If you have to estimate at least know why you’re estimating and do it appropriately so that it’s in some way useful with associated risks clearly defined. Understand what the estimate will be used for, choose a suitable technique, provide each estimate as a range (incorporating a percentage-error or tolerance), and don’t invest time trying make the estimate more accurate.
Absurdity and bad behavior
A certain amount of absurdity and bad behavior always accompanies estimation.
When you don’t have enough information to even make assumptions, and you’re being pressured for estimates, you can base them on hallucinations and take the consequences when they come. And they will come. Being pressured to make any kind of estimate without appropriate information feels like a bullying tactic to secure the blame for later on. Is that a tacit admission by the bullies that they think the project is likely to fail anyway? If there’s any truth to that, that’s really quite fucked up. Sadly many projects are so obviously set up to fail, and fail they do. It’s really no wonder people behave in this way.
There’s likely to be a good reason for the lack of appropriate information. If it relates to scope, for example, I’ll bet the business people don’t really know what the business needs are or what customers actually want. I wouldn’t know for sure. I might have lots of assumptions and what I think are great ideas but I’d still be unsure. That uncertainty is reality. What’s dumb is when people pretend that uncertainty doesn’t exist. Perhaps they think admitting they don’t know would be embarrassing, even career-threatening. In the typical corporate environment, that’s a fair point. It’s unsafe to show weakness. That doesn’t excuse making unreasonable, often ludicrous demands of the folks responsible for delivery. Alas, it’s easier to do just that. Like I said in No Bull, “It’s always an IT problem, until it’s proved not to be.” By keeping the spotlight on IT fewer people will know people in the business are complicit in delivering the wrong thing.
The thing is, when everyone openly recognizes the uncertainty, an opportunity presents itself to have a very different kind of conversation. In my experience success begins right there.
Need to set a budget?
“Give me estimates. I need to know how much it’ll cost. I need to set a budget.” This thinking drives a vicious circle that keeps software delivery in failure mode. “Guess what? Yet again IT failed to deliver against their estimates.” Err yeah, because they were estimates! And so IT is forced to provide more accurate estimates next time. For crying out loud, there’s no such thing as an “accurate estimate” – it’s an oxymoron. Rather than perpetuate conversations grounded in make-believe, how about trying something else.
I get the need to set a spending limit. Who wouldn’t? It’s everyday thinking. But are costs calculated from estimates, which were perhaps made under ‘duress’, the best way to calculate a budget? There’s a lot riding on that figure after all. Is this sounding like it has some risk to it?
Instead, how about deciding the amount of money the company would be willing to lose if the business assumptions proved to be wrong? Let’s make that the initial financial investment with which to deliver a minimum viable product. First, the business people need to quantify the value those business assumptions will apparently realize. In Competitive Engineering, Tom Gilb shows how this can be done in a more meaningful way than anything we see in typical business cases or financial forecasts. It’s time business operations started closing the loop on business decisions and learning to use software development more effectively as part of that process.
Not getting it. Not getting the benefits
As a business, if you’ve got a truly agile delivery capability that keeps the cost of change affordable and the total cost of ownership low, you can discover the right things to deliver through constant iteration and continuous delivery. You’re hands are on the wheel of something really quite special. Rather than betting the whole budget on a hole-in-one, make lots of small bets and code your way to what the business actually needs and what customers actually want, and waste no money on features that won’t be used.
Contrary to popular Agile belief, you can’t pull this off with incremental development and a release plan. Incremental development requires something at the start that describes the whole thing at some level of detail – that sounds likes a spec of some kind, doesn’t it? A release plan means a big bang or at least a series of medium pops, either way feedback from customers comes via scheduled encounters – that’s not a continuous conversation, and the longer you go without feedback, the greater the likelihood of error and bad investment. This sounds like a bigger bet to me.
Lots of businesses are missing out because IT departments are busy trying to do Agile rather than working upstream in the business to be agile as a unified customer-oriented capability. And I suspect some business people are happy with this arrangement because the spot light stays off them and IT continues to get blamed. The status quo is utterly preposterous when you think about it. One thing underlies all this: A complete lack of trust. It’s truly a sad state of affairs.
Business success requires risk be dealt with properly
What’s important here? The illusion of success from the comfort of the status quo or measurable success in the real world? Knowing that uncertainty is always there no matter what you do, is it not less risky to start small, deliver working features to customers every week proving business assumptions and ideas as you go, and continue to invest small amounts of money periodically for as long as it makes sense based on actual profitability and customer feedback? This is what gives a business real responsiveness in the market and an unfair advantage over its competitors.
All that’s needed is a small amount of money for initial outlay, a little bit of trust, and an agile delivery capability. Then you can laugh at the absurd truth in Dilbert’s estimation stories.