Cloudy with a Chance of an Estimate
In a recent post — provocatively titled The (Agile) Estimates Overkill —I took an attempt at explaining why estimates don’t work if someone sees them primarily as a commitment to timing. And, some aficionados might have experienced an urge to educate me on the subject of estimates in general, and of estimates in agile, in particular, citing that the estimates should be regarded not as a commitment but, in short, as a discussion of chances and odds of how the development will go, considering the challenges of this particular production environment. Besides, there’s a reason to believe that some of the aforementioned aficionados have accused me of the gravest sin ever, and namely, of not reading Mike Cohn’s “Agile Estimating and Planning”.
Relax, guys. I perused Cohn’s book long ago, and time after time I’d flip its pages to refresh things in my memory — this is not to mention the other books, articles, and from-the-trenches stories. My most reliable source for making conclusions, however, is my work and my experience. If someone stays out-of-the trenches and theoretizes about estimates, this is just theory. My view on estimates lies in the practical, pragmatic context: if they don’t work as a commitment to timing, but as a discussion of chances and odds, why most companies continue to play this game? What makes them go on with it? Why spending lots of time on discussing chances is valued more than the action itself?
What Is an Estimate? (take 2)
I cited two possible answers to this question in The (Agile) Estimates Overkill. Those new to “agile” theory might view agile as the silver bullet to complete projects on time, and they regard estimates as the promise of exactly that. There are still people who genuinely believe that an estimate done in an “agile” manner must be more dependable somehow. Other believers consciously accept that estimating is a discussion of chances, a probability forecast, and a burndown chart — one of the tools for estimation — provides such a forecast based on velocity. I feel somewhat uncomfortable busting this myth, but let’s refresh the classical definition of velocity in our memory, quoting from here: “The main idea behind velocity is to help teams estimate how much work they can complete in a given time period based on how quickly similar work was previously completed”. Does it ring any bells now? If we never build the same feature twice, just as you can’t step twice into the same river, then why velocity-based forecast should be relied on?
Actually, this thought-provoking question can be asked in relation to all the forecast techniques based on past performance. And, if you’ve been wondering why weather forecasts have been so… how do I say it… erratic in the recent years, chalk it up to the ubiquitous model-based weather forecasting techniques! I mean, I want to know for sure if there’s going to be hail, or a thunderstorm, and I don’t care if there’s a 30–40% chance of those, which a model throws at me based on how the elements behaved in the past. With the weather going crazy all over the world, how can they even keep a serious face on — “them” being whoever they are in charge of weather forecasts — showing a long-term forecast which in essence is not a forecast but a useless model graph...?!
Back to our estimates. Yes, there are cases when a team’s work is monotonous, iteration in, iteration out, but from what I’ve been able to observe, this doesn’t happen a lot. Mostly, the tasks to be done and the challenges to be resolved are unique, for each iteration, and for each release. You never know when something pops up and kicks this neat forecast in the butt.
The Devil Is In…
.. not only in the details. The second most common habitat of the said devil, which goes after the details, is human nature itself. Nothing else explains this better than the good old Parkinson’s Law:
Yes, indeed. Having all the time in the world is loose. It’s either you have time, or you don’t have it. It’s either you have the sixth sense to define what should be included to the minimal viable product, for instance, or not. Let’s not forget that no one cares about software development for its own sake, except the software developers who view their work as craft. We do things for the market. For the customers, and they care little about the development kitchen constraints, challenges, and brilliant solutions. Same stands true for UX.
Now, how this reasoning fits into the subject of estimates, you might ask? Here’s the astounding truth. Teams and companies start playing around with the estimate rituals when they either have some extra fat to burn OR when they genuinely believe that putting effort into estimating is a high priority task. There’s no room for activities that are a waste in a mission-oriented squad. If you are a part of a hands-on team, and tempted to start a planning poker session (or another similar “game play” estimation activity), don’t do this. Rather than waste your time on playing with probabilities, get some work done. Write some code, do a UI sketch, instill clarity into your team’s collective aura. Some mathematical forecast model surely has it that a brick will fall on your head one day. But you’d hardly be wasting your time to estimate how many more bottles of champagne are likely to slip out of a torn plastic bag, when one of those bottles has already hit the concrete, and there are 3 more in the bag. You’d rush to catch the rest of the bottles, not to let them slip, right? Or will you freeze and estimate the probability of all of the bottles being shattered? And, isn’t it ironic, that business people who are skeptical about shamanism, astrology, and other such things, devotedly indulge into what is, in essence, shaman rituals with estimates? Come on, an estimate of completion based on a burndown or a planning poker session, is as valid as an astrological forecast. There’s no big difference. It’s either you’re “fat” enough as an organization to afford wasteful rituals or not. In fact, even in large companies that seem to be so safe and secure there’s always the bottomline point of “do or die”. That’s what the stories about massive job cuts imply. Rituals are a waste. If there’s time for rituals left, this is a sign of unhealthy fat. Burn it. If a work group discusses development, consider if there’s a need to wrap this activity into estimation rituals, because when a discussion turns into a draining debate of “how probable” a timeframe is, work suffers.
How Do I Tell My Higher-Ups ..?
As life has it, however, many of us have to cope with the fallacy of estimates. There’s no way to persuade a higher-up non-tech manager, or a client, or a stakeholder to give up on estimates. That’s why people go on playing games, as they attend to those who expect a release or a project to be done on time, as predicted by an estimating ritual. And, that’s where another interesting booster for evolution is hiding. Luckily — and, yes, I mean it, luckily —not everyone in the position of leadership or authority comes from a tech background. There comes a point of litmus test, when someone based in tech — a project manager, a team leader, or someone in middle management — meets a non-tech stakeholder. Why I call it a booster for evolution? Having to deal with a non-developer stakeholder about a deadline is stimulating because it helps tech people exercise their soft skills! And there are so many ways to fix the gaps between what the techies know and the non-techies don’t know — and it works in reverse, too — such as writing articles, speaking at conferences, joining the “no estimates” movement, you name it. Add to this personal exchanges and outright conversations. If everyone has their say, this world will become a better place, with less projects and software screwed. Changes in the way organizations work happen just as slowly as the tectonic plates move, and it might look like your word has no weight, but here’s what you can rely on, if not on a project completion estimate: you feel better inside, when you give your all and speak your truth.
Related:
A Manifesto for Big Picture Pragmatism
Bored at a Daily Stand-up? Ask “Who” and “Why”
The (Agile) Estimates Overkill
Back to the Future of Agile Software Development
This article has been re-written from an earlier story.
