Micro Focus is now part of OpenText. Learn more >

You are here

You are here

#NoEstimates? Not so fast

public://pictures/Martin-Heller-TechBeacon.jpg
Martin Heller Owner, Martin Heller & Co.
 

If #NoEstimates is the answer, what was the question?

That is, what question are you answering when you raise the #NoEstimates banner?

Woody Zuill, then a development manager at Hunter Industries, introduced this famous Twitter hashtag in 2012. At the time, Zuill found that software time estimates provided little value in his role as an agile development manager. His in-house team could deliver more business value simply by working on the highest-priority item until it was done than by first estimating how long it would take. The idea behind #NoEstimates isn't new. I've heard this message from others prior to the dot-com bust. What's new is the hashtag.

[Also see: The #NoEstimates debate: An unbiased look at the origins, arguments, and thought leaders behind the movement]

There's an assumption in Woody's formulation: he had a working agile software development team of fixed size trying to deliver business value. His managers kept asking for cost estimates instead of deciding on what items had the highest value to the business, and he wanted to change that. All well and good: in his case, providing cost estimates was answering the less important questions and wasting his team's time.

A recent, concise formulation of the alternative to estimates comes from agile pioneer Kent Beck. "Alternative to estimates: do the most important thing until either it ships or it is no longer the most important thing."

 

Another alternative is to teach your business managers how to estimate software costs, at least roughly. If they knew how to assign business value as well, they'd understand the trade-offs and be able to make their own decisions about what features they want next.

Underneath the surface of the #NoEstimates banner lies an essential truth: doing software estimation is hard. The methodologies for estimating require that you break down the overall task into pieces small enough to understand, and then add up the level of effort to compute a cost. Why waste your time?

Here's one reason: breaking down an overall task into pieces small enough to understand is important. In itself, it's not a waste of time, whether or not you do the extra work of forecasting costs and duration for each piece (which might be a waste of time). Design top down, implement bottom up, anyone?

Sometimes you really need an estimate

Now that we've beaten the agile in-house case to death, let's discuss a different situation. I once managed a software development group that did contract work for other businesses. Contracts could be firm fixed price (FFP), cost plus fixed fee (CPFF), or time and materials (T&M), depending mostly on what the customer wanted. We wrote customer proposals explaining what we were going to build for them, how long it would take, the payment terms we wanted, and how those payments would be tied to feature deliveries.

One of our jobs was to build a thermal design program for a manufacturer of power plants. We already had a prototype built in interpreted BASIC; the customer wanted a version in C that would run faster, to make the best use of mechanical engineers' time.

In the course of writing the proposal, I worked out a cost estimate for the software. Another manager, a mechanical engineer, did an independent cost estimate, which was within five percent of mine. That gave our VP enough confidence that he "only" doubled our estimates and offered the customer a firm fixed price. This contract was a success for all concerned: we came in under our estimated time and cost, our company made a nice profit, and the customer realized value exceeding the cost of the software the first time they used it to design a power plant.

How so? The software calculated that the desired plant efficiency could be achieved even without one of the heat exchangers used in the standard configuration. In this case, the thermal design fed into the manufacturer's mechanical design and cost estimates for its own contract.

What was the value of our software development estimates? Without any estimate, we wouldn't have been able to write an FFP proposal or close the contract—the customer was allergic to T&M contracts. With only one estimate, we wouldn't have a good idea of the error bars, and we would have had to pad the FFP contract or try to sell the customer on taking it on a cost-plus basis. With two estimates, we had an error bar, it was small, and our management was comfortable going ahead.

Through the looking glass

More recently, I was CEO of a startup that used an Indian outsourcing company for most development. One of the problems we faced was that the outsourcers were constantly over-promising and under-delivering. This wrought havoc with our product delivery schedule and upset our investors. As it turned out, their estimation methodology was flawed, and their staff was carrying a certain amount of dead wood.

From a business perspective, we had a pretty clear idea of what we needed them to build and when we needed to launch. In order to get that on time, we had to collaborate with them in several ways: we took on more of the design work, helped them improve their estimates, and strongly suggested specific cuts to the team working for us.

We got the site we wanted built. Marketing and selling it was another story: suffice it to say that there's a reason I'm now doing freelance work.

 

Keep learning

Read more articles about: App Dev & TestingApp Dev