Estimation-driven software development can lead to an economic disaster. This article explains how, so that you can avoid it.
Estimation and estimates are a dreadful way to run a business. The basic idea is this: Estimates anchor benefits while not limiting your costs at all.
Let’s look at this statement in parts. The second part (“estimates don’t limit costs”), is self-evident. Anyone looking at the track record of software projects will see the evidence. Below are some examples.
In my presentations, I list several sources and results from surveys and studies. The one that most strikes me is this one: “17% of all large software projects went so bad that they threatened the very existence of the company running that software.”
17% of all large software projects went so bad that they threatened the very existence of the company running that software.
Source: McKinsey & Company in conjunction with the University of Oxford, 2012
This example alone is clear evidence that estimation, does not limit the costs of the software project. So when people claim that “we need to estimate to know if we ‘can afford’ the project”, they are either ignoring this data point or may think they are better “than average” (a known bias for humans).
Right, but how do estimates anchor (in other words: limit) benefits for a software project?
The value-limiting impact of estimation
This first part of the statement above takes a bit more explaining. Here’s how estimation works:
- We define a scope (what we want)
- Then, we speculate as to the approach to delivering that scope (how we are going to do it)
- Based on that speculation we come up with duration or effort guesses (the estimates) that are then used to make commitments (aka contracts) with stakeholders, other teams, etc.
Once we’ve completed these 3 steps we’ve basically committed to “what” and “how”. As a consequence, we are less flexible to changes in the “how”, not to mention the “what”. Hence we have largely limited what we can deliver as well as the overall strategy (and sometimes the detailed tactics as well!) for delivering it.
Traditional planning destroys value creating opportunities
The benefits we deliver are naturally anchored (tied to) the “what”, and they are greatly affected (tied to) the “how”. Let’s take an example.
In my workshops, the students break down an IT Ticketing system delivery project into a 24 hours increment.
When the students start, they think (as they should) it is impossible. Why? They assume that we will have to buy a system (which requires procurement to be involved, immediately shooting up the time required) to implement an IT Ticketing System in a mid-to-large size organization (10K employees).
That assumption (what and how) immediately leads us into a path that has some locked in variables (procurement, need to have a lengthy requirements gathering process, need to open a bid process with multiple providers, etc.).
These variables, once locked, immediately limit the value you can deliver, even before you got started.
These variables, once locked, immediately limit the value you can deliver, even before you got started.
Estimation is impossible without making such assumptions (what would you be estimating then?), which then leads to the inevitable locking (anchoring) of benefits!
Estimation is impossible without making such assumptions, which then leads to the inevitable locking or achoring of benefits!
In the #NoEstimates movement, we deliver very small increments at frequent intervals. Therefore, we constantly look for implementation alternatives so that we can discover benefits later, and deliver on those even if they were not in the original plan. In essence, #NoEstimates welcomes… No! #NoEstimates is designed to welcome change.
