Tuesday, December 18, 2012

Are Estimations Harmful?

In the beginning we had plans. These plans were crucial to the business organizations. They relied on products being ready, so marketing could have marketing prepared, sales can sell them, and support support them.

Then reality happened. Either the products were not ready on time, or their quality was bad, or were not what the customer wanted. Most of the time, all three.

Managers realized they needed to put things back in order and cracked the whip. Of course, this didn’t help. It added demoralization and more turnover, which was not really helpful to the organization.

Agile methods tried  to deal with quality and customer fit. But instead of having full scope in unrealistic deadlines, it kept the deadlines. Since customer fit is much more important than scope, we loosened the scope reigns, and instead got incremental releases, on date with incremental relevant features.

In theory, at least.

Although the product development might have changed, and is now producing releases frequently, and even better quality, the rest of the organization hasn’t changed. Marketing still needs to know when to prepare material for product launch. Sales need training before that.

The agile development process still needs to fit into the rest of the organization. And it made an effort to do it. The planning process has two objectives: The first is to understand the requirement better. The second is about giving some predictability to the product owner, who is the proxy for the rest of the world.

Estimations are just that, so there are misses. The problem starts when we’re starting to hear estimations as promises and commitments. When we do that, a funny thing happens – the estimations become bigger. The same task now takes longer. Reality is elastic.

Gaming the system

People do not do this out of spite. They are professionals. What they do is take precautions. They do not feel safe (since the boss blames them for missing the estimate) so they make sure they don’t get in trouble. If all goes well, the estimations are met, and the product is delivered. If all goes well.

What worked for the development organizations though is bad for whole company though. The products get delivered but late. And now the boss has a different complaint: You’re working too slow.

Can’t please some people.

Necessary evil

Estimation are harmful because they breed blame. Since estimations are not certain, they have inherent risk. And nobody wants to hear about risks.

But we can’t change the entire organization today. It still needs predictability, even if it’s only a mirage. (I admit, I ask for estimates, and I know fully well they mean nothing. But I feel much better with an imaginary one, than with none at all).

Kanabn’s approach for creating predictability is based on lead times historic data, but it’s still not deterministic. They are still estimates. Maybe more grounded, but at anytime can explode into mega-tasks and break the fragile reality for everyone.

The hard answer is that old XP saying: Embrace change. Face reality. Understand that the plans we build are brittle. They make us feel better, and give us some grounds for better planning, but they can change in a wave of  a hand.

However, we can’t make people embrace change. We can show them, time and again, that what we planned broke. Some will understand logically, but will continue to behave as before. So we’ll get asked about estimations anyway.

There is one thing we can do. Since estimation is harmful and doesn’t help, there’s no need to work on it so much. If you’re spending a day for a team of 10 on estimations, you’re throwing money away. Give some broad estimation and start developing.

After all, isn’t delivering software better than just guessing and discussing it??

2 comments:

Eric King said...

The problem with typical estimations is that (as you pointed out) they always contain some uncertainty, yet they are never presented that way.

I seldom see an estimate that says "this should take 8 - 16 hours, with about an 80% certainty". Instead, that estimate is relayed as "this will take 12 hours" (the uncertainty is implied and hidden). This turns the estimate from accurate but imprecise to precise but inaccurate.

Then, when the task actually takes 14 hours, which should be completely acceptable and understandable, it's considered a failure. Which leads to the finger-pointing you describe.

Gil Zilberfeld said...

Eric,

Thanks for your comment!

Taking the manager side "this should take 8 - 16 hours, with about an 80% certainty" while might be true sounds bad. And it's not just for managers, really, do you expect to hear that from your graphic designer? Your gardner? Or doctor?

Explicitism(?) doesn't help. The implicit variation is something we "know" exist, but we can choose to either regard or disregard it.

And that's where the listener comes in. The manager or any stake holder. Yes they should understand. But sometimes they choose not too. Like I said in the post - I can't make people understand. I can try push, teach, talk, shout, threaten, go over their head. In the end, it's their choice.

Depressing isn't it?
Anyway keep smiling :)

Related Posts Plugin for WordPress, Blogger...
Twitter Delicious Facebook Digg Stumbleupon More