Agile CMMI: Complimentary or Oxymoronic?
Recently the Software Engineering Institute (SEI) published a technical note entitled CMMI or Agile? Why Not Embrace Both!, co-authored by Hillel Glazer, Jeff Dalton, David Anderson, Mike Konrad, and Sandy Shrum. The Agile-CMMI Five (AC5), as I like to call them, are likely the bravest group of people in the IT industry in their daring attempt to bring together two groups of people seemingly at opposite ends of the software-process-religion spectrum. Although it would be easy to denounce the AC5 as a collection of Satan-worshipping kitten torturers (and extremists from both camps have pretty much done that already), the reality is that this publication is a thoughtful discussion of a topic that is important to a large number of organizations within the IT industry.
I'd like to first put this issue into context by summarizing the results of the Dr. Dobb's 2008 Process Framework survey. We explored whether organizations were combining Agile and the SEI's Capability Maturity Model Integrated (CMMI), and if so, how well was it working in practice. Yes, organizations are in fact doing Agile and CMMI together, an observation that is clearly inconvenient for the extremists claiming that this isn't happening. Of the respondents working in organizations doing agile development, 45 percent indicated that their organization had both CMMI-compliant and non-CMMI agile projects, 10 percent indicated that they were exclusively doing CMMI-compliant agile projects, and the remaining 45 percent of respondents said they were exclusively doing non-CMMI agile projects.
The authors go to lengths to point out that CMMI is a model, not a standard, for software process improvement. Nor does CMMI define processes or procedures. When I describe CMMI to people, I typically focus on it being a set of goals/suggestions for an effective software process, although to be fair, it is also a maturity framework that can be used to prioritize your process improvement efforts. Fundamentally, your organization's software process is your choice, it isn't dictated by the CMMI, International Standards Organization (ISO) guidelines, or any other process framework.
The AC5 also point out that CMMI has unfortunately been misused for almost two decades as an indicator of business performance and an ability to meet contractual requirements. Interestingly, the results from Dr. Dobb's 2008 Process Framework survey confirm this observation. We found that there wasn't a statistically significant difference in the success rates of CMMI-compliant agile projects compared to non-CMMI agile projects. In short, CMMI wasn't helping the situation, but it was not hurting it either.
In Section 4 of the paper, the AC5 does a very good job of reviewing both the strengths and weaknesses of CMMI in practice. For example, when CMMI is used in pursuit of maturity level numbers, the organization often loses sight of customer value and practical business goals. CMMI organizations often fail to ensure that the processes are successfully deployed to all new projects, are improved over time, flexible enough for teams to adapt to their existing situations, and written in a manner that practitioners actually understand.
Similarly, Section 5 contains a very good discussion about Agile that most CMMI practitioners would benefit from. It begins by overviewing the value statements of the Agile Manifesto, as well as the principles behind them. David Anderson, one of the AC5, was a co-author of the manifesto. They also explore some of the myths surrounding agile, such as the false belief that agilists don't do architecture, nor do they write documentation. This section also overviews common agile practices such as short iterations, active stakeholder participation, collective quality ownership, and embracing change. Finally, it discusses how agile is not successful when there is a lack of processes, lack of discipline, or lack of planning.
Section 6, the heart of the paper, argues that there is value in both paradigms, a belief that I subscribe to as well, and that they are compatible with one another (something that the process framework survey clearly showed). They argued that agile approaches can struggle when it comes to the realities of larger teams, a topic that I've written about in my Dr. Dobb's Journal column several times, and that CMMI can prove to be a safety net for agile teams at scale. Similarly, agile can be used to address some of the challenges of CMMI, in particular, the lack of flexibility that is often exhibited within CMMI organizations and the inherent risks of traditional waterfall approaches (a favorite approach of CMMI organizations). In short, you can take the best of both the Agile and CMMI worlds and develop a very robust and disciplined approach to software development.
I believe that there are several challenges facing the AC5. First and foremost is the Agile community's inability to discuss this topic in a fair and coherent manner. When this publication was first announced on the Agile Project Management (APM) mailing list, where several of the AC5 are regular contributors, the discussion instantly turned into various rants about the evils of CMM, CMMI, and process frameworks in general. Luckily, the discussion eventually evolved into a reasonable sharing of accurate information, but that was only because of the tireless efforts of Hillel Glazer to counteract the misinformation being strewn about. My experience is that the APM mailing list is one of the more mature agile lists right now, I hate to think what the discussion would have devolved to on the XP or Scrum development lists. To be fair, the AC5 report that the Agile community has invested more effort in understanding and writing about CMMI than the CMMI community has invested in understanding and adopting agile ideas. They write that the two communities view each other with skepticism, but by and large, ignore each other.
My second fear is the level of inaccurate information and misunderstandings about both CMMI and Agile. This is one of the reasons why I spend so much effort running the various surveys through Dr. Dobb's -- I want to find out what is actually going on out there, because my experience is that it is often much different than what people are talking about on the mailing lists, at conferences, or in articles and books. There's a lot of wishful thinking and bravado, but not much discussion of the inconvenient details of day-to-day work. The good news is that this problem is slowly going away, particularly in the agile community. At the 2008 Agile Conference in Toronto, there was a concerted effort to include papers and talks that went beyond development, and this philosophy seems to have carried over into the planning for the 2009 Agile conference to be held in Chicago this coming August.
I applaud the AC5's daring attempt to overcome the rampant prejudices of the extremists in both the CMMI and Agile camps in trying to bring the Agile Capulets and the CMMI Montagues together. On the Agile Project Management (APM) mailing list, Hillel Glazer recently reported that the general attitude amongst reviewers of the document was very much against this marriage, much like the situation that Romeo and Juliet faced. My hope is that the AC5 will persevere long enough to pull this marriage off, avoiding the tragic fate of Shakespeare's star-crossed lovers. It is time for the CMMI and Agile camps to bury the hatchet and find ways to work together effectively. It is possible, but first we must get over our misguided prejudices.
Hot Links
Examining the Agile Manifesto discusses the implications of the agile value statements as well as the 12 principles which support the values.
In Agile is Relative I explore myths and misconceptions.
In Agile CMMI: No Oxymoron I discuss some of the results of Dr. Dobb's 2008 Process Framework survey which found that agile and CMMI are being used in practice a fair bit.
In Repeatable Results over Repeatable Processes I examine results from Dr. Dobb's 2008 Process Framework survey, which found that people really do prefer repeatable results in practice.
Agile and Large Teams provides advice to organize small, medium, and large-sized agile teams.
For a few years now Hillel Glazer has written a blog about applying Agile techniques in a CMMI environment.
The SEI's CMMI website.
Here's where you'll find the results of the 2008 Process Framework survey, including the original questions as they were asked and the source data.
My Agility@Scale blogis where I discuss strategies for adopting and applying agile strategies in the complex environments.
