10:00 AM Time for your team´s stand-up meeting.
Everyone tells about the tickets that they closed yesterday and explain what they will work on tod...
For further actions, you may consider blocking this person and/or reporting abuse
This is my visceral response of the feelings I had when reading this post. I've not had good luck with Agile teams, some my own fault, some others fault. This is in no way meant to be a slight on Davide's article. It's just some thoughts... that's all.
Sounds to me like the same things poor managers push on development all the time. Software is never done. That's why we tried to move away from date setting to continuous delivery.
In total defense of those in the trenches, not even they are able to continually estimate correctly. Why? Because the frontend world's Npm ecosystem is a disaster not to mention the volume of things needed. A simple app requires 20 to 40 meg of Node Modules? Do we have any idea what all that shit is about?
Web Apis are easier due to standards centered around http protocols. But major unexpected things happen there too e.g. using SOAP to REST etc.
Security presents major obstacles which adds weeks in some cases just to get fundamental issues resolved.
I've been in IT since 1987, and have lived all the changes. Whats clear to me more than ever is the pressure to get it DONE is mostly a ridiculous expectation based on market pressure which has caught the highly paid planners unprepared.
I have yet to see companies have the proper Architecture in place to deliver rapidly. Sotware development is still a start from scratch endeavour. How can I say that? I've been a consultant my entire career. I have never once seen a internal company library of reusable components.
Your points are reminiscent of 60's style management which created toxic environments. You can hit a monkey as hard as you want to produce more, but if he doesn't know the answer it won't matter.
The real problem is in pushing up the reality of missed due dates because 3rd level expectations were simply wrong. You know, the quarterly planners. Somebody must push back and it rarely happens because, well, 1st line managers and Scrum masters would like to keep their job. So the trench person always takes the hit.
The points you made, make me glad I'm not on your team. I don't recognize any of them as collaborative in nature.
thank you very much for your detailed comment, but I believe you did not quite get my point.
I am not ranting about developers not delivering on time and putting more pressure on them.
I just listed all the possible reasons why we ( and I put myself in since I still code 80% of my day) are often caught saying generic "I am almost done" during standups.
and I made it very clear in the conclusion that being precise about the level of doneness could help improve estimates, planning, manage to stretch a bit the schedule, or get some helping hands from colleagues.
not at all to punish or ridicule the struggling developer.
i am sorry if I was not able to deliver the idea with more clearly and with more humor.
Also please be aware I'm not talking to you directly, the content of your article is mostly good. It caused me a bit of pain as I read it based on my past experiences with everything you mentioned. Stand-ups can be great but they can also be tortuous. Retrospectives can be great and they can be worthless. Dependencies can be taken seriously or glossed over. Infrastructure is almost universally not enough on long standing projects. Security can be too tight. Complexity is over the top difficult and finally the tooling isn't quite there yet.
Tying in JavaScript with a different back-end is ludicrous but done all the time. How many hats are developers required to wear? It takes a minimum of 1.5 years to be a SME for Java or C# minimum. Typescript/JavaScript take the same amount of time.
I know. no problem. honestly, I regret picking such a straightforward blunt title which does not really reflect the overall mood of my post.
And I'm suffering from PTSD for being in Agile trenches too long....
sorry man.
hope you get well and wish you can find a nice team with smart colleagues and managers. lots of challenges but without stupid pressure
I apologize Davide, I think I was triggered from past experiences. Thanks for posting this.
I totally get your points. We're all in the same boat, but the root of the issue is simply today's expectations truly exceed any ability to set a due date.
Continuous delivery is the only way with each iteration biting off small chunks. If a dependency arises and management doesn't address it (like security getting in the way, or poor infrastructure) then the problem is not the developer's issue. Yet it's the developer who has to stand in front of a group of peers (who are not having the same issues) and report daily.
Retrospectives are another joke, I've seen idea after idea to improve never receive any traction because the desire to meet a due date exceeds the ability to fix technical debt. Developers are simply not allowed to create the tools and processes necessary to heal the toxic environment. In fact technical debt is almost never addressed, in favor of getting the new stuff out.
Any developer who's been around a while, knows there's nothing they can't accomplish, it's just a matter of time. Putting additional pressure on the developer is not the answer. What's need is shared responsibility and collaboration. Many drill sergeants don't do that; rather, they side with upper managers in order to shine and keep their job in this ultra competitive world.
I my last 7 years, I've only had 1 of 5 Agile teams actually make it pleasant to work there. The rest either just wanted to keep their jobs or were arrogant by nature. Arrogant leaders are a big thing in IT which is a total detriment to IT Teams.
i could not agree more with what you wrote, besides that in my last 7 years and 5 teams only 1 was not pleasant to work with, exactly for the reason you mentioned.
Retrospective were done just because it was cool to say we were agile, the pression was too high, tecnical debt never addressed, it was
but I managed to leave that team and then always found strong colleagues that shared passion and will to change, and good managers that fought on our side bringing our requests to the management, rather than just filtering them account ( yes yes, tell me and then i will never bring them up..)
This is why no estimation should be done in advance.
I don't know what kind of agile methodologies are you applying but agile is about delivering value to a product not moving tickets on time.
Agile techniques also help to move out the focus from engineers by understanding how sw development really works. If you, at any time, find yourself blaming somebody (e.g. because he/she is not in time) instead of blaming the system then you're sure you're not doing agile.
I take this article as anti-pattern recipe to any sw project management.
I dont know how you could come to the conclusion I blame somebody for not being done.
the point is : and i always to it with a smile ( without sarcasm) - If you are not done, it's not a problem. Just let us know. Agile means being able to quickly react. If you dont let team mates and superiors know whats the real status, it's impossible to react.
Of course I meant you as a generic project mgmt guy. Anyway, "bugs" section depict exactly the blaming culture we should eradicate. Instead of questioning why an engineer missed an input validation we should ask ourselves how to improve the system so that this doesn't happen anymore.
did not mean to sound so harsh on the bug section.
but unfortunately, I had a couple of examples in mind which happen many years ago and seriously, there was not much in the system that could have been improved. simply my colleague at the time was very very sloppy.
believe me, you could have not missed that bug if you had run your code at least once after writing it.
In this case it is an HR problem. That person shouldn't have made its way there in the first place. It will repeat in other ways whatever measures you take.
absolutely. and whenever he is right now, I am pretty sure he still does. :-)
:) Why I point out this is sometimes you may be wasting resources on things you cannot fix. The approach that ”introduce a workflow so that it never happens” should be taken with care or introducing systems for such people will consume your resources instead of the actual work.
In my old workplace, we had a "definition of done" doc. It listed all the things we needed to do for a task to be done and by saying almost done, others knew we had probably covered 90% of that list. If not, you'd just say "I'm currently working on developing/testing/documentation for this feature" and that was enough to update the team in a stand up.
exactly. the definition of done is very important.
if you say "almost" I think of about 90% completion. however big or long the task was. If it was estimated for a week (5 days), and you are almost done at standup time, it should be done in the evening max.. :-)
"Almost" for something more than a week or two is tricky. I tend to phrase it as "I expect to have a pull/merge request up today, if all goes well" and if I don't, I tell the team the reason why in the next standup. Almost is too vague that I didn't realise I barely use it anymore.
A code review I dislike is
It is so vague, it seems like throwing a comment because of a hunch. The problem is:
Code review is not making other people's jobs or delivering them the solution on a silver platter but is neither about sending someone on a wild goose chase.
absolutely.
such a comment in a code review does not make much sense. And honestly i would take for granted that the reviewer knows really well the codebase (and has checkout out the branch to see the piece of code in its entirety and maybe try it out)
If the other way is just a matter of taste, it is bad, if it is indeed a better solution but not preventing major bugs or solving a problem that may arise, and you are already tight on the schedule , it can be better to leave it as it is, or maybe create an Issue on Github/Gitlab or a followup ticket that will be estimated and planned.
Hello Davide, thanks for your post!
We're a small shop and I usually review other people's code since I'm more familiar with the system, and we don't currently have a definition of done, a list of acceptable criteria or even a uniform way of creating and explaining tasks. Newer developers will usually refer back to the person who created the task to verbally explain the task without updating the description in the task management tool we use.
Now this and other reasons have caused a code review bottleneck as you mentioned, where I keep returning tasks that are marked as done to 'open'. Now we're working on improving this process, however I have two questions:
Hi Doaa, thanks for your comment.
Well, in a small shop it's a bit different and difficult because everything is less structured and there are fewer resources - no agile coach, no product owner, no project manager etc.
This does not mean you should not have a process. Start small and simple and build on top of it.
regarding your questions:
1) normally whoever is in charge of the project ( PO, PM, PjM, Lead, Agiile Coach) but if you don't have any... it could be anyone.
Who works on the ticket could before starting to code, write down some thoughts, some points of the stuff that is needed, and describe the task. that will work as reference for the the acceptance criteria and user story, instead of something that was just verbally explained.
2) There will always be cases that were not documented or taken into account. don't worry.
starting with TDD ( test driven development) can help ( and as long as you find new cases you can leave some tests as todo and open new tickets for the future.
3) if it's something major, send the review back, if it's something that is missing - but you haven't established yet, maybe just write it down as a comment, summarize them, share them in the first meeting/retrospective/standup, ).
I often create issues in gitlab for some stuff I think is needed but not necessary to proceed with merge - and open a ticket straight out of it - in such way, the technical debt is already being "documented""
Don't get demotivated or angry, just be propositive and try to make life and work better for you and your team. it will pay off - probably slowly, but it will.
Be proactive and lead the way :-)
Thanks a lot for your comment!
I do think TDD will help us a lot in our business - unfortunately we've had countless instances when simple tests would have caught embarrassing bugs. I'll do my best to advocate for it.
So as I understand it, retrospectives can be quite specific if I can mention issues in MRs/tasks? Up until now (and we haven't done many) it's just been general feedback about the week and workload.
As for your last point, we've tried creating tasks for technical debt but that caused a huge backlog and top management was confused in how those 4 tasks related to the same feature/bug are different, so for now when I send a review back I also send the task back, so that all of its history is there in one place.
Thank you again for your help! :D I'll keep my eye out for more of your articles.
I get completely understand and agree with what you've written! I've only been programming for 4 years and within that time there have been numerous occasions where I've said I'm almost done when in fact I still have a load to do! I think this was because as a junior developer, I simply didn't want to look bad, whereas I should've just been honest!
As I've progressed I've realised that it's better to just say, however, I still need to improve as I find myself doing a lot of work outside of work because not enough time is given for things like unit testing. This is something that I need to work on.
Great article and I'll be following you for more :)
thanx for the comment.
asking for help, asking questions, telling the truth about potential delays or blockers immediately is very important for professional growth.
and please don't do at home stuff that you should have done at work. work is work, free time is free time. if you find yourself behind schedule, talk with your lead and pair program with a senior or another junior to go past the issue. and if the estimate did not consider the time for unit tests.. well that is definitelz something that needs to be addressed in the next sprint planning/retrospective
It's not just about being junior. It is about feeling insecure. The job environment and culture should make sure people feel secure so that they can comfortably admit something is not going well.
yes. but we are the people. honestly i never met mean bosses which punished people for a ticket that take too long. The only circumstances that make manager angry is when they were not told they were going to miss the deadline. so it's always better to tell the truth.
I can't say how many times I found myself in this situation. In general I try to use time units in weeks. Due to dependent nature of development I feel there is not much difference between an hour and a week.
what do you mean exactly with that? :sweat_smile
I tried to mean a week looks like the smallest possible unit of time for development. So if something is almost done, I prefer saying it will be ready within a week. Saying it will be done in 5 hours usually end up being a way of tricking myself.
Hmm.. interesting article.
sometimes people behave not because they want to but because of the environment around them made them choose to do it.
Not sure about the agile method you used and the function/role from your agile coach in your team, but when you worked on the project with the agile method, you can always make an evaluation when you finish one cycle process. From there, you can see the feedback and you can evaluate your team capacity.
If your team always doesn't hit a certain target which was agreed at the beginning, maybe that's the right time to made evaluation.
not completely sure what you mean exactly, but we do have, ( even too sparse imho) kind of sprint retrospectives/evaluations where we check for example in the last 3 months of all the tickets we worked on if we managed to keep up to the estimate, if we did not, we somehow reasses our way ouf doing the estimates and/or of creating tickets/describing tasks.
This really looks like a rant. Otherwise, if you see a failure, maybe you should address it with your team. I thought this was the whole point on Agile: improve along the iterations. It's not unprofessional to make a mistake. It's not unprofessional to say "almost done". It's a problem bigger than the person saying it, and they clearly need help with it.
of course, it's a rant :-) but its intention is humorous and helpful.
and I wanted to ( first find and then) provide an insight of the reasons why we - because I still do that too often - say that.
And it is not unprofessional to say it. as long it is true :-) (still more clarity, and informative wording of the status of your task would me more profesionall and more useful to your team - this is what standups are for, after all.
Thanks for writing this post! It's really helpful.
Just read this comic after reading this article. xD
golden!
Nice article, thanks!