Over the past few weeks I’ve been trying to put my head around the #NoEstimates approach. I am not a cynical type of person and I have approached this investigation with open mind and with a view to rationally verifying whether the approach is sufficiently solid to be used in the type of corporate software development domains in which I normally operate.
For an approach, any approach, to be accepted by the mainstream it needs to provide a complete solution. To be taken seriously it needs to address not just an immediate problem but also all connected facets that this problem is associated with. When it comes to the area of estimates – in the software development domain – any proposed alternative needs to address the same type of questions and expectations that the current approach is attempting to deal with.
I have come across two main active proponents for this approach (Woody Zuill and Neil Killick) so I decided to do a sweeping review of their published writing to try and gauge the completeness and comprehensiveness of their approach.
Both gentlemen agree that at the heart of the drive to obtain or deliver estimates is the need to make decisions. The types of decisions can vary but, most often than not, they will touch on such issues of affordability, about investment strategies, about ROI, etc.
They also agree that while the need to make decisions is a legitimate one, estimates are the wrong tool to enable that process. They therefore suggest that as long as decisions can be made without estimates then estimates can be disposed of as an unnecessary, redundant and useless technique.
This is how Woody sums this up HERE:
…it looks to me that what we need are decisions, not estimates. Estimates are often used to help us make decisions. Estimates are not the only way, and for many of the decisions we need to make they are likely not the best way, in my opinion. We can, and maybe we should explore other ways to make those same decisions.
At the heart of the proposed approach lies the following proposition (see in Neil’s post HERE):
Instead of depending on an accurate estimate for predictability we can take away the unknowns of cost and delivery date by making them… well, known. The Product Owner can fix the delivery date based on a concrete budgetary and/or time constraint (e.g. 3 days before the Australian Open starts for the Australian Open app is a concrete time constraint, and “we have to build something for $30,000″ is a concrete budgetary constraint). Within that constraint the team can then fix incremental delivery dates (e.g. end of every Sprint) to allow focused effort on iterative product evolution (it’s not good to have priorities changing every day on a whim) and provide the opportunity to deliver early and/or under budget. This approach is also useful where there is no concrete budget or delivery date, although the need for interim release dates diminishes if the team (and organisation) is mature enough to have a continuous delivery model.
And a few additional comments from Woody’s blog:
Most of us will probably agree that decisions are important and we need to make them, and that we want to make “good” decisions. Great decisions are even better. Yet in many cases, mediocre decisions are sufficient [stay with me here...]
Interestingly, as long as we pay attention, learn from our mistakes, and are willing to make “course corrections” frequently, even bad decisions are often sufficient. In other words, even if we make bad decisions, we can adjust and steer our work (and therefore our results) by making decisions as we go along. That is an important point. Dwell on it.
To summarize, given that estimation has ‘built-in’ uncertainty associated with it, this uncertainty can be completely removed by fixing a delivery schedule based on a per-agreed budget and/or time constraint.
So this is my understanding of how this process is proposed to work.
- The organization allocates fixed amount of $’s and uses these $’s to ‘buy/hire/employ’ a certain number of resources (I am assuming that these resources could be people and assets, as appropriate)
- The resources are allocated to work on development activities, with the priority being determined by the business value these will deliver.
- This is progressing in an iterative manner until such time that the allocated funds are exhausted or until such time that a certain milestone, or predetermined date, has been reached – at which case the process ends.
If I was an owner of an organization and someone were to approach me with the above proposition I could decide to take it on. Given the fact that I spend my own money I can certainly decide that this could work for me.
What if I were to spend someone else’s money? Would that change the dynamic of that decision? Let’s explore this question:
When committing other people’s money there is often a requirement for transparency in the decision making process. In this case the following are legitimate questions that person can ask:
- “why did you decide to spend my money on this product, and what will I get for my money at the end”
- “I have a number of products I can invest my money on, why should I spend my money on this product at the expense of other products?”
Woody is suggesting the following to mitigate these questions:
There is a lot of stuff we need to decide, which requires that we make decisions. Make many small decisions while you learn, steer, adjust, and correct.
This, on the surface, is not a bad advice but does this approach work for large and complex implementations?
Would you commit many $50M on an enterprise ERP configuration project with the approach that “we will make decisions as we go”? And even on a much smaller scale. You need to make an investment of $2-3M on a new Document Management System using SharePoint. Would you make decisions on the fly given that you need to commit upfront funds for purchasing the software and the hardware on which it will ultimately reside? Sure, determining what will be developed and allocated to each and every iteration can be done progressively throughout the project, but what about the large and more strategic decision?
While some aspects of the #NoEstimates approach can work, they can only work in very limited and confined circumstances. I suspect that even then they cannot be implemented on large scale software development projects, and they cannot be implemented in organizations where strategic budget allocation is done based on cost benefit and ROI considerations. Until such time that this approach can demonstrate how it would deal with these issues, from my perspective it is busted.
Think about it!