Over a million developers have joined DZone.

Predictability Addiction

DZone's Guide to

Predictability Addiction

· Agile Zone
Free Resource

Reduce testing time & get feedback faster through automation. Read the Benefits of Parallel Testing, brought to you in partnership with Sauce Labs.

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…

The Agile Zone is brought to you in partnership with Sauce Labs. Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure.


Published at DZone with permission of Gil Zilberfeld, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}