The Pragmatic Bookshelf has recently published an article by Ron Jeffries, Estimation is Evil.

I didn’t enjoy it for a number of reasons. The word evil turns the article into a religious argument and sensationalizes it needlessly. I would have preferred to see a model allowing us to calculate the economic value of estimation, a way to see how it can be negative in some cases, and a case study where it turned out to be negative. Besides, I wasn’t even sure the author wanted to make an anti-estimation point as he spent a large portion of the article explaining how to decompose a big unknown into estimable chunks and argued that estimation is essential to selecting work from the product backlog into the iteration backlog. He also devoted the middle third of the article to how the Chrysler C3 project should have been chartered, which seemed tangential to estimation.

Something interesting happened when a colleague of mine sent the article to an internal mailing list of managers and Scrum masters, mostly new to Agile. The mailing list, usually quiet, came back to life as several people felt compelled to write to their peers with their detailed interpretations of the article. Good for them, but most of what was written resembled blind people touching an elephant.

The Elephant In The Room Is Risk Management

If I were to reduce Ron Jeffries article to one paragraph, it would be the one where he says, spot-on, that “the very beginning” is the worst possible moment to make decisions about “all” “requirements.” (This point has nothing to do with estimation, but you’ve already got my point about it.) It shows the relationship between information, decision-making, and risk.

When the decision is forced at the point when the minimum amount of information exists, it carries the most risk. If we defer the decision until more information arrives or somehow create more information before the fixed decision point, we can reduce risk. Estimation is but one possible source of such information and it may be unreliable, expensive to obtain or redundant in the presence of information supplied by other sources. We must discover and pay attention to other sources of information and remember that the goal is not to obtain as much of it as possible, but to make a decision and reduce risk.

The main risk-management modes are: (a) avoid, (b) reduce, (c) transfer (insure), and (d) retain. We can systematically use information arrival to (a) make some decisions risk-free so the question of avoidance becomes moot, (b) reduce other risks, (c) make insurance cheaper due to the risk reduction, (d) make the remaining risks acceptable.

The best moment to predict the SuperBowl XLVII winner was at the end of the game. Predicting that the Baltimore Ravens would win it before the playoffs was a much riskier decision. The Ravens were the fourth seed in their conference and eight of the twelve playoff teams had better records. The probability of a loss was significantly greater than 50% at that point. As the playoffs progressed, information arrived continually and it reduced continually the risk of this bet (bookmakers’ odds, being a fairly efficient market for this particular type of risk, reflected that). After the Ravens’ final defensive play, the risk was completely gone.

You Cannot Bet On the SuperBowl After It’s Over

Of course you can’t. But that has everything to do with bookmakers’ business model (to make money, they need you to carry bigger risk than theirs, so if you carry no risk, they can’t accept your bet) and nothing to do with our ability to use information to inform risky decisions.

Move decision points to the right on the time axis (deferred commitment) and move information arrival points to the left.

Malleability of Software Creates New Risk-Management Opportunities

The last bit of advice may sound difficult to implement in many areas, but many more opportunities for it exist in the world of software. Many Agile engineering practices can fasten information arrival. For example, continuous integration, if done right, can produce information on our product’s integration status tonight — as opposed to a month later. Agile management practices (and engineering practices can strengthen them) can help defer decision points. For example, if a team delivers working software every week, as opposed to every month, decisions about what to select from the product backlog into the iteration backlog can be made three weeks later — and with the benefit of all information that arrived during those three weeks. The difference between potentially shippable and shipped can weeks’ or months’ worth of information — and all the risks the business has to carry that are intertwined with the information.

I have done a lot of work in Service-Oriented Architecture over the years and observed how many technical and business risks arise at integration boundaries. I have found that the appreciation of continuous integration as a primarily social, rather than technical, practice; personas; specification by example; and James Grenning’s learning-test technique (which he describes in the chapter that he wrote for Robert C. Martin’s Clean Code book) are all excellent tools for discovering tomorrow’s problems today. Risk thinking combined with appropriate technical practices simply make the difference between predictable delivery and panic. I have also observed that many ignore this and pay the price.

Lean And Not So Lean Enterprises

The second part of Ron Jeffries’ article that stood out for me (and again it has nothing to do with estimation) is his story of Agile’s first successes and its first failure with the Chrysler C3 project. Jeffries explained how the way the C3 project was chartered — as a complete replacement of Chrysler’s existing payroll systems — set it up for failure.

Every time we start work — on a large project, a small project, a user story, a feature, or an epic — it is a transaction, in which two sides exchange risk. A lot of such transactions happen in the software industry every day without any due diligence, in other words, consideration of all risks involved and how they can be managed with the help of information.

Whether they see it that way or not and whether they like it or not, the Vendor and the Client are tied together in a Lean (or not-so-Lean) Enterprise. The Vendor promises to deliver something valuable to the Client, using their unique expertise; while the Client, using their unique expertise, plans to add more value to deliverable and deliver the total to their Customer. It’s the same value stream. If the Vendor fails or falls short, the Client’s plan fails as well. They trade risk when enter the transaction.

Very often, all consideration given to this risk fits in one sentence: “This client requires a fixed commitment to the deliverable.” Another way is “a more Agile approach.” An assumption is made that the interpretation of all risk information can be encoded in a “groomed”, prioritized backlog and then the Product Owner is vested with God-like powers to produce a prioritized order every two weeks. When Wall Street types use this sort of “risk management” with our money, you know what we all want done to them.

Ron Jeffries tells us a really valuable story how Chrysler, by choosing to charter the C3 project one way over another, unwittingly underwrote a huge amount of risk and, after a string of successes, ultimately footed the bill for the failure.

Conclusion

I don’t find the back-and-forth estimation debate useful. Estimation is only one of many information sources involved in making decisions and managing risk. The real question is how it factors into the decision you have to make today.