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 today.
When the round comes to you and the Agile Coach / Project Manager mentions the ticket you are working on, you say:
I am almost done, I just need to apply some final touches but it should be simple and quick
Fast forward a couple of days or even more and you find yourself repeating that again and again.
Yeah, I am pretty sure I will be done today, had a couple of blockers yesterday but now I am really almost done!
Let's be honest. How many times did it happen to you ( or you see this happen in your team)?
How can a task that you said it was almost done, end up taking 1 or two more days ( if not an entire week)?
Not trying to be mean or bossy here. I found myself in this situation many times. The thing is
Why are we telling others and ourselves the almost done lie?
Fear of judgment
Are we afraid to admit in front of our colleagues and superiors that we have been slower than it was estimated?
Avoid conflicts
Are we trying to be accomodating and avoid stating that we all knew that it was not possible to deliver on time and the estimate ( that was forced onto the team by management) was wrong?
Imposter Syndrome
This goes together with the fear of judgment but has more to do with the inner fear of not being fully capable of managing the task and that if we say we are stuck or are struggling, others might think we are not the experts we pretend to be.
Pareto principle
Are we aware at all that we are way behind schedule because the hardest part / or simply the longest part has yet to come?
The Pareto principle, also known as the 80/20 rule tells us that 80% of the feature is implemented in just 20% of the time, the remaining 20% will account for 80% of the time. Evil is in the details: we might have quickly already built the form or the RestAPI but we still need all validation, proper error handling or CSS and that will take lots of time!
Dunning Krueger Effect
Are we aware at all of our skills, do we have a clear picture of the task to be achieved, of the unknowns that might be hidden, of the possible blockers, of the technical knowledge required to accomplish it, are we maybe really overestimating our abilities?
The trap of Perfectionism
Maybe we are just too perfectionists?
We were really close to being finished (almost done_), but then we decided to refactor that ugly piece of code using some design pattern, or abstract away all duplications, and now we are halfway through the refactoring and everything stopped working, (and of course we don't want / can´t stash all our beautiful changes and deliver the old version)
or maybe we just really don´t know what Done means.
The definition of DONE
What does Done mean for you, for your team, for your boss, for your client?
Are you done when you just formally accomplished the list of things in the ticket and you can finally move the ticket out of the In Progress column then go to smoke a cigarette or play kicker?
When can a task be considered done?
50 shades of done
Are there different levels of Doneness?
- sloppily done
- good-enough done
- done done
- WOW! done
Have you ever discussed this with your team members and agile coach?
What are the steps to accomplish the task?
- Implementing the feature
- Write unit tests
- Do some manual tests to find bugs in usage
- Prepare it for different environments
- Integration tests
- Deploy it
Maybe your team splits those into different tasks, or between different developers with different seniority?
Maybe you come from a team or company where nobody ever cared about unit testing and now you struggle in considering those as part of your task when in fact they are taken for granted during the delivery of a feature
Doing the right thing
It may also happen that you are done, but you did the wrong thing because you were afraid of asking questions or you proceeded on wrong assumptions.
Maybe what you were asked was a simple prototype to test out an idea, a future project. Or an MVP (Minimum Viable Product) - a polished, working, production-ready, tested version of a product but with very basic features.
But you are there, still implementing a restful API for all the data sources, or fighting with CSS for the alignment or style of that Send button. All things none would care of in this phase.
Maybe you obsess on unit testing coverage and got lost in mocking/stubbing every piece of code when some unit tests and more integration tests would have been easier, quicker and actually more beneficial.
Many people talking about 10X Developers reason only about tech skill and speed but forget that fundamental aspect of efficiency AND effectiveness.
Efficiency is doing things right; effectiveness is doing the right things.
There is no point in being fast and perfect if you end up delivering something no one asked.
Scope creep
Asking questions, understanding the requirement and the expectation is also important to redefine the scope of your task and improve your sprint planning and team estimates
Maybe the task should have been split into more tickets, more granular sub-tasks, and then the big picture and the small details would have been clearer and so the time needed to achieve the task more precise.
When goals are defined, it is less common that many other small changes in requirements will be asked on the way ( without adjustments of the estimate or delivery date)
Code-review bottlenecks
How many times did you think you were done, but then you got the ticket bounced back during code review because your code was full of typos, you didn't write unit tests, you forgot to add validation in the Form Inputs, or you forgot to consider env variables and too many dependencies are hardcoded?
Simply the fact that you moved the ticket to For Approval within the estimated time, does not mean that it was done and that you delivered on time and now it´s the fault of that annoying picky code-reviewer and you now need more time to be "done" with those adjustments. (see Definition of done above)
Bugs
I am not say everything you push should be bug-free, but if you were requested to implement a form, and if you forgot to add a basic validation for a required field and everything crashes, you cannot just say..:
well, but that is a bug! I just implemented the form, let's close the story/task ticket and open a bug ticket for it. ( unfortunately, I heard that...)
and you call this "done"?
So, as you saw, there are plenty of reasons why a task could not be considered completed or could not be completed within the assigned time.
Deliver on time is essential for your team and company success and it´s essential as a professional developer.
This means that we should never be vague and we must be aware of the goal and our progress. And if it happens that you find yourself behind schedule, if you realize you are not going to make it on time, don´t lie, don´t omit the truth mentioning "simple final touches or irrelevant hiccups".
It´s not about feeling guilty and stressing about it, it´s more about informing your team and your project manager so that maybe you can get more time or you can get some help.
Cover Picture: Cape Town Foreshore Freeway Bridge - construction started in 1970 and left uncompleted in 1977 - and still there (I saw that while driving during my vacation in South Africa last October and was quite stunned..)
Top comments (39)
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.