Sick and tired of Agile estimation
During this last week, I finally had the opportunity to read a book that was on my reading list for long time: Black Swan by Nassim Nicholas Taleb. The book is about uncertainty and unexpected events.
NNT (as the author calls himself) explains that we live in an extremely complex world where we cannot predict all the events which will happen, and therefore it is silly to try to plan or predict future outcomes.
Throughout the book, he mentions several events that humankind did not dream of that caused terrific outcomes.
Even living in this complex world, we always try to plan everything. We always try to predict the future. But, like NNT shows us, Plans fail because of what is called “tunnelling”: the neglect of sources of uncertainty outside of the plan itself.
We humans believe that we are good at forecasting if we do the same task over and over again; we think the more routine the task, the better we learn to forecast… We just forget there is always something non-routine in our complex world that will destroy our forecasts.
Like NNT explains: most delays and cost overruns arise from unexpected elements that did not enter into the plan—that is, they lay outside the model at hand—such as strikes, electricity shortages, accidents, bad weather, or rumours of Martian invasions.
We cannot project the behaviour of a system if we do not know all possible conditions of that system, therefore we cannot truly plan; all estimations will be, most likely, completely wrong. Let’s make the bridge now into software development:
Everything that I described before can be applied directly to software development, so why the heck do most of the companies (in my experience) still ask for detailed plans and estimations? It’s ridiculous to even start when we already know that we will be wrong!
Why do we still have Senior Management asking for milestone plans with detailed lists of features for months? Why do we have people bothering themselves with Gant charts full of detailed information that will be obsolete as soon they finish printing out the Gant chart?
Why do we have management looking into sprint reports, asking why the Delivered stories are not as high in number as the Committed stories? Why do we even have management forcing people to learn “how to get better at estimation”?
Why do we have management bothering Scrum Masters with questions like: “Why does the sprint burn down have several peaks? I would like to have a normal line!” Why do we have teams spending hours in useless estimation meetings where they discuss if the story is a 3, 5, or 8? Even worse, why do we have teams spending entire days doing estimations for complete product backlogs?
All the previous examples can be considered evidence of fantastic waste! We spend days and days trying to achieve what we cannot, so what can we do to avoid all this waste? The solution is simple: DO NOT ESTIMATE.
