I’m addicted to predictability. I admit it. I want my life to flow along, according to plan. Sure there will be some minimal changes, but I can adapt.

I’ve given up on this long ago, as I came face-to-face with real life. I know life is not predictable. And I have embraced change, as agile has taught me.

Or have I?

At ACCU, I had a pleasure of listening to Tim Lister lightening talk about estimation. Tim talked about weather forecast and compared it to project completion date estimation. If experienced weather people can only forecast (Read: DO NOT KNOW) the direction and impact area of a storm within hundreds of miles, how can experienced developers KNOW that the project will be completed on Sep 15th next year?

We don’t. We can estimate, give a range, but we don’t know everything. So we should talk about ranges of dates.
How does that go with my predictability addiction? Not well.

I would like to know when “it will be done”, so I ask the developers leading questions. “If we do this, the risk will be reduced, right? so we can release on…”. Or “Well, we might need to add some small feature X, but it won’t take more than a week, right?”.

My questions are “designed” to give me certainty. I either remove items from the equation, or add a “known” factor to the plan. The answers help me with my addiction… to some extent. In fact, I’m setting myself up for some crushed expectations.

Estimation is just that: estimation. We should reduce risk by not doing crazy things, and sticking to practices that reduce it (testing, anyone)but that won’t get us to certainty. Here’s an example: Our team works in pairs and we have a plan for the next few months. Now one person of the team got promoted, and left the team, so we’re minus one person. How much “velocity” have we lost? Is it just the linear drop in capacity? The thing is – we don’t know. There goes predictability.

Everyone is looking for predictability, but we’re deluding ourselves, thinking we can actually get it. Accepting uncertainty just goes against human nature.
So what’s my take?

Developers, testers, people who produce software: Give ranges. Explain these are estimates, even when the managers on the other side has a similar addiction as myself. And more important – measure velocity, cycle time, or whatever you measure progress with. It’s the past results, and the course corrections that gain the trust needed from managers that your ranges are not over-inflated or extra-reduced.

Managers – Ask for ranges, as well as past results. If you ask, you will receive. Don’t be tempted to ask for a date. Don’t ask (mis)leading questions, since you’ll get them. Since we’re betting the rest of the business on software delivery, it’s a poor starting point. Start from the ranges given, and build from there.

The first step in every recovery is admission. Eleven more steps to go…