While the actual document about Agile usage in the technology industry slowly but majestically navigates through the final editing and production process, I thought I’d share an important bit of data that didn’t make it into the report. Shown in the diagram below is the percentage of survey participants who said that they used particular Agile methodologies. We also asked the respondents about other methodologies that often come up in discussions of Agile, either as complementary approaches (for example, Lean), or as points of comparison (Waterfall being the most obvious one).

How many at each table in the Agile seating chart?
As you can tell, there’s no clear winner here, other than Scrum, which overshadows every other Agile methodology in adoption. There’s another way to look at the same picture: whenever there’s a family photo of Agile methodologies, the participants almost always make sure to invite their poor cousins to attend. There are both good and bad sides to that earnestly ecumenical approach.

Someone once told me, “If you want to learn about Agile, read a book.” Most of these references have an earnestly ecumenical approach to Agile. For example, Craig Larman’s Agile And Iterative Development: A Manager’s Guide gives equal time to Scrum, XP, UP, and Evo. Peter Schuh’s Integrating Agile Development In The Real World covers a different set of methods, but with equal egalitarianism. Sure, these books are a few years old, but they’re representative of what teams interested in Agile will find when they scan the bookshelves.

We don’t need to declare a winner. A methodology that’s in the minority may shoot forward tomorrow in adoption. Scrum might become so commoditized that it becomes the basis for a new set of tailored approaches, in which case the original meaning of “Scrum” winds up submerged in other things.

However, I can tell you from first-hand experience that many development teams are having  a tough time figuring out if they’ll find a healthy community of fellow adopters for particular Agile methods. That’s a very legitimate question, particularly since the success of Agile implementations often turns on what lessons learned a team can apply from other people’s experiences . (Which is one reason, perhaps, why Agile coaching seems to be as important as it is. Among other things, a coach is a storehouse of vicarious experiences with Agile implementations.)

Everyone is welcome at every table
Actually, the survey results shown in the diagram tell a different story about methodological pluralism. In practice, teams mix and match different methodologies. The pluralism of methods within teams may be just as interesting, and maybe more interesting, than pluralism across teams. My Forrester colleagues Dave West, John Rymer, and Mike Gilpin wrote an excellent piece on using Lean to complement Agile, and vice-versa. The diagram shown here indicates that a lot of other methodologies (Six Sigma, ISO, etc.) occasionally wind up in the mix, too.

My upcoming research document, which covers a lot of other aspects of Agile adoption, provides some more information about this mix-and-match behavior some additional teams. The real topic of the study, however, is how Agile changes the way that groups interact with Development, and the effects these changes have on the company at large. I’ll post when it becomes available. There’s a second document in the works, too, which I’ll talk about later.

[Cross-posted at The Heretech.]