Estimates: Jumping To Wrong Conclusions
Estimates: Jumping To Wrong Conclusions
How estimates, even good ones, leads to "gaming the system" and can be perceived to be as important as delivering the software. How crazy is that?
Join the DZone community and get the full member experience.Join For Free
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
The main dysfunctions we concentrate on when talking about estimates are how they (and the people who gave them) are treated once they are given. Management asks for estimations and then either:
- Disregards them completely and sets a deadline that ignores the estimates, made by the people who actually know and will do the work.
- Inflate them because “they are always late”.
- Puts them on the calendar as promises made to be fulfilled.
All three lead to mistrust and wasteful work, as the workers will game the system in order to come out on top.
There’s another option we don’t usually talk about in #NoEstimates: When the game is played collaboratively. Estimates are treated just as that, and the workers don’t get whacked on the head when they miss it. When the risks and deadlines are discussed and agreed upon together. Yes, there are organizations like this.
However, we find ways to mess up things even then.
In a training session the other day, we were talking about estimates, and what happens in that specific organization when they are missed. After publicly establishing that as long as the work was managed properly, and only things outside the field of vision caused missing the target, I asked: “So what do we do next time?”
The answer came out almost automatically: “We should work more on our estimates”.
Why is it So Hard to Understand?
I’ve been thinking about what causes this kind of thinking. How estimates get so much respect, when logically there are better alternatives.
Obviously, logic has nothing to do with it.
It starts with how we see ourselves as professionals. If estimates are part of our work, than as professionals, we want to get better in estimation too. We look more professional if we hit the original estimation (regardless of side effects, e.g. quality).
There are other personal perspectives. As humans, we have a hard time acknowledging we don’t have control over everything. Hitting the estimates serves as compensation for not knowing everything. Drilling through the known unknowns, compensates for the unknown ones.
Also, we don’t like being wrong. Especially when others are right, the bastards.
Finally, there are other environmental factors. The environment may not be safe enough. It may look safe, and missing deadlines does not meet bad consequences. But there are perceived consequences for missing estimates, that may or may not happen.
With all these illogical thinking, the result is that hitting our estimates is perceived as important as getting actual results.
Personal incentives aside, the organizational implicit behavior is the greater motivator to putting more effort into estimations. Our tools and metrics put emphasis on reviewing against the estimates, rather than on actual work. Look at burn-down charts – even in an agile environment, that is supposed to navigate in the lands of uncertainty, we still look every morning at how we’re doing according to plan.
And I’m not even talking about larger scale plans.
To get outside this mindset, a safe environment is not enough. Organizations need to explicitly communicate what is important, as well as downgrade getting estimates right. If indeed estimates are not important as reference, we need to say so. We need to stop reviewing our status according to a plan that was built when we knew a lot less. And we need to de-emphasize the importance of processes and tools that do.
PS: I’m going discuss these things in my session “Rebooting ALM” in Lean Agile Scotland 2015.
Published at DZone with permission of Gil Zilberfeld , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.