Thursday, August 30, 2012

Plateauing an agile adoption

My sons plateauing in Colorado
Many studios adopting agile will "plateau" after an initial burst of improvement.  Continued improvements stall for various reasons and getting past a plateau can be a challenge.

Agile adoption is usually not too hard at first. A simple framework for iteration and daily cross-discipline conversations, all by themselves, will bring significant improvements to a studio. Unfortunately, this initial improvement is then locked-in and adoption stalls.  Agile plateaus.

What's hard about agile is building and sustaining a culture of escalating self-organization and continuous improvement.

After coaching and training teams for a decade, I've seen common plateauing patterns:

  • Lack of executive buy-in. Executives can fear that agile exonerates failure with little upside.  They hear that agile means "no planning" and that any plan, even the old, unreliable type, is better than no planning at all.  Teams are not allowed to be agile, which means that they are limited in using emergent knowledge about the game to refine a plan.
  • Middle-management accountability doesn't change. Many studios are setup so that a producer or project manager is accountable for meeting a schedule. When there is a shift to a process where teams are accountable for iteration goals and the product owner is accountable for guiding the product based on emergent value and measured velocity, accountability has to shift away from those roles. Until it does, middle-managers are going to continue to manage teams and schedules. 
  • Pushing velocity on teams. Story points must be used for forecasting (pull versus push). When they become a metric for "pushing" a team commitment, then all sorts of bad things happen. Bug-filled features, untuned assets and mechanics, low-quality code, etc. are the result. To paraphrase a certain bun-haired princess: "The more you push velocity, the more quality will slip through your fingers." 
  • Micro-managing sprint backlogs. This is similar to the accountability pattern above, but it deserves its own pattern because there are different root causes and solutions. It's simple to observe. Are teams finishing all their tasks, but delivering low value? Are there twelve different ways to analyze a sprint backlog but the team doesn't debate about making something fun? Managing the sprint backlog is very important, but the backlog must derive from quality, which is often more emergent than we'd expect. 

There are no solutions listed here for a couple of reasons: First, listing all potential solutions would require a small book because, second, solutions are different for each studios that encounters them and are usually dynamically linked when root causes are uncovered. 

Solutions are usually easy to identify but hard to implement, because they challenge a culture.  Agile is hard!

1 comment:

Scott Crabtree said...

Insightful comments, Clint. Based on your work I've read and seen you present, I know you are just the person to help studios move past the plateaus and reach the peak. :)