Sunday 29 June 2014

Estimates: Lies and Guesses?

Terry Bunio has already written a blog post on this Are #Estimates Lies? #NoEstimates. But I like to give my point of view on this topic as well.

To make a long story (blog post) short: "Estimates are not lies and guesses". There, you can stop reading here if you like :-)

Still here? I'm glad you would like to read more on my thoughts on this :-)

I hear that these statements are something that the #NoEstimates "community" claims to say or hold true. I haven't actually heard so much about it, but if it's true I would like (as a person thinking that the ideas behind #NoEstimates are good) to reject these statements - if so. But... there is a grain of "truth" in there... There is a reason why someone would call them "lies" or "guesses". Let me dwell on it.

Estimates are not lies or guesses - in the unicorn world! :-)

If you look at the pure definition of the word "estimate" (Merriam-Webster) you can see that it's not about guessing or lying. In the the definition you see words like "judge", "tentatively", "roughly", "approximate", "general".

But is this really the only usage of it, in the world of software development? Rhetoric. No.

And this is what #NoEstimates are trying to address. And this is where I think that #BetterEstimates and #NoEstimates share the same "interest". Maybe, in the end, we share the same solution to the problem: Communication! And in "communication" I put in words like "honesty", "transparency", "forthrightly" etc. Things that make communication meaningful and without "smell". Ok, maybe you should never be 100% honest etc? There might be situations. But you get it, nothing is ever 100% "true" or "false".


How does #NoEstimates fit?

In my opinion, I think it fits as a "topic" in this discussion about "dysfunctions" or "smell" associated with estimates. I see the hashtag as a "prefix" or an "abbreviation". I don't seem to get much throughput there, maybe I'm seeing things wrong? What do I know... But it's still my opinion, and I hold myself the right to change it later on, if someone points me at better :-)
But let me explain a bit.

Guesses

Sometimes I actually have no idea on how long time I think it's going to take when asked "How long..?" or "When..?". Usually it's because it's too vague or it feels too "big" to give a credible judgement - or anything else. 
The most honest thing is then to say that: "I have no idea" (or similar) (and when I do, we usually stop discussing estimates).  But when we're doing planning poker, or something else, it might not be easy to say that. Or when faced with some types of customers (you know which ones I'm talking about... :-) ). There's then a risk/chance that you do something that is more comparable with a "guess". Sometimes maybe the planning poker session is "forced" with: "We don't have time to discuss the details here, we must come up with a figure tomorrow" - i.e. "forced" to guess. 
Then I think #NoEstimates fits as #NoneOfThoseEstimates.
Sure, it's "bad management" or DDSTOP. But it fits the conversation, in my opinion. Like: "STOP!" or "NO!" (#No!Estimates?).

Lies

Sometimes, when I estimate, that estimation magically turns into a deadline. I.e. there is no "real" deadline (like market window, synchronization with other things etc), the estimate becomes the deadline. As in "We think we can pull this off in X sprints/iterations." and looking at the calendar that will occur at December 6. And the date is communicated up to the CEO (or whatever).

And in other times, estimates are "gamed". Like "Really that much!?" or "You have to cut that!". Usually in some "bidding" context. But I have actually heard customers say that directly faced with an estimate (and there are other reasons, than the estimates, why they say that).
And in other times, estimates are used because someone "above" needs a number to pass up the chain.
Etc...

In these scenarios you could actually call the estimates more like "lies" than "judgements".

Sure, again it's "bad management", "bad communication" or DDSTOP. But it fits the conversation. Again: #NoneOfThoseEstimates or #No!Estimates.


TL;DR

There are lots of other dysfunctions associated with estimates. All fits the #NoEstimates hashtag. Does it then mean: "Stop all estimations!"? Of course not.

And #NoEstimates also speaks of some "paradigm shift" on how both business and IT approaches software and how it is looked upon. But that's another topic :-)

But, #NoEstimates are centered round the fact that estimates are good if they are valid and used for the correct reason. No one thinks otherwise.

4 comments:

  1. Very good post exploring the potential dysfunctions that turn Estimates into a practice that removes value from the software development process.

    There is, however, one angle that you did not consider but I believe adds to the discussion. That is the angle the contribution of the estimates to the development process itself.

    Even if the estimates were accurate, insightful, honest, etc. we have to still ask: but are they adding value to the software development process, i.e. the process of delivering value to the final beneficiary?

    We hear the following from people who think Estimates add value:
    * They foster discussion and agreement (yes, but maybe too early? or the wrong kind of agreement - because of the dysfunctions you describe above; that agreement adds "strength" to the plans and therefore makes it harder to change them?)
    * They allow the buyer to define the price: If so, which price? the right price, or the price that results from a negotiation that has little to do with the value we want to deliver to the final beneficiaries? Does the negotiation on price (or time) add or detract from building trust?
    * They allow the buyer to decide between options A and B: are those options Visions and experiments that need to be validated in the market? or are they "solutions" (which we can then estimate) that have not yet been validated to deliver value to the end beneficiary?

    In summary, even when estimates are not "gamed", what are their consequences. Their unintended consequences? By understanding those consequences we can then build an argument for the "right use" of estimates, but without understanding the consequences we are stuck in a tool discussion (yes, estimates are only one tool to achieve certain goals). Tool discussions maybe fun, but they don't bring our software development community forward.

    ReplyDelete
    Replies
    1. Thanks for comment Vasco!

      I agree. Estimates are "muda" in a lean sense. But I felt it was a little off topic. I wanted to focus on the "lies" and "guesses" topic :-)

      Delete
    2. But to try to answer your question. Isn't that solved with *communication* as well?
      If that's how you feel, tell customer! Or..?

      Delete
  2. It's not the developers the estimates are for, it's the business. As stewards of the customers money, the developers should see it as "value added to the project," to be able to tell those paying for the delivery of value - how much, when and what. Just like anyt other provider of value from house painters, to hardware engineers, the car mechanics. The excuse that the customer doesn't know what done looks like is no reason not the elicit further that information to build a credible estimate of the work to be performed in exchange for the delivered value.

    Until that is understood the notion of #NoEstimates will be unresolved.

    ReplyDelete