Posted by Tom Grant on August 13, 2012
A common question we analysts hear from our clients is, "How do we scale our Agile efforts?" Now, let's be clear: the question is not how to get Agile to work in a large project. Sure, there are challenges in making Agile work within big teams, but there's a much bigger concern. Organizations invest in Agile, or allow Agile experiments to blossom, and then try to capture the Agile magic in a bottle and mass produce it across the organization.
That's an entirely different challenge, with ambitions and uncertainties that are both Texas-sized. (I'm in Dallas, so I'll use Texas metaphors. So shoot me. Wait, no, I take that back.) The uncertainties have many faces, including (but in no way limited to) issues like:
- How many projects or products should employ an Agile approach?
- Can we expect our outsourcing partners to use Agile as widely as we do?
- Do we need a common tools strategy to support Agile?
- How much diversity of Agile approaches within teams is a good thing, and how much is counter-productive?
Truth be told, these are not easy questions to answer. For example, diverse Agile approaches are OK, as long as they don't diverge too far from core Agile principles and practices. Unfortunately, it's easy for bad Agile practices to emerge under the mantle of "diversity." If a team has mimicked some behaviors of Agile teams (daily Scrums, product owner role, etc.) but has missed the core of what it means to be Agile, that's bad. If it's impossible to figure out, across Agile teams, the real status of work, because they've adopted different measures of sizing and estimation, different quality metrics, and different definitions of "done," that's really bad.
But how do you keep healthy diversity from turning into destructive misalignment? Many of the measures that you might imagine aren't necessarily the best ones. Create an Agile standards board within the company? Sure, if you want to make teams feel that some foreign power is handing down a diktat. Put everyone through the same training? You might create some short-term conceptual congruence, but over time, teams will drift apart in their understanding of Agile in practice.
Here's why I often write about serious games as a mechanism for replacing the typical rules governing work when they clearly don't work. Case in point: ScrumKnowsy, the brainchild of Innovation Games and ScrumTide. By playing a simple game in which you rank important Agile principles and practices -- What are the critical steps towardbuilding an initial backlog? What are the key responsibilities of a product owner? -- team members can gauge how far apart their notions of Agile are. Even more importantly for the question of Agile at scale, teams can compare their relative understanding of Agile. To provide an anchor point, you can compare your answers with what some leading thinkers of Agile, including Jeff Sutherland, Jim Coplien, and Jens Ostergaard, would say on these topics.
Clearly, the approach that ScrumKnowsy takes is a lot less obnoxious than the Agile standards star chamber and a lot easier to use for regular reinforcement than training classes. While other approaches, such as Dean Leffingwell's Agile-at-scale toolkit, are also important, we've seen a lot of occasions when a creative approach like ScrumKnowsy is also necessary. For example, planning exercises need to include everyone's input, but it often takes Planning Poker to get meaningful participation from everyone in the teamwithout creating an open-ended debate over sizing. The formula for scaling Agile will vary somewhat from organization to organization, but some creative elements will always be necessary.