On Doing Versus Being Agile

Are you doing Agile, or have you become Agile?

The difference seems pedantic at first…

You are doing Agile when you’ve changed your tools and processes. This is relatively easy to do but doesn’t offer much in the way of benefits. You’ve become Agile when you’ve changed you structure and culture too. This is relatively hard to do, but offers significant benefits.

Agile isn’t just a process. It’s a complete framework that brings together a shift in culturestructure, and processes. This framework is supported by tools such as Rally and other Agile Lifecycle Management (ALM) tools.

A few companies fall into the trap of simply adopting an ALM tool and thinking that their work is done.

Many more companies fall into the trap of adopting an ALM tool and forcing an Agile-related process on their teams, then thinking that their work is done. This still provides some benefits: “The average Scrum team delivered a 35% improvement in velocity at Yahoo” per Sutherland et al in their seminal paper “Shock Therapy“. However, working in this environment can be even more stressful than working even in a “waterfall” environment. This is because Agile rapidly uncovers significant opportunities for organizational improvement that can rarely be solved with tool and process changes alone. Is ignorance bliss?

Few companies manage to do the hard work of changing their structure to improve collaboration and eliminate most dependencies. This can provide significant benefits, such as decreased time to market, higher quality, and greater capacity. I estimate that these teams can achieve 300% improvements relative to teams that have adopted process changes alone.

Even fewer companies implement the sorts of radical cultural changes necessary to achieve the highest performance available. Sutherland argues that “The best Scrum teams in the world average 750% gains over the velocity of waterfall teams with much higher quality, customer satisfaction, and developer experience” but that “90% of Scrum teams… never deliver this capability.”

What’s a good example of this?

When examining culture, sometimes it’s useful to look at other industries so that one doesn’t get caught up on the tools, process, and structures. Given that Agile/Scrum/XP owe so much of their heritage to Toyota Production System (a.k.a. Lean), we can learn a lot from comparing Toyota and traditional American car manufacturers.

Thankfully, we have the example of NUMMI, an automobile manufacturing plant jointly owned by General Motors and Toyota that opened in 1984 and closed in 2010. This American Life aired an episode about NUMMI in 2010, less than a week before the plant produced its last car.

You might find it interesting to listen to the episode with these questions in mind. They’re a bit academic, but I found them quite insightful and hope you will too.

First half of the story:

  • What changed in the plant between GM’s original operations and the joint Toyota-GM operations?
    • Tools? Processes? Structure? Culture?
  • How did GM and Toyota introduce those changes?
  • What might have happened in the event that Toyota changed the tools and processes, but not the structure or culture?
    • For instance, GM’s original plant had the necessary equipment and codified process in place to stop the manufacturing line when necessary. Toyota improved on this with the “andon cord.” What was the biggest practical difference?

Second half of the story:

  • Following NUMMI’s wild success, what did GM attempt to replicate in other GM plants?
    • Tools? Processes? Structure? Culture?
  • Were those changes effective? Why or why not?
  • What insights does this give us as we seek to enact an Agile transformation in our own organizations? What might we do differently?
2017-07-10T11:16:54+00:00 March 19th, 2016|0 Comments

Leave A Comment