Agile Zone is brought to you in partnership with:

Gil Zilberfeld has been in software since childhood, writing BASIC programs on his trusty Sinclair ZX81. With more than twenty years of developing commercial software, he has vast experience in software methodology and practices. Gil is an agile consultant, applying agile principles over the last decade. From automated testing to exploratory testing, design practices to team collaboration, scrum to kanban, and lean startup methods – he’s done it all. He is still learning from his successes and failures. Gil speaks frequently in international conferences about unit testing, TDD, agile practices and communication. He is the author of "Everyday Unit Testing", blogs at http://www.gilzilberfeld.com and in his spare time he shoots zombies, for fun. Gil is a DZone MVB and is not an employee of DZone and has posted 76 posts at DZone. You can read more from them at their website. View Full User Profile

Predictability Addiction

02.04.2013
| 1638 views |
  • submit to reddit
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…

Published at DZone with permission of Gil Zilberfeld, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)