I was recently asked to coach a team to help a giant company "deploy Agile." Like all great projects, this one seemed to be starting late, with a shrinking budget. So I needed a way to quickly figure what to do and add early value. And needless to say, I needed this approach to look like I knew what I was doing.
Who else has faced a similar disaster in the making? Hundreds, if not thousands, of project people -- each with a unique idea of Agile, what it is, and, of course, how to do it. And each willing to tell everyone that they know how to do it better than the guy who was hired to help do it right. I had no interest in being shown the door before explaining the benefits to doing the right projects in the right way. And besides, I needed the dough.
As I looked through my meager kit, I remembered the PMI "organizational maturity model," or OPM3. It is designed to guide an enterprise to project and program management best practices, and it begins with a cool assessment tool. I also came upon a favorite article by Meilir Page-Jones, called "The Seven Stages of Expertise in Software Engineering" (1998), in which he explains how seven common stages are universal to the passage of a person on a journey from total ignorance to world-class knowledge . . . whether the journey is software engineering or bear hunting.
Seemed exactly like what I was doing: a sort of wumpus hunt. (Anybody remember what a wumpus was?) Anyway, I put together a definition of seven stages to world-class Agile practices. It wasn't too difficult, given the wealth of firsthand stories from Mike Jones, Ken Schwaber, Jeff Sutherland, Mike Cohn, and the other Agilists in the public domain. Plus I added in my own practical experience in world-class organizations, from snake pits to Mount Olympus. (At the high end is someone putting down new trails and techniques. At the other end is the organizationally mandated SDLC, with the ritual pyre for a project manager who comes in late or over budget.) Next came a simple assessment, a questionnaire that could be applied to a person, a team, or an entire group or organization. Then I created a simple plotting worksheet, and a set of guidelines for how to read it. Voila: the Agile Map.
Despite the complexity, lots of stuff can be read from this diagram. It has been described as a web of the pitfalls and spider traps of deploying Agile practices into a "defined process" organization. I often see it as a topography, an aerial view of the landscape, with the positions of the fellow travelers mapped out. Whatever your perspective, here's what this diagram tells us.
The gray plate is the map of the Agile maturity of the organization. This is the foundation for all Agile practices. I sometimes think of this as the mountain.
The colored lines represent the Agile knowledge and experience of the team members, developers, and subject matter experts. Sometimes the lines seem like the paths they take on and around the organizational foundation. Whether you view it as a path or as the space where the team or the individuals live, these lines reveal strengths and areas for additional coaching. It is usually a good idea to include the product owner in this diagram, but it is especially important to know which line is the PO, because the path of this role can be considerably different than that of other team members.
Finally, the red dotted line represents the dynamic of the Agile team. This may be a thought leader or two. Or it may be the organizational or team imperative. In any case, it represents the pull or the forces acting upon the individual team members and upon their practices. I often think of this force as gravity, or magnetism, or even shear-force wind . . . sometimes invisible, sometimes subtle, but sometimes sufficient to accelerate momentum or even kill it.
Of course, there is more to this tool than a simple diagram. Each questionnaire is unique to the organization and the Agile goals; each team is unique in its vision of itself and Agile. There is a set of tools for influencing the Agile practices along each vector. And there is an effective interpretation of the dynamic of any single team or organization, and quite possibly several effective interpretations.
But as with all great adventures, an Agile Map seems to me to be a good way to start. For further discussion on this approach, please contact me here, or directly at email@example.com