Towards a more balanced list of content about #NoEstimates

Both my readers will have noticed there’s been a fairly large gap between my posts here, as life (picnic, lightning, and all that) has intervened. Like J.D. Salinger, however, I have continued writing drafts on various topics, and I plan to post more in the coming months.

My past posts here have often delved into a favorite theme of mine: that IT people tend to go to extremes, often rejecting something useful (an approach, a technology, a tool) simply because it has downsides. Such rejection is at times emotional and even self-righteous; we can get so caught up in it that we fail to look at a topic at all evenhandedly, let alone dispassionately.

No better case example along these lines has come along in the past year than the active and contentious #NoEstimates debate on Twitter and in the blogosphere. I’ll have a much more detailed post soon about my objections to the #NoEstimates approach overall (full disclosure: I’m one of its most vocal critics), but right now, let’s focus on one aspect of the relentless advocacy I see in the hashtag’s proponents: its lack of evenhandedness.

Specifically, proponents of #NoEstimates insist repeatedly and proudly that they’re “exploring”; recently, one major advocate tweeted out a call for links to posts about the topic (“I’m gathering links to #NoEstimates content”) so that these could be collected and posted. Yet, it turned out that only posts advocating one side of the issue would be included, even though the resulting list of links was then touted to people who might be “interested in exploring some ideas about #NoEstimates.” When challenged on this dubious interpretation of the meaning of “exploring”, the advocate then defiantly attached a disclaimer: “Warning! There are no links to “Estimate-driven” posts”. In short, making the exploration balanced wasn’t even remotely his goal.

Advocates can use their own blog for whatever purposes they want, of course. Yet, there’s an interesting split going on here: staunchly claiming to be “exploring”, while rejecting the inclusion of any summarizing or critical posts, and then sneeringly labeling all such posts as “estimate-driven.” There couldn’t be a clearer case study of IT black-and-white-ism, them vs us. Explore all you want, this behavior says, as long as you’re doing it on my side of the issue and on my terms. What, there’s a post that attempts to summarize both sides of the argument? Not interested.

As professionals, it’s basic table stakes that we be able to weigh all reasonable sides and perspectives in a business discussion. When I see reluctance or outright refusal to do so, I have two reactions: one, it must be a very weak argument indeed, to not be able to tolerate even linking to an opposing view; two, the argument’s advocates obviously don’t realize (or care) that these actions are reinforcing the sad stereotype of IT professionals as dogmatic, one-sided, theoretical rather than practical, disconnected from broader concerns, and unable to soberly weigh the business pros and cons of an issue.

Lots has been written on both sides of the NoEstimates debate, and anyone truly exploring this topic deserves to see the arguments laid out next to each other. Because here’s the deal: my citing your differing opinion doesn’t detract one bit from my view of a controversial issue; it strengthens it by showing a sincere desire to weigh your points fairly and counter them with reason.

So here’s a more balanced, quote-annotated list of NoEstimates-related links to juxtapose against the one-sided list of NE links posted regularly on the hashtag by the #NoEstimates advocates. It includes posts arguing both for and against estimates, although the latter side is represented largely transclusively, by linking to that existing and extensive one-sided list of advocacy posts. My criteria for inclusion here weighted strongly each author’s attempt to lay out and explicitly counter, with reason, the various points made by the opposite side. I especially favored “synthesis” posts that attempted to evenhandedly list the issues and assumptions operating in both camps.

Read and make up your own mind. But read both sides, and perhaps reflect a bit on how bizarre it is that one side seems to want you to read only theirs.

• Shim Marom, February 27, 2014. “Consolidating the #Estimates/#NoEstimates Debate”

Each argument, in favor or against the #NoEstimates proposition, will be listed and a statement in support and against the proposition will be provided. Whenever appropriate I will add further commentary where I will attempt to narrow the gap and articulate the assumptions arising from each or both arguments.

• Peter Kretzman, September 24, 2014. “The case against #NoEstimates: introduction and common sense“. First of a series of four posts.

Whenever there is any manner of management/business scrutiny (and there always is), estimates in some usually more explicit form are part of the landscape. In fact, pretty much all proposals to senior management will cover or evoke these specific questions in some way: “How much will this cost?” “When can we have it?” “What’s our expected benefit?” I’ve never seen these questions not get asked by the boards, the CEO, COO, and CFO of even smallish companies. They’re the most natural questions in the world when undertaking to have anyone do work of any substantial size in any domain. In fact, a board or CEO that didn’t ask these questions about a major pending project would be guilty of dereliction of duty.

• Glen Alleman, February 27, 2014. “Answers to Shim’s questions”.

Time to start looking for business value from our work efforts in building software for money. That means knowing the cost of our efforts to some degree of confidence before and during the project. Knowing afterward is simple and worthless.

• Troy Magennis, February 7, 2012. “All Estimation is Waste — Rubbish!“

Being skilled in why estimates are necessary and how to work with your business peers in offering solutions and opinion early during the portfolio and budgeting phase is the best way to change the executive management’s opinion of IT managers, returning IT to the hero status it so richly deserves.

• Glen Alleman, March 6, 2014. “Some more answers to the estimating questions”

Woody asks some important questions that have straightforward answers in the software for money domain. These answers come for the business side of a software development organization. It’s the business of software that needs estimates. … So here’s some good questions that have answers from the point of view of those paying for the cost to produce the software for the customer.

• Steve McConnell, August 18, 2015. “17 Theses on Software Estimation (Expanded)“

Overall, #NoEstimates seems like the proverbial solution in search of a problem. I don’t see businesses clamoring to get rid of estimates. I see them clamoring to get better estimates. The good news for them is that agile practices, Scrum in particular, can provide excellent support for agility and estimation at the same time. 

My closing thought, in this hash tag-happy discussion, is that #AgileWithEstimationWorksBest — and #EstimationWithAgileWorksBest too. 

• Keith Braithwaite, December 12, 2015. “Why I Have Such a Strong Reaction to #NoEstimates“

It seems as if the “no” in #NoEstimates doesn’t mean no. Or maybe it does. Or it might mean: prefer not to but do if you have to. Or it might mean: I’d prefer that you didn’t, but if it’s working for you carry on.

And the “estimate” in #NoEstimates doesn’t mean estimate. It means: an involuntary commitment to an unsubstantiated wild-arsed guess that someone in authority later punishes you for not meeting. Or it might mean estimate after all, but only if the estimate is based on no data. If there’s data, then that’s a “forecast”, which is both a kind of estimate and not an estimate.

“Control” seems to be a magic word for some #NE people. It’s said to them in the morally neutral, cybernetics sense but they hear it in some Theory X sense, as if it always has the prefix “Command and ”. This creates the impression that they have no interest in being in control of development, budgets, etc. Which might or might not be true. Who can say?

So not only are the #NoEstimates concepts all over the place, they’re discussed in something close to a private vocabulary—maybe more than one private vocabulary. This is not an effective approach to an engineering topic.

• Martin Burns, August 8, 2014. “Estimates Are Not Waste“

It’s the kind of thinking that often leads to Dilbert-thinking: that management must be incompetent idiots because they can’t do what we do, and we don’t understand (or even see) what they do. And leads people to create axiomatic, circular definitions for Estimating as A Bad Thing.

Which is often the kind of thinking that got us here.

It’s a variant on the power play of We should be in charge around here. It’s ugly. Don’t do that.

• Glen Alleman, July 17, 2014. “Open Loop / Closed Loop Project Controls”

When you drive the project in the absence of a desired outcome – the project goal – without units of measures meaningful to the decision maker, is like driving in the rear view mirror. It can be done, but you don’t know you ran over anything until you do.

• Ron Jeffries, April, 2013. “Estimation: The Best We Can Do”

The people paying for our work need to allocate their resources. They need to manage their cash, and they need to coordinate our work with activities and stakeholders outside our team.

To do this effectively, they need information on how long things take, which translates into how much things cost, and into how long it takes before we start getting our money back. They need information that we have to do this job well. The fact that our information is vague, flawed, and uncertain is not a reason to hold it back. We need to get the information into their hands, and to do it in a way that gives them the best chance of using it well.

• Troy Magennis, August 5, 2013. “Project estimations are throwing off our ability to properly plan out projects“

Extending “No Estimates” to all possible work is nonsense unless there is truly no option of altering staffing levels, or reordering feature priorities based on time to market. In the idea-rich software atmosphere, there is always more demand than supply.

• Nick Pisano, April 9, 2014. “Gimme All Your (Money) — Agile and the Intrinsic Evil of #NoEstimates“

The core arguments in Agile via #NoEstimates are an implicit evil because they undermine the essential relationships between the parties.  This is done through specialized jargon that is designed to obfuscate, the contingent nature of the obligation underlying its principles, and the lack of clear reasoning that forms the basis for its rebellion against planning, estimating, and accountability.

• Dave Gordon, June 2, 2013. “Thus I Refute #NoEstimates“

Complexity will persist in the face of all attempts to reduce it through simplifying assumptions. Few modern business problems are simple enough to reduce to a small number of decisions, which then drive all other activity. Apples falling out of trees are fine for explaining gravity to school children, but celestial mechanics has to contemplate multiple bodies. Similarly, modern business problems are not simply about software. And that is why we should devote our energies to improving the quality of our software development estimating methodologies, rather than advocating adoption of simplifying assumptions that don’t reflect a holistic view of the operating environment.

• George Dinwiddie, March 30, 2014. “Short Overview of Estimation”

While arguing against estimates, I found some residual benefit for estimation. From a business perspective, it’s quite valuable to project into the future to predict what might happen, and to make contingency plans, if needed. Making estimation less important does not make it unimportant.

• Dan North, August 8, 2013. “Blink Estimation“

With sufficient experience and the right mix of people in the room you can reasonably assess how this project is similar to, and different from, previous ones, and how much you should reasonably invest to realise the business impact associated with it.

• Jurgen Appelo, December 12, 2013. “#JustEnoughEstimates”

Big estimates and commitments are not safe-to-fail, but having no estimates or commitments is unworkable. … Not anticipating, and not estimating, is no option. It would mean we’d be no different than the rest of the natural world, merely adapting to whatever is thrown in our direction. We would stop being human.

• Fabio Akita, October 7, 2013.  “#noEstimates Debunked”

We estimate based on past knowledge. If we can’t out perform our past selves, how incompetent are we? I mean, we can argue that software is not predictable, and I agree. But making mistakes of orders of magnitude in recreating similar software only smells incompetence to me. Most of the software we produce are not brand new ideas, breakthrough new algorithms. They are really mostly the same: content websites, ecommerce, elearning, social networks, social commerce, forums, polls. Unless you work in research programs, what other kinds of different software did you do lately?

• Terry Bunio, Sept 17, 2013. “Why I believe in Estimates”

By Agile proponents recommending No Estimates they have eliminated a feedback loop across projects that provide feedback on how we plan and estimate. Other Agile teams can/will encounter the same challenges that another team faced, without a feedback mechanism that highlights divergence from an estimate or schedule. Without an estimate or schedule, the team may not even think of it as a divergence…

• Mike Harris, David Consulting Group, November 8, 2013. “‘No Estimates’ in Action: Our Thoughts”

Whether we like it or not, software development mainly takes place in a business context.

This brings two constraints to bear:

At the micro level, selection of the best option for any development problem has to consider effort (cost) and duration;
At the macro level, … at least part of the customer’s satisfaction will always relate to on-time, on budget. Hence, some form of estimation is not just management overhead but a development best practice.

• John Allspaw, October 25, 2012. “On Being a Senior Engineer”

Avoiding responsibility for estimates is another way of saying, “I’m not ready to be relied upon for building critical pieces of infrastructure.” All businesses rely on estimates, and all engineers working on a project are involved in Joint Activity, which means that they have a responsibility to others to make themselves interpredictable. In general, mature engineers are comfortable with working within some nonzero amount of uncertainty and risk.

• Jim Bird, May 30, 2013. “Estimating Might Be Broken, But It’s Not Evil”

While there is evidence that software development projects are getting shorter on average (because people have learned that smaller projects fail less often or at least fail faster), some problems are too big to be solved piecemeal. So estimating isn’t going to go away – most of us have to understand estimating better and get better at doing it.

• Magne Jorgensen, August 29, 2014. “What We Do and Don’t Know about Software Development Effort Estimation“

An apparent lack of improvement in estimation accuracy doesn’t mean that we don’t know more about effort estimation than before. In this article, I try to summarize some of the knowledge I believe we’ve gained. Some of this knowledge has the potential of improving estimation accuracy, some is about what most likely will not lead to improvements, and some is about what we know we don’t know about effort estimation.

• Patrick Koglin, June 18, 2014. (in German) “Why collective estimation processes are important”

Estimates are important …

so that requirements can be clarified
so that misunderstandings can be resolved at an early stage
so that there is transparency about deadlines and targets
so that task prerequisites and open issues can be clarified
so that all parties can arrive at a common commitment

• Ron Jeffries, February, 2013. “Estimation is Evil”

Why not start every product with a simple experiment? Do we think it’s pretty simple? Take a real product visionary as a product owner, and have them sit with a few developers for a week or two to build something. Then ask yourself whether to go ahead. Is this a bigger project, possibly taking six months or a year? Then build in two-week iterations for a few cycles. See where you are. If it’s good, go ahead. If it’s not, stop.

Seriously. Put a person who understands the problem right in with the people who understand how to solve problems, and solve problems in the order that seems most important. Ship everything you do right away. See what the users say, see what the market says. Adjust.

Are there “issues” with this approach? Sure.

• Matthew Heusser, November 5, 2013. “’No Estimates’ in Action: 5 Ways to Rethink Software Projects”

We’ll define #NoEstimates as running a software project without any human estimation process. If customers asks, “How long will it take?” that’s estimating. If they never have to ask, that’s #NoEstimates.

(See my rebuttal of this article’s points, at this link (registration required, unfortunately), and lightly edited as a comment on Heusser’s article as well. Update as of July, 2017: CIO Magazine has removed the comments on Heusser’s post. Here’s a link to the text of my comment.)

• Michael Wolfe, July 29, 2013. “Engineering Management: Why are software development task estimations regularly off by a factor of 2-3?”

Impossible to summarize, but worth a read, including the comments.

• Dan Milstein, April 23, 2013. “Coding, Fast and Slow: Developers and the Psychology of Overconfidence”

The key is that you first accept that making accurate long-term estimates is fundamentally impossible. Once you’ve done that, you can tackle a challenge which, though extremely difficult, can be met: how you can your dev team generate a ton of value, even though you can not make meaningful long-term estimates?

• Kurt Haeusler, May 20, 2013. “Pricing, And A Little Bit About Estimation” http://kurthaeusler.wordpress.com/2013/05/20/pricing-and-a-little-bit-about-estimation/

The other misunderstanding I see in the NoEstimates debate is that the ProEstimates crowd thinks the NoEstimates advocates are somehow refusing to answer questions like “How much does it cost?” and “How long will it take?”. This is quite false. As far as I am aware the NoEstimates crowd are attempting to answer exactly these questions using techniques with a higher level of professionalism and more reliability than guessing.