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??