In This Issue
- Agile CMMI?
- Hot Links
- Agile CMMI?
- Hot Links
One issue I'm often asked about is whether agile software development and the Software Engineering Institute (SEI)'s Capability Maturity Model Integrated (CMMI) work together, if at all. This question is particularly common from people working in organizations where CMMI is already in place and they're trying to adopt agile concepts to improve the way that they work. I'm also starting to hear it from people who are scaling agile approaches to meet the needs of larger or distributed teams, to conform to regulations, who are working with significant legacy systems, and so on. My answer is always the same: CMMI is simply a requirement specification for a development process, no more and no less. Although many CMMI-compliant processes are overly bureaucratic and inefficient, there is nothing stopping you from combining the best of the two and come up with a streamlined "Agile CMMI" approach. However, the real question is whether or not it makes sense to do so.
In January, Dr. Dobb's ran a surveywhich explored the adoption rate and effectiveness of various process frameworks, one of which was CMMI. The survey ran for a week and was promoted in Jon Erickson's blog and in a mailing which went out to Dr. Dobb's readers. The response rate was unusual for us, I suspect because of the topic: Only 339 started the survey, the lowest survey response rate that we've ever gotten, and only 219 completed it -- many people were turned off by the second of five pages which explored frameworks such as COBIT, ITIL, and Zachman, all of which appear to have low adoption rates (more on this in my next newsletter). In hindsight, which is always 20/20, I should have asked about these things last. When it comes to Agile and CMMI, we had the following response rates:
- 127 respondents indicated that their organizations were doing agile projects.
- 13 (10%) indicated that they were exclusively doing CMMI-compliant agile projects
- 57 (45%) said they were exclusively doing non-CMMI agile projects
- 57 (45%) said that their organization had both CMMI compliant and non-CMMI projects.
The survey, which also asked about traditional projects, found the following success rates:
- 57.6% for CMMI-compliant traditional projects (107 responses)
- 56.8% for non-CMMI Agile projects (114 responses)
- 54.8% for non-CMMI traditional projects (172 responses)
- 53.4% for CMMI-compliant Agile projects (70 responses)
I have several observations that I'd like to share.
- First and foremost, organizations are in fact doing Agile and CMMI together, contrary to popular belief.
- Second, I was surprised at how close the success rates were.
- Third, it appears that although CMMI appears to slightly improve your chances of success on traditional projects it decreases it on agile projects. I suspect that this is a reflection of the cultural differences between the two communities: CMMI organizations are often command-and-control oriented whereas agile teams are collaborative and self-organizing. In many ways adopting agile is far more about changing your organizational culture than it is about adopting cool new techniques or tools, so many CMMI organizations may find it very difficult to become more agile.
- Fourth, the survey didn't specifically ask about productivity, quality, or stakeholder satisfaction, three issues where agile approaches seem to do much better than traditional approaches. This could explain why the success rates were lower than reported in the 2007 Success Survey (71.5% success rate for agile projects compared with 62.8% for traditional projects). In the success survey, we first explored the importance of quality, scope, value, schedule, and team health and then asked people to judge the success of various types of projects as they judge success. In this current survey we didn't do that, so I suspect that people are defining project success in terms of "relatively on time, on budget, and to specification" as they've been told to do for several decades now.
When it comes to Agile and CMMI, the survey could have gone into more detail. For example, it didn't distinguish between CMM and CMMI, nor did it distinguish between staged CMMI and continuous CMMI. We also didn't ask about the CMMI level they were at, which would have been interesting to see if there's a relationship between level and willingness to consider agile. I've worked in several level 4 or level 5 organizations that are very interested in agile techniques because the metrics they're collecting are showing them that they still have a lot of room for improvement. So, it would be interesting for someone to do a follow on from this survey and look into these issues.
Both Agile and CMMI are here to stay for the foreseeable future, and as a result your organization will want to take both seriously and apply each, where appropriate, in the most effective manner possible. Having worked with dozens of organizations around the world to help improve their software processes, I've made two critical observations that I'd like to share with you. First, because of its complexity, in practice CMMI enables bureaucrats to get their hands into the development process, and when that happens you start to run into serious efficiency problems. Second, because of the marketing rhetoric surrounding it, Agile enables the ad-hoc hackers among us to adopt a veneer of respectability by claiming to be Agile, even when it is obviously clear that they're anything but Agile. As the roll-call sergeant used to say in "Hill Street Blues" let's be careful out there.
For a few years now Hillel Glazer has written a blog about applying Agile techniques in a CMMI environment.
The SEI's CMMI web site is www.sei.cmu.edu/cmmi/.
The results of this survey, including the original questions as they were asked and the source data, will be posted towards the end of March 2008 at www.ambysoft.com/surveys/processFramework2008.html.
See my Agile@Scale blog.
The Agile Alliance homepage is the best starting point for anyone interested in
The Agile Models Distilled page provides links to overviews of a wide variety of models.
The Principles of Agile Modeling v2 are described here.
The Practices of Agile Modeling v2 are described here.
Check out the Agile Modeling mailing list.