The great thing about a straw man is that it burns easily. With this in mind, let’s light up a few #NoEstimates straw men and watch the embers float into the night sky.
I’m no authority on #NoEstimates – Woody Zuill and Neil Killick are really the authority on the subject. What I can bring, though, is the perspective of someone working on a team that does no estimates.
Here is the basic version of our implementation of #NoEstimates. We deliver released product increments in two to four days. We allow one acceptance criterion to be in flight at any one time and we hand it back absolutely done™ in a few days. Everything that would cause blocking or waiting gets autonomated (builds, releases, running of tests) – so these only require human involvement when the machine breaks. Making regular releases builds trust and introduces a feeling of predictability despite the work being unique each time (we never work on the same acceptance criterion twice).
So onwards to the straw men. Apparently we should estimate software because we wouldn’t buy a kitchen or get an MOT without obtaining an estimate. Hand me the matches, because building software is not like building a kitchen or performing an MOT (a vehicle safety test).
Although there are many configurations of kitchens, they are already in stock and the installation is highly predictable. You don’t even need to ask a craftsman to give you an estimate – there is a simple formula for working out how much the kitchen costs and how long it will take to install. Usually, the cost is entirely generated by the computer using software operated by a sales assistant. If the workmen find variability on site, you get charged extra and it takes longer.
An MOT is even more predictable than a kitchen. The procedure runs off of an A4 check-list of items that must be inspected to ensure that the vehicle is roadworthy. No parts need to be removed or replaced to perform the inspection. It is highly predictable, repeatable work. No MOT has ever taken more than a day. If the inspection reveals a problem that must be addressed for the vehicle to pass the test, it takes a great deal longer and costs significantly more – often many times more than the original cost of an MOT.
You can run software development in the same way as these activities. Many organisations do. You can give out an estimate and then when you discover variability you charge more money and ask for more time.
Alternatively, you can drip-fund a project and have the option to trash it if the variability means it isn’t worthwhile. Rather than estimating, you assess what you are getting for your money. Instead of buying an entire album based on a review, you listen to the first few bars and decide if you want to keep listening. You carry on listening to more and more bars of music until you decide to stop listening or until the record finishes. Some albums are wall-to-wall awesome. Others aren’t worth much after three songs.
If one organisation offers to work with you and deliver software incrementally with the option to terminate at short notice, you can work together and get results quickly. In the time it takes one organisation to submit an estimate to another, many working increments of the product could have been delivered and the assumptions made could be in the process of being tested.
You don’t get all of this just from #NoEstimates – there are many other factors involved, including a rigorous process, a disciplined team and strong technical practices that you must have in place (and should have in place whether or not you decide to estimate).
The question posed by #NoEstimates is whether estimates are needed by your organisation, whether you could do something else instead of estimates and whether estimates give you a strong return on the investment you make in them. For my real organisation, undertaking work in the real world for real partners who pay real money; estimates are not needed.