The #NoEstimates Beef! And Agile's Trojan Horse

Posted on August 16, 2013 by David Anderson

Today I was inspired by a post to the Kanbandev Yahoo! group by Dan Brown from the UK. For those of you who don't know Dan, he's a very lovely man, a fabulous Kanban trainer and coach, and experienced practitioner of Agile software development methods. And particularly endearing to me, he started his career as an assembly language programmer, just like me, producing near defect free code, in hostile silicon environments, unlike the pansies with their protected memory spaces, 3rd generation languages, compilers, debuggers, and modern fancy IDEs with automated testing environments, static and dynamic code analysis and so many other belts, braces and protective screening devices designed to prevent bugs escaping into the wild. So we've established Dan is a good guy! :-)

Dan's Beef with the #NoEstimates Movement

Recently, Dan posted his thoughts on the growing #NoEstimates movement that is advocating dropping Agile estimation methods such as Planning Poker(tm) and Fibonacci Series sizing. Dan worries that despite the self-evident benefits of probabilistic forecasting, those moving to this so called "No Estimates" approach might be throwing the baby out with the bathwater. It's an argument I've heard before. Here is what Dan had to say...

I have a bit of a beef with #NoEstimates. There is a hidden pitfall I've mentioned a few times here and there and it goes like this:

Estimates are pointless wastes of time and effort. Once you are sizing your Work Items, and start using Probabilistic Planning, you will get much improved predictability. Estimation however has hidden value.

 

If you are doing classic Agile Planning Poker, and I say something is 3 bananas, and you say its 13 bananas, then there is a good chance we each know something the other doesn't know, and it’s a great time to share that so that the entire team engaged in estimation gets to hear that and share in the tacit knowledge, just before we go away and do the work. That to me has great value.

If we throw away estimates, but don't even realize we are throwing away the true value of estimation (shared tacit knowledge just in time) then how can we know we need to find an alternative way to get that value? There are other things that provide real value benefits at the end of them that will get the same shared tacit knowledge just in time - BDD for example. If we all participate in defining the Gherkin acceptance criteria, we share the tacit knowledge and get valuable, usable & code-able acceptance test as an outcome too. Win-win!

Estimation is Agile's Trojan Horse!

I thought I'd share an edited and enhanced version of my reply to the list. I'm not a fan of Agile Estimation and haven't been for more than a decade. My first book, Agile Management for Software Engineering, advocated the use of a probabilistic approach. Such an approach was used on the first Feature-Driven Development project and I had used variants of it many times in the intervening years, before Agile Mannagement was published in 2003. Here is my argument as to why Dan's defense of Agile Estimation doesn't persuade me to stick with it.

Estimation is Agile's Trojan Horse! Agile Estimation seemed like a gift in the early part of this century for methods that appeared to corporate types to represent chaos and anarchy. However, I believe it is a gift that is poisoned. The baggage of reductionist thinking, Cartesian decomposition and determinism that comes with it, is a price that isn't worth paying regardless of the benefit!

It seems the real value of the practice of estimation is in the conversation and the analysis that comes from the discussion. Agile was in part a revolution against the analysis methods of the 1990's and hence, it wasn't tribally acceptable to have "Agile Analysis". Many valuable techniques developed in the 1990s were shunned and rejected by an Agile community amongst which "the code was the only truth."

The Apologist Argument for Agile Estimation

I genuinely feel that Agile Estimation is fatally flawed and the apologist argument that is often presented is not a suitable defense.

When you call it estimation and what you do is estimate but you are doing it because you want an emergent side-effect, you will still get the estimate and people will still want to use it. The "but you should throw the estimate away afterward" advice is a part of the narrative that practitioners don't hear and don't do.

If, fundamentally, you don't want the estimate then don't do estimation! Period!

Be Explicit About Collaboration

If what you want is a collaborative discussion to flush out analysis of functionality and risks and to spread that tactic knowledge across the team then find an explicit way of provoking that and call it such. It is well known that human beings store information inside the heads of others in their social group and struggle to discover hidden information inside the heads of others in those same groups.

The Kanban Method is all about making invisible things visible, making implicit things explicit, getting everyone on the same page and fostering better collaborative decision making through the act of flushing out the truth about work, workflow, risks and so forth.

Using a method (Agile Estimation) that is intended as a disguise, in order to discover information you know you need in order to improve service delivery, goes against the underlying values inherent in the Kanban Method. Hence, Agile Estimation is at odds with the value system inherent in Kanban.

If Agile Estimation is what you do now, then you would likely leave it alone initially, but suggesting that it is necessary and that its necessity, highlights a flaw is the #noestimates movement is simply wrong.

Forecasting benefits from analysis and categorization

Probabilistic forecasting will always benefit from filtering types and classes of things in order to achieve a data set with a single mode and from this to make a best fit distribution curve for the purpose of forecasting. Finding an explicit way of doing such analysis is important which is why a considerable amount of my peripheral guidance is associated with identifying types and classes and using various forms of qualitative assessment to achieve fast, factual results with consensus.

If an organization values such analysis to help with its planning and risk management then an explicit activity to encourage the conversations, collaboration and discovery of facts that help categorization and classification of requirements should be included in the process or workflow. I would not consider such a practice to be a core part of the Kanban Method, nor would I want to prescribe precisely how it is done. However, it is clear that the outcome should produce factual information that informs better probabilistic forecasting and does not encourage deterministic speculation about size, complexity, or risks within piece parts of a whole.

Comments: