No Estimates Anger
What is it about “No Estimates” (or indeed, #NoEstimates) that gets people so angry? I had a great time last night at an open space discussion on this topic. Most of the room were using relative sizing, a small number used estimates – but as a group we worked out what it would take to get away from estimating without throwing away the value we might get from them.
If you are honest, you’d be able to create a list of pros and cons for estimates. You might title the headings “benefits” and “harms” perhaps? What we are aiming for is a way of getting as many of the benefits and as few as the harms.
What we concluded was that there was a relationship between regularly delivering quality releases, building trust with the business or customer and a drop in demand for estimates.
Unfortunately, when I posted this conclusion on social media, it caused some medieval reactions – which I hope to answer here (names not included, because I don’t believe these individuals should be blamed for being scared of change and for not understanding a topic they clearly don’t want to understand).
Telling a business stakeholder “I can’t say when I’ll be done until I’m done” confirms the worst of IT stereotypes
You don’t get to a situation of #NoEstimates by using this kind of language. If you say “I can’t say when I’ll be done until I’m done” doesn’t help to convince anyone that estimates may not be required (perhaps that is why it has been selected for use in this straw man argument).
On day one, in a low trust environment people want assurance. To give them this assurance, start delivering early and often. This will build trust.
#NoEstimates posits that we can tell the CFO, “staff my dev team for n months, & we’ll deliver something. You’ll love it, trust me.” Bzzzzt.
Again, although I suspect this is another straw man argument, I’ll cover it. If you said to a customer “fund me for two weeks and I’ll give you a release containing the first couple of features, then you can opt to continue funding or end the contract”, would that appeal more or less than “here is an estimate that says I can complete the project in six months, give me the money and I’ll send you a CD in six months”.
And then I realised the problem.
People must be interpreting the fact that “some teams have found that they don’t need to use estimates” as “YOU must stop using estimates”.
This is why they are getting quite angry and upset (and possibly why they have decided to tell me that I MUST be doing estimates, even though I’m not).
So here is my position on this.
I have found that as trust increases, many of the negative reasons for estimates disappear and many of the positive reasons for estimates are solved in other ways. Because there is so little value left in them, estimates just stop being needed.
You shouldn’t be aiming for #NoEstimates if you are operating in a low trust environment (and this includes an organisation working in a high trust environment taking on a new customer who doesn’t trust them, for example). Instead, you should be aiming to build trust.
If you successfully get to a high trust state – which takes a whole lot of hard work, regular releases, quality releases and transparency – then you may want to take another look at the no estimates hash-tag. In the meantime, don’t be too concerned with how people drive on tarmac if you are still driving on dusty roads.