I’ve spent the last two blog posts introducing the #NoEstimates movement, first discussing what it appears to espouse, and presenting some initial reasons why I reject it. I then covered the many solid reasons why it makes sense to use estimates in software development.
This time, let’s go through, in detail, the various arguments put forward commonly by the NoEstimates advocates in their opposition to estimates and in their explanation of their approach. Full disclosure: I’ve attempted to include the major NoEstimates arguments, but this won’t be a balanced presentation by any means; I find these arguments all seriously flawed, and I’ll explain why in each case.
Here we go, point by point:
- “Estimates aren’t accurate, and can’t be established with certainty”
Let’s use Ron Jeffries’ statement as an example of this stance:
“Estimates are difficult. When requirements are vague — and it seems that they always are — then the best conceivable estimates would also be very vague. Accurate estimation becomes essentially impossible. Even with clear requirements — and it seems that they never are — it is still almost impossible to know how long something will take, because we’ve never done it before. “
But “accurate” is simply the wrong standard to apply to estimates. It’d be great if they could be totally accurate, but it should be understood at all times that by nature they probably are not. They are merely a team’s best shot, using the best knowledge available at the time, and they’re used to establish an initial meaningful plan that can be monitored and adjusted moving forward. They’re a tool, not an outcome. As such, the benefits of estimates, and their contributions to the planning and tracking process, exist even without them being strictly “accurate” per se. These benefits were itemized in my last post.
Knowing the future precisely isn’t what estimating is about, actually. It’s a misunderstanding and a disservice to think it is. Here’s why.
Perhaps we can’t really predict the future, yet we have to, every day. The reality: anyone running a viable business has to do exactly that, predict the future, in multiple ways. The only way to live life, much less run a successful business, is to achieve competence in what amounts to predicting the future. Business leaders seldom can wait for perfect information to emerge before making decisions. Every business plan ever developed essentially entails “predicting the future” and figuring out how/what to do: what markets to enter, what products will be viable to offer, how much raw materials one should have on hand, etc. Essentially, with everything we do, we’re implicitly weighing the world of options, risk, cost, value. Yes, we’re “predicting the future.”
Can we always be right as we do this? Of course not. Yet that seems to astonish and dismay the NoEstimates advocates. Case example: a major NoEstimates advocate discusses planning, strategy, and goal-setting, only to make the odd statement that “all these techniques require perfect, 20/20 foresight.” Such a view is quite misguided. In fact, there’s no plan, no estimate, no forecast that is ever intended to provide perfect, 20/20 foresight. None. To believe that it would or could, in fact, reflects a major misunderstanding of planning, estimating, and forecasting. In reality, all those approaches are simply techniques that one uses as a way of tilting the odds in one’s favor, and as a means to monitor progress against expected results and react accordingly.
Not to mention: from the point of view of working with business stakeholders, the quickest way to demonstrate one’s lack of business savvy in the real world is to scoff that no one can possibly predict the future.
- “Estimates are misused by management”
Amazingly, that’s not especially useful. As Glen Alleman wrote, “anecdotes of failed or bad management processes cannot be the reason for abandoning those processes.” Hearing endless examples of misuse is like watching someone go into lengthy detail about all the ways you can get an infection in hospital, with the end goal being to argue we need to eliminate hospitals.
And by the way, it underscores the weakness of their argument when NoEstimates advocates cite the number of people who retweet an anti-management Dilbert strip as a good metric to support their case.
“Estimates get turned into commitments”
NoEstimates advocates emphasize (and lament) how estimates often are interpreted as a commitment or even a target. While this can be true and reflect a misuse of estimates, one also needs to recognize that commitments do need to be made in business, and that they always come from what amounts to an estimate, in some form, that a particular goal can be successfully met. NoEstimates people talk about drip funding, and promise stakeholders that they “can pull the plug quickly when necessary“, but at the same time, they say things like “we can commit on that part which is known: mostly tomorrow, maybe the day after. Longer commitment is not possible.” Or, “I prefer to commit only to what is needed in order to validate or deliver value to the customer now”. (Emphasis provided)
What, development won’t commit on any item past the day after tomorrow?! Business people will often rapidly conclude (fairly or not) from such anti-commitment talk that the people saying such things must actually have little or no idea or confidence in what they can deliver and when. And no real skin in the game: minimal planning, close to zero commitment. Trust deteriorates rapidly as a result.
Commitment and goal-setting matter for internal reasons as well. Without solid commitments to steer towards, even a competent, motivated team can drift along and not prioritize well: yak shaving, for example. Commitment and clear targets tend to focus both the mind and the daily “to do” list. It’s frankly a wonder that this would even be a source of controversy.
Estimates are just one part of an iterative, collaborative process of evolving a meaningful, achievable plan, getting everyone on the same page, ensuring (to the maximum degree possible) that the major necessary chunks of work have been clearly and transparently identified up front, alternatives identified and openly discussed, and, finally, yes, appropriate commitments forged. That process is not dastardly or underhanded or abusive or manipulative, it’s normal and desirable. There’s nothing wrong with it.
This is an odd instance of somberly intoned faux-wisdom, skewed logic, akin to something like this: there’s no need to drive safely; we just need to avoid having an accident. Similarly, estimates serve as a time-honored means to the end: in fact, their purpose is actually to enable decisions. Without them, you’re making your decisions blindly, without full consideration of their likely impact. If all we truly need are decisions, we might as well flip a coin.
More analogies come to mind in response: having a map doesn’t guarantee you won’t get lost, so why bring one. A weather forecast doesn’t guarantee it will or won’t rain, so why even consult it. But of course, no one ever expects those approaches to be infallible; their purpose is to increase your odds of anticipating and/or dealing with the unexpected. The above NoEstimates question reveals a strange conception of “guarantee”, and in fact betrays a certain kind of reluctance to accept ever being wrong. But as with the above points about estimates being “accurate”, an estimate is also never a “guarantee”. It’s an informed best shot. Equating any estimate to a “guarantee”, or objecting that it isn’t one, shows great lack of understanding what estimates are or how used.
Again going back to basics: estimates won’t necessarily be “accurate”. They’re not plans, or commitments, or schedules, and (most especially) they’re not guarantees. Estimates provide useful input to creating such things; they’re an attempt to “tilt the odds” in the favor of success. If you’re looking for anything to provide you with a 100% guarantee, you shouldn’t be in business at all.
Here’s what happens: if your estimates and your plan, closely monitored during the course of your project, reveal unexpected variation and/or gaps, you adjust appropriately. The NoEstimates gleeful consternation that plans don’t typically go completely as scheduled in every aspect is simply unfathomable. Every project plan ever made ends up having variance from the plan. Having a plan is what lets you react and adjust in the first place. If there is no plan, no target, there’s nothing in particular to push you into having to adjust; you just keep coding away.
As for bias, it seems way better to get bias out explicitly on the table, through open declaration and active group scrutiny of estimates, than to have it enter through the backdoor silently.
- “Estimates make it harder to change the plan”
Why would that possibly be the case? Don’t let that happen! Estimates should be getting recalibrated constantly, feeding in any new information and (quite possibly) changing the approach, the timeline, the staffing, the scope of your overall effort.
As new information arises, any plan can be changed, assuming that there’s a sober evaluation of the pros and cons of doing so. Note that there’s always a healthy tension between adhering to a game plan vs. panicking entirely and ditching the plan as soon as the first obstacle rears its head. Part of the role of a skilled product manager, and of management in general, is treading that narrow line, deciding when and how to react and regroup.
NoEstimates advocates often paint their critics as inflexible, “big design up front“-oriented, waterfall-obsessed dinosaurs. That’s a straw man. Analogy: if you’re taking a trip, there’s a very happy medium between “we’ll head east and completely wing it as we go” vs. “we’ll plan every stopover to the nearest second, up front.” In other words, you plan the trip, to the degree you deem appropriate for your needs, and you adjust appropriately as new information hits your radar. Some plans will need to be changed in major ways; others will absorb the inevitable minor variances and be (broadly speaking) just fine as initially defined.
- “Estimates take too much time.” “Estimates are expensive to gather.”
It depends. It’s always easy to trot out egregious straw-man examples: don’t spend more time estimating etc. than “doing work”, one NoEstimates advocate has been known to tweet, as if that’s a common scenario. Of course it isn’t: time spent planning needs to be weighed (as with everything in business) from a cost-benefit perspective: if I’m about to spend $10 million on a software project, it’s worth spending six figures constructing estimates and a workable plan against which progress can be measured. Align the time and expense of estimating with your “value at risk”, in other words. This, again, should be common sense.
This may be the weakest NoEstimates argument of all. Of course estimates are not required. A driver’s license isn’t strictly required to physically drive a car; a sterile environment isn’t required to operate on a patient; having a referee isn’t required to play a game of soccer. Equally, doing upfront planning or even using common tools like bug tracking or source code control aren’t required to deliver software; I’ve (unfortunately often) seen teams go without such things. But just like a reasonable level of planning and the use of appropriate tools like source code control, rational use of an estimating process can indeed contribute meaningfully to overall high-quality, timely delivery of software capabilities for an enterprise. Pointing out that estimates aren’t required in order to code, as if anyone had been claiming they were, seems (quite intentionally) to miss the point.
OK, no, this is the weakest argument, because it’s not a bona fide argument at all. I really wish I could cite the specific better ways that NoEstimates advocates have proposed in lieu of estimates, but the declaration is usually formulated as above, vaguely, with nothing behind it. The only concrete “better way” that seems to get cited consists of drip funding for the team (“you can pull the plug whenever you want!”), story slicing of whatever piece of work is mysteriously judged as “most important,” frequent delivery of software, and then iterate/refactor. The need for estimates then disappears, or so claim the NoEstimates advocates.
None of that is intrinsically a bad idea for some development circumstances, but it’s most certainly not universally applicable. And it doesn’t answer the up-front questions that don’t go away: what will be the likely total investment we’re making to get the full capability we need? And when will we get that capability?
- “We’re not ditching estimates!”
Despite this now oft-repeated claim, the key NoEstimates advocates have yet to name any concrete examples of when estimates, in their view, actually are appropriate. As a result, NoEstimate’s claim not to be ditching estimates comes off as defensive, disingenuous, and insincere, considering the intensity of the diatribes they’ve delivered against estimating.
In truth, NoEstimates advocates appear to acquiesce to doing estimates only in cases where they are basically forced to do so, by unreasonable and/or unenlightened management. But this kind of grudging acceptance of the need to do estimates, while metaphorically holding one’s nose (“estimates are a smell of possible decision-making dysfunctionality“), is no way to win the understanding of or promote a strong collaboration with business people who have to grapple with uncertainty in their own areas every day. In fact, such a clearly insincere, pro forma acquiescence is also likely to fail to incorporate all the positive elements and outcomes that a high-quality estimating process would bring to the table.
So there you have it, the principal arguments raised by NoEstimates in support of their case.
One last installment will be forthcoming in this series, giving my “bottom line” assessment of estimates vs. NoEstimates.