A classic agile cartoon uses the metaphor of chickens (stakeholders) and pigs (Scrum team) to communicate the relative level of commitment to projects. In an original cartoon series, the chickens (stakeholders) usually get the brunt of the joke because stakeholders are often the least likely to understand the complexity surrounding the development of complex products.
A few years ago, Mark Pushinsky contributed the following blog to describe the cone of uncertainty (the attenuation of estimation accuracy over long periods of time) and how agile methodologies help manage it:
"I was on my way back from Vegas sitting on a plane, with a massive hangover…….and this thought occurred to me.
Do you know about the Cone of Uncertainty? It is a phenomena that people in software use to describe the fact that when you start a project you have no idea when you will finish. The longer the project goes and the closer you get to finishing the better/more accurate your estimate. Basically you are pretty sure you are going to finish it the day before it is done.
We have been trying to make it go away in software for many years. Fancy new estimation techniques, months and months of analysis, and brute force have not materially changed the fact that software projects are unpredictable!
Period!
Managers having been trying for decades to make it disappear/pretend it does not exist/figure out how to make it turn from a cone into a cylinder. Yet time and time again the uncertainty in projects remains.
The epiphany that occurred to me is that Agile or Scrum flips it around. This means that if you ask me what I can deliver in the next 2-4 weeks I am pretty accurate, if you ask me what I am going to deliver 3 months from now I have some uncertainty, but I can give you a reasonable guess, and if you ask me what I can deliver 6 months from now I have no idea…….
When we teach estimation and planning in class, we make a point of saying that Agile does not make the Cone disappear. Nothing will! We use lightweight, proven techniques to make our best guess at long term plans. We do not pretend to know the end…….in fact we are pretty sure it will change……and we commit to be back in 2-4 weeks to tell you how it has changed. Then we focus on short term commitments, doing the right things, executing well, and delivering outcomes
I have found that after a couple of iterations of working that way we get customers focused more on prioritization, the next release, and getting impediments removed. They begin to worry less about when the whole thing will be done. I think the best way to end a project is to stop working on it before all of The Requirements have been implemented.
The 80/20 rule, right?