What would my #NoEstimates book look like?

I mentioned on Twitter today that, at one stage a few years ago, I was close to writing a book on #NoEstimates. I was then asked what the theme of my book would be, in contrast to that of Vasco Duarte‘s popular and controversial book on the topic. The answer was way too big for Twitter, so I decided to write this post.

Despite the encouragement of many kind folks for me to write the book, I decided against it – partly because of work commitments, but partly because I didn’t want to risk becoming associated to the hashtag as a brand (I’ve kind of failed with that anyway, but hey ho!).

I was also wary of developing a bias toward whatever ideas made it into the book. I always want to remain as impartial as I can to respectful critique of my ideas, as well as new and challenging ideas from others, and putting my current opinions down in a book would give me a vested interest to defend them. With blogging there is the space for opinions to evolve relatively safely. For instance, my views have evolved significantly on SAFe since my 2012 rant piece, and they have similarly evolved on #NoEstimates.

All that said, if I were to write a book on the topic, what would it look like?

While there are many cross-overs in my ideas and opinions with those of Vasco, who (with far more bravery and commitment than I could muster) did take the plunge and write a book, my book would certainly come at things from a different angle.

Right from when I started blogging and speaking about #NoEstimates around 5 years ago, the most interesting aspects of the topic to me were less about the actual act of estimating and more about the dysfunctions surrounding it. I actually have no issue with estimating (I even enjoy estimating! – shhhhh), and the angle of “estimates don’t work” is not one I subscribe to.

But there are certainly dysfunctions. Ask any audience at a software conference – or managers and teams alike at almost any software organisation – if they have any problems with estimation in their company. The energy in the room immediately changes to one of awkwardness.

Make no mistake, software folks have major issues with estimation.

This is even more interesting when you consider that organisations are supposedly trying to leverage the benefits Agile Software Development – iterative and incremental delivery of value generating software, with the ability to quickly jump on and deliver new ideas for the customers’ competitive advantage – but are struggling to adapt their planning and scheduling techniques accordingly. How do we keep to schedules now that we’re doing this Agile thing? – they ask. How can we ensure we meet our business goals if we’re focusing on customer goals? It’s no surprise that “scaled Agile” frameworks such as SAFe and LeSS are gaining popularity.

So, with that precursor, here are some of the topics I would explore in my hypothetical #NoEstimates book. They are in no particular order, but I have separated them into two different perspectives – that of the provider of estimates and the requestor.

Provider (e.g. developers, teams)

• Shooting yourself in the foot
  Not incorporating appropriate levels of uncertainty into an estimate (e.g. giving a precise date when a set of scope will be delivered, saying a precise set of scope will be delivered on a fixed date, not calling out risks/assumptions/issues/dependencies as part of the estimate, etc.)
• Not revisiting an estimate
  i.e. not monitoring progress toward the goal upon which the estimate is based and revising the estimate accordingly
• Not understanding/asking for the reason behind the request for an estimate, and thus providing the wrong kind
  This is a problem for the requestor also (see below)
  e.g. “How long will this take?” might indicate a need for a relative comparison of two pieces of work for ROI purposes rather than a lead time assessment of one piece of work
• Being solution rather than problem focused, so the wrong thing gets estimated
  This is a problem for the requestor too (see below)
  e.g. building an automated email system, integrated with MailChimp, when a manual email with no integration is all that is needed to deliver customer value and determine feature viability

Requestor (e.g. managers, business stakeholders)

• Treating an estimate as a commitment (i.e. “you said it would be done by today” mentality)
  Likely to be an issue with the estimate not incorporating the appropriate level of uncertainty, as described above, or management not allowing it to
  Leads to a situation where everything has deadlines, most of which are arbitrary, so real deadlines don’t get prioritised and treated as such
• Not understanding the devastating effect of queues on lead time
  Queues are typically the biggest contributor to cycle time in the current software product management paradigm
• Not understanding and addressing other causes of variability
  Such as volatile teams, too many projects in flight (WIP), complicated technical/schedule/other dependencies
  Predictability comes from having a predictable environment, not from making predictions – I’ve likened this in the past to the Shinkansen bullet train system – building a network for predictable, high speed trains rather than trying to make trains faster or more predictable
• Treating effort estimates as calendar time
  A symptom of queue, WIP and other variation ignorance, above
  “It will take 6 weeks” is often a best-case effort estimate, where many assumptions are made
  The actual time it will take (without compromising quality) is typically way longer, even if the actual effort on that work item accumulates to just 6 weeks
  The relationship between effort and cycle time is often referred to as “flow efficiency”, and is an interesting factor to consider when discussing this topic – given how low flow efficiency is in your typical software development organisation
• Poor/no prioritisation
  With no actual order/sequence of desired work items, or one that changes constantly, it is very difficult for teams to make reliable estimates or sound trade-off decisions
• Ignorance of cost of delay
  If economic urgency is not incorporated into work prioritisation, work will become urgent when it is too late to trade off other commitments – this causes compromises in quality and predictability, and means deadlines are more likely to be missed
• Not understanding/asking for the reason behind why they need to make a request for an estimate, and thus asking for the wrong kind
  This is a problem for the provider also (see above)
  The requestor might also be the provider for another requestor (e.g. boss or client), so there can be a chain of misunderstanding
  They need to know why they need the estimate, and what kind, so they can give this information to the provider and have a productive dialogue about the best approach
• Being solution rather than problem focused, so the wrong thing gets estimated
  This is a problem for the provider also (see above)
  e.g. asking the team to estimate how long it will take to build a fully fledged reporting system when there is a far simpler and quicker way of giving the customer what they need
  This not only reduces predictability but also removes the team’s ability to get value to the customer (and thus the business) sooner
• Asking individuals and teams to be predictive beyond a short 1-4 week timespan rather than using empirical process
  Due to the complex nature of product development, teams should only estimate individual backlog items and forecast how much they can do in a short timespan (e.g. 2-week sprint/iteration)
  For batches of items beyond this short timeframe (e.g. releases), empirical forecasting using “yesterday’s weather” should be used to answer “how long” or “when” questions, not asking developers
• Asking for development estimates before a value and capacity assessment has been made
  How long a feature or project might take is utterly irrelevant if the anticipated business value of building that thing isn’t high enough compared with other opportunities, or there will not be capacity available soon enough to do so
  Yet often the requestor takes a back-to-front approach and wants to find cheap/quick options, or ones that will fit into a pre-defined schedule, rather than doing their homework with understanding value and capacity
  This leads to developers being constantly interrupted to provide estimates for low value work they may never do or, perhaps more worryingly, doing lots of low value work because it is estimated to be cheap
  On a related and ironic note, the higher the anticipated business value, the less it matters how long the work would actually take (assuming a standard cost of delay profile and that the value can be generated early enough to fund the development team) – a higher precision estimate (and actual) is needed when there is a lower margin between R (business value) and I (cost of the development team)
• Not allowing a truly iterative approach, rendering the use of experiments by teams to “buy down” knowledge (and reduce risk) impossible
  Strongly linked with being solution focused (see above)
  If the team cannot iterate to solve a problem, they may be locked into building a solution which is later learned to be an incorrect one
  When the customer inevitably changes the requirements due to the emerging information, the organisation might be too invested in the current solution to throw it away (“sunk cost fallacy” comes in here), thus scope grows and expectations become misaligned with reality

I’m sure there are far more #NoEstimates topics I would cover in my book, but stopping short of actually writing it I think I’ll end here :).