Search

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!

Friday, August 17, 2012

Creative Developer Motivation and Autonomy

"Motivated developers are the most productive".  Is an axiom, but as a developer, high productivity wasn't the only reason I enjoyed being motivated.  Creative motivation is intrinsic.  We are creative because we like being creative.  It gives us joy.  Making something new work is a huge reward in itself.

How do we support such motivators?  Studies have shown that the top three creative intrinsic motivators are:

  1. Autonomy - The urge to direct our own lives 
  2. Mastery - The desire to get better at something that matters 
  3. Purpose - The yearning to do what we do in service of something larger than ourselves
The first, autonomy, is a challenge in organizations because most organizations do not trust their developers to have much of it and developers don't often trust their organization back.  Trust and autonomy take time and have to be built into a culture.   Building trust often has to be built from the bottom up (unless it's part of the culture from day one).

One starting place to build trust is in the iteration/sprint.  Can developers be allowed to take control of how they achieve their iteration goals for just two weeks?   This question defines the first fork in the road between organizations that will have success being agile and those that will not.  There are many other forks in this endless, challenging road, but if trust can be built over the short term, you're off to a good start.


Monday, August 13, 2012

Axiom: Creative developer motivation and productivity

This is the first axiom in a series I'll be posting over time.

Axiom: Creative developer motivation and productivity:

The productivity of creative developers (developers who work on creative new products), is primarily based on their motivation.  Highly motivated creative developers:

  • Produce higher quality work
  • Have more creative ideas and are more likely to share them
  • Produce more (art, technology, effective designs)


Axioms

axiom  (ˈæksɪəm)
 — n
1. a generally accepted proposition or principle, sanctioned by experience; maxim

I sometimes find myself in debates about the value or application of agile practices.  For example, I was speaking with a ScrumMaster who was frustrated with their team because they are not "filling in their time-sheets" or "updating the task tracking tools" they've setup to help sprint execution become "more efficient and predictable".  This led to a debate about the value and appropriate application of tools and the purpose of the team owning sprint planning and execution.  I believe such tools and practices harm Scrum teams, while the ScrumMaster believed that certainty in sprint planning and execution can be achieved with enough detail and tracking.  The root cause of the disagreement laid below the practices, in the area of core principles or axioms, for creative teams and product development.

So the idea is to start posting what I believe to be axioms about creative workers, teams and products.  The idea is to make connections to some of the practices that are debated.  This will duplicate and overlap some of the agile manifesto, which is a great statement of values, but the manifesto has been quoted so long and frequently, that we don't always think about the reasons behind it.

I'll put "axiom" in the post headings and link to this page.  I'd love to hear any comments about whether these are truly axioms, or not.