This article will answer the question and provide at least a few hints for conquering the boss' lament.

NoEstimates Means Estimates Aren't Bad, Just Not Essential

Woody Zuill, a development manager at Hunter Industries, introduced the #NoEstimates Twitter hashtag and addressed the concept in blog posts such as Doing Scrum Without Estimates. Zuill is quick to point out that, while he has experienced some success with the ideas at Hunter, they represent his own opinion. That might be wise, considering the large public pushback on the idea.

That pushback may be due to a misunderstanding. Zuill didn't claim that estimates are "bad" in all cases; rather, they're not always essential to the software development process. Alternative decision-making approaches are possible. In other words, while estimates solve a problem, what problem do they solve, exactly? What other ways are there to solve the problem? That's the discussion Zuill wanted to start.

Instead of arguing can/cannot, let's define estimates and look at some examples of where #NoEstimates is working, in the field, right now.

Woody Zuill made quite a splash with his introduction of #NoEstimates on Twitter.

For the purpose of this article, an estimate is "a length of time it will take to develop software, determined by human judgment and based on experience." There are many ways to do this. You can break the work down into chunks and add it up, you can look at a variety of similar projects to compare, or you can stick your finger in the air and guess. All of those are estimation techniques.

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.

Notice that this means we can still estimate the budget for the department, or the rate of customer adoption to do financial projects. The term #NoEstimates is specifically tied to humans using their judgment to predict development effort for a solution that have not yet fully developed.

Here are five ways to do just that.

1. Make Starting Amount of Money Small; Deliver Working Software Often

J.B. Rainsberger, the author of jUnit Recipes, points out that his first solo software project was just like this. Rainsberger made no promises up front, offering instead to show working software every two weeks - and also allowing the client to fire him with as little as two weeks' notice.

This technique may work best for outsourced projects. It also represents a significant amount of risk for the outsourced company, and minimizes risk for the customer. The team turns over working software - not designs, specifications or in-process code - that may have little or no value to the economic buyer.

This is essentially what happened with Chrysler's Comprehensive Compensation System (C3). The car maker dropped the existing project, already in progress, in order to "reboot" it as a project that would deliver working software every two or three iterations, each of which was two weeks long. For Chrysler, in 1999, that was a fast deployment process.

For internal projects with an existing team, a larger organization might want to look at another approach to #NoEstimates.

2. Fund a Pilot That Delivers Working Software; Then Use Modeling to Forecast Schedule

Imagine a high-functioning software team pulling pieces of work from a queue. If the effort involved for each piece of work averages within some reasonable deviation, the team can count the pieces of work accomplished per week and predict, in a sense, when the project will be done. (Management can also change which pieces of work are "required" to change the date.)

That may not be as easy as it sounds. To work, the amount of effort per feature needs to normalize, or approach a bell curve, and there can't be any "black swan" events lurking in the weeds. For example, bugs discovered late in the cycle may create extra work that's not modeled.

The team also needs a fair amount of data to do this kind of modeling. This typically requires a funded pilot with no defined scope. It might, however, be possible to pull the data from previous projects that were delivered with estimates - by throwing away the estimates and assembling predictions from data.

Troy Magennis, a former executive at Sabre Holdings and Travelocity, now with Focused Objective, has done some of the most prominent work in this space. Magennis has also developed predictive models that include complex elements like deviation, cycle time, defects/time for repair and so on.

Even without a complex model, most agile teams are capable of producing a burn-down chart that can answer the question, "Is this date and this scope possible?" Someone just has to ask.

3. Move From Contract Negotiation to Partnership

The Dynamic Systems Development Method, or DSDM, predates the agile movement. It recognized that, on most projects, people, money and time remain fixed. Quality is something that probably should be fixed, too, as non-working software doesn't actually work. The one thing most flexible is actually scope.

Most planning work is eliminated here in favor of developing high-level goals in collaboration with the customer. The team promises to deliver something on week 30, and the two groups meet every week or two to show progress and design the next step.

If that sounds a bit like a fairy tale, I understand. At the same time, that's essentially the business model of Menlo Innovations. Based in Ann Arbor, Mich. and founded by Richard Sheridan, former VP of product development at Interface Systems, the Menlo team may establish scope at the outset of a project, but it lets the customer adjust and plan specifics each week.

By the end of a budget period, the customer could steer to a place very different that the original goal. The customer gets what it needs in the moment - not what it thought it needed six months ago.

A great deal of portfolio management efforts consist of trying to figure out what projects will be done in what time, how many contractors or new hires are needed to make the timelines line up and that sort of work. Matt Barcomb, vice president of product development at Taxware, suggests that might be overthinking it.

According to Barcomb, most IT organizations can usually figure out what they should be working on right now. If the team can develop rules of thumb, or heuristics, around when to stop and when to adjust, it doesn't need that kind of heavyweight scheduling. Just work on projects until they don't make sense, then change gears. This might make long-term predictions challenging - but if you look back over your team's last five-year plan, how accurate was it, anyway?

If your organization makes enough money to run itself, and if you view time spent estimating as time not developing, then you might abandon estimates and just write code. This approach is extremely tempting for products that charge a per-user, per-month fee that are already cash-flow positive. (We used this method for some time when I belonged to the technical staff at Socialtext.)

The approach isn't limited to profitable Web startups. John Carmack, CEO of Id Software, is famous for the expression " it's done when it's done," so much so that the phrase appears under Carmack's name on WikiQuote. Id created the wildly popular games Quake, Doom, and Duke Nukem.

The common objection to this is governance - that Carmack owns the company and can therefore do what he wants - but publicly traded organizations need to give advice to shareholders and the board on projects.

It's worth noting that Apple, one of the largest publicly traded organizations in the world, is secretive about upcoming products and refuses to make quarterly earnings estimates for shareholders or Wall Street. It doesn't seem to be hurting them.

NoEstimates Really About Solving Problems a Different Way

"My boss would never go for that" may sound like an invitation for dialogue, but it's actually a fiat. Any further conversation boils down to "would not, would too" - and that's not a helpful. Clearly, many software customers want estimates. In many cases, those are reasonable.

Turning the conversation a bit, here's the next logical question: What problems do estimates solve, and can we solve them a different way?

This has been done before; it reminds of Henry Ford's famous claim that if he'd asked his customers what they wanted, they would've told him faster horses.

The line is usually used to dismiss customer concerns, but let me suggest a different idea. Ford's customers were telling him exactly what he needed. If Ford had applied the 5 whys technique to that request for faster horses - driving in to what the customer really needed - he may just have found the automobile.

It's the same with estimates. If we apply "Why?" for estimates, we can drive down into needs such as planning and funding decisions. All the examples above are innovative environments where the technical staff found a way to provide for those needs in a different way.

That conversation can lead to answers such as "It's a lot of money to us" and "We want to reduce our risk." These are things the team can work on. Estimates might not go away, but the focus on estimates, and the amount of time and effort involved, might decrease. This means more time and energy can be spent actually building and testing software.

Copyright 2017 IDG Communications. ABN 14 001 592 650. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of IDG Communications is prohibited.