Estimation in an Agile Organization – A Barometer of Dysfunction?

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.

 

This entry was posted in Agile Development, Agile Management, Agile Metrics, Agile Teams, Agile Velocity, Lean Software Development, Scrum Development. Bookmark the permalink.

3 Responses to Estimation in an Agile Organization – A Barometer of Dysfunction?

  1. Lisa Crispin says:

    This is an interesting debate and I see good points on both sides.

    I’d like to stick up for the business people who DO understand the nature of software development and the push-pull nature of agile teams. If they understand the transparency of agile, they realize that agile practices give them a much better ability to assess progress and plan. Since you mention Mike, I’d like to recount my experience having Mike as our manager back when our team transitioned to agile. He educated the business people on what estimates are and how they can be used for planning, with the understanding that they might be dead wrong. Over time, one hopes they will average out to something that is meaningful to planning. Our business people have always trusted us to do our best work, and if that means it takes longer than our estimate, so be it. They know that this keeps technical debt under control so we have a more predictable velocity over time.

    That said, over the years, we found that estimating a bunch of stories far in advance of when they might be prioritized was mostly a waste of time. We had two big shoeboxes full of estimated stories that were never going to get done. The product owner first planned only 3 sprints ahead, keeping the backlog in a spreadsheet. Nowadays, we only plan 1 sprint ahead. We estimate the stories the PO thinks might be prioritized, and then the biz folks prioritize them. It’s a more Lean approach and it recognizes the fact that in our domain, priorities shift so fast, there’s no point in planning too far ahead. We do plan big themes farther in advance, doing estimates at the theme level, that is enough for our biz folks to plan. I’m sure every situation is different, so I recommend everyone experiment with different approaches to find what works for them.

    • Michael DePaoli says:

      Thanks for the feedback Lisa. I agree context will dictate approach and only by folks trying different techniques in their context will they arrive at what works best for them.

  2. Michael DePaoli says:

    Thanks for the feedback Adam. Over the years I’ve come to see lead time, variability and cycle time as perhaps the most useful metrics when aiming for predictability. I too don’t understand the controversy. :-)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>