Why use No Estimates? Focusing on what matters

As I sit here with my red-wine glass and contemplate the #NoEstimates discussion on Twitter for the last few days I can’t help but think that there is a key difference in how I look at Software development when compared with some of the Agile Pioneers like @RonJeffries, or @TOtherAlistair. And I want to explain some of those differences. They are too important to our profession to go undiscussed.

Tired of the same old house

First, I’d like to state that I don’t think that the construction analogies are of use anymore. It was ok to use that in the beginning of software development. Those were the most well-researched projects at that time. However, today we have a sufficient body of knowledge to warrant research and analogies from within our domain.
Also, while I know some will claim this is a gross generalization (and it is), construction is not in the Complex domain, while software is. If you follow any of the #Cynefin discussions you know that approaches suited to the Simple domain are not suited to the Complex domain. In my view most construction projects are in the Simple domain (not all), and most software projects are in the Complex domain (again, not all).

Change the context, or your project will fail

One other thing that makes me focus on the #NoEstimates approach to software development is my realization that the existing context is not well suited to software development. The context where Estimates are mandatory, and you will be held accountable for years to come; the context where teams are asked to “commit” to a plan that they know very well may not be possible to achieve; the context where we base all of our approaches on our belief that predictability is easily achievable in long term software development efforts.
I want to promote the #NoEstimates approach because I want to change the context surrounding software development. I’ve learned enough to know that software estimates don’t work, and I know a better alternative!

It’s the customer, simply!

My approach to implementing #NoEstimates is centered on discovering value, because I assume that I don’t have all the answers up-front. Since I recognize that I don’t have all the answers, I’m ready to accept that the definition of the work to be done will change (not might, will!). So I focus my energy on discovering that most valuable work to be done. This requires that I focus on defining small increments of customer-value (instead of large chunks of “work”). I use User Stories (and Epics and Features) to help me build a vocabulary that leads to a constant dialogue around value at all levels in the company. And I’ll let you in on a secret: Sales people don’t like estimates either! Why? Because they want something out ASAP and if you tell them that they need to wait another 6 months they will hate you. Estimates or no estimates. Sales people understand something intuitively: they need value to sell. The longer they wait the more uncertain they are about that value. It is that simple.

I believe #NoEstimates is a better way to manage software projects

It is this simple. I’ve used #NoEstimates, I recommend #NoEstimates and I use #NoEstimates in my own work. Discover the value, deliver the value in the thinnest slice possible, rinse and repeat.
There are many concrete ways in which you can generate dialog around value, and ways in which you can enable very thin slices. Some have been published (Naked Planning by @arlobelshee being one example), others are just being discovered and experimented with.

Estimates have failed, are you looking for alternatives?

The Estimation approach to software development has failed us for too long. It never really worked in the projects I participated in (and I used it a lot) and we always ended up using the only available tool to us to meet our deadlines: manage scope.
So I recognize that an approach focused on helping companies and teams zero-in on the valuable parts of the their projects and delivering those first, helps in Risk Management, focuses on welcoming the changes we know are coming instead of sticking to the plan (estimates *require* a plan, otherwise what are you estimating?), and more importantly it requires customer collaboration for it to work. Unlike Estimates that focus on contract (the estimate) negotiation.
How to use #NoEstimates to manage your project? Take a look at an example I published a few months ago, and the data that supports this approach. After all, #NoEstimates is firmly grounded on empirical data collected over many (22 at last count) projects. Again, unlike estimates which by definition are not based on data. Estimates are rather guesses about future events.
Have you experimented with some form of #NoEstimates? Leave a comment below. Let's keep the conversation alive.