Sep 25th, 2017

NoEstimates

I’m a huge fan of #NoEstimates movement. After more than ten years as a software developer, I still suck at estimations, sometimes even for simple things. And I will probably ever be. The thing is that I’m not the only one:

On Average, Large IT Projects Run 45% over Budget and 7% over Time

I don’t want to get into details how no estimates approach works neither when and how to estimate what needs to be estimated. I will not dig into reasons why we, developers, are so inaccurate in estimations.

Instead, I would like to sell you this methodology with arguments that already sold it to me.

Stress

Estimates that one cannot make are stressful to everyone.

Starting from a developer who either blames someone else who acts as a dependency or feel guilty as a lame programmer. That will feel anger on the manager or customer that made pressure to put lower estimations. Or some authority that during estimation round told everyone nah, that’s easy.

Through manager who acts as a proxy and has to handle customer anger, ask hard questions to the team or response to the customer with bad news.

Finally customer. The one that pays our bills and starts wondering if someone tries to make him fool.

Quality

Have you ever tried to lace your shoes in a nervous hurry? Even the simplest things that you do every day with closed eyes, start being complex under pressure. Imagine that you have to, in such conditions, create something complicated or fix a bug that doesn’t work for unknown reasons. Something that requires focus, time and deep thinking.

With the burden on your shoulders instead of well-crafted solutions, you start looking for shortcuts. You stop thinking about maintainability. Code reviewer will know that whole this crap should be buried in the 7th circle of hell but there is no time to make it proper, so just close your eyes and accept this spaghetti that even creator could not understand.

Useless meetings

Let’s say that you have sprints 2 weeks long. Every other Monday your team spend some time to estimate. Multiply the number of meeting participants by hours spent by your wage and you can throw that money to the basket equally.

It’s an open secret that developers are bored during such meetings. They rarely can fully concentrate. But even if they can there are a lot of unknowns on the sprint track.

There will be issues to be covered outside of the scope.

There will be unexpected interruptions.

There will be dependencies that we have to wait for.

There will be misunderstandings.

Finally developers - as probably all human beings - tend to overstate their skills and will be really sure that can accomplish this task in a proposed timeframe which, as we already know, rarely will be real.

What instead?

Should you instead allow a developer to tackle the task as long as they wish? Definitely not. There are a lot of articles, probably even thesis, about benefits of deadlines. The key here is to take advantages and hide shortcomings.

Instead of estimations we should demand defined deliverables every day.

When a task is too big to be delivered in a single day it should be split as soon as developer notice that fact.

As a side effect, this would require making proper plan before tackling the task… and that could give you a tool for more accurate estimations. Small portions of work in single tasks allow measuring real velocity of a team in tasks per day.

It would also require leaving project at the end of a day in a state without tasks open for weeks. If any developer won’t come to work another day others in the worst case could start the work from scratch - not so much will be lost.

Yes, I know that good Agile practices require the same thing, and some still have estimations. But it doesn’t reduce problems mentioned above and it’s much easier to lay back discipline of small tasks when they’re actually not crucial in your methodology.

This approach might not be intuitive for many, definitely, it makes tricky long-term assumptions, but I encourage you to give a try. It’s one of this thing that once tried, you never want to go back.