Estimation in agile organizations still seems to be a pretty hot topic. I was reading a recent post by Mike Cohn on his blog about it. Mike states:
“Because I’m so interested in estimating and planning, I always take notice when I see a new blog post or news group posting claiming, “Estimating is waste! Don’t do it!” The thing that never shocks me about these arguments against estimating and planning is that they never come from the business people for whom we are developing products or systems. They understand the value of estimates and plans (and the shortcomings of poor estimates and plans).”
I agree with the general agile tenant which Mike alludes to with respect to estimation: do it if it is valuable. What I don’t agree with is a general statement that, “They understand the value of estimations and plans (and the shortcomings of poor estimates and plans)” — the ‘they’ being the business people for whom we are delivering value.
Most often, the ‘business people’ for whom we build solutions/deliver value are the ones refusing to accept the nature of the type system which software development organizations represent. They are typically either complicated or complex systems. Many business people still want a level of control and predictability that just isn’t there without first doing and establishing a system capability. These business folks want things to be simple systems where one can select a best practice, follow the steps and get the planned outcome… See a Tollhouse cookie recipe for such control.
Another key challenge is that these same business people often don’t respect what makes a system work and what makes it predictable. For instance, the belief that you can reboot teams, project to project, putting together different people each time and expect to have predictable outcomes. Additionally, it is often these business peoples’ failure to respect the pull-based nature of lean/agile systems that makes traditional estimation wasteful. It’s like you know the red line of your car’s engine is 7000 RPMs but you demand it perform at 9000 RPMs. Bad things will happen and the performance will certainly not be predictable.
For organizations that have the patience to establish lead times for the different types of work for their teams – and then respect that productive capability and use it to plan -estimation is a minimal effort and is valuable. It can leverage organizational experience with the different demands for service on its teams.
It is often those who want to sell something that they can’t deliver, either to make a boss happy or to earn a bonus (or both), who will invest in heavy, assumption-laden, big upfront estimation fairytales that entertain and distort, but are not valuable.
I find that looking at how much estimation is desired and when it is done are pretty good barometers of dysfunction with respect to the business people’s understanding of the nature of agile/lean systems, and what it takes to become predicable as a product development organization. At the end of the day, isn’t that why we’d want to invest in estimation in the first place so that we can predictably deliver value to our customers? I think the answer is yes. Tell me your thoughts.