The Agile Architect

Are Agile and CMMI Compatible?

CMMI certification aligns with agile much more than you might think.

• By Mark J. Balbes, Ph.D.
• October 11, 2011

• For more on this topic, please see Part II: Agile and CMMI: Tips from the Trenches

Recently, I've been involved in a CMMI Maturity Level 3 (ML3) appraisal. Now, I can hear your groans. You're thinking that CMMI is yet another certification that leads companies toward heavyweight processes that favor waterfall methodologies and a lot of paperwork. That's what I originally thought, too. In fact, our work toward this appraisal has been refreshingly valuable and relatively easy.

Why do we want a CMMI ML3 rating? Frankly, it's for the money. We are a project shop that works on government contracts. We are finding that more and more of these contracts are requiring a CMMI maturity level rating or equivalent. Rather than prove equivalency for each contract proposal, it is easier to get an official appraisal.

If you aren't familiar with the Capability Maturity Model Integration (CMMI), you can read about it at the Carnegie Mellon Software Engineering Institute Web site. In essence, CMMI defines a model for the maturity of an organization's engineering practices. During the appraisal, you demonstrate your organization's maturity in areas such as requirements management, project planning, risk management and decision analysis.

To achieve maturity level 2, you must demonstrate that your individual engineering projects are mature. A company can achieve maturity level 2 by hiring good project managers that manage their projects well -- but in different ways.

To achieve maturity level 3, you must demonstrate that the organization as a whole has processes in place to ensure the success of the projects. In other words, you are demonstrating that the success of your projects is reproducible across the organization.

Despite what you may have heard, agile practices lend themselves very well to a high CMMI maturity level. The trick is to approach the appraisal with the right perspective. While the model itself is divided into specific practices, it does not tell you how to do these practices. Agile methodologies tend to address multiple practices at once.

Mapping CMMI to Agile
Let me give you a specific example. The Technical Solutions Process Area in CMMI ML3 has 3 specific goals, each with specific practices:

1) Product or product component solutions are selected from alternative solutions.
1.1 Develop alternative solutions and selection criteria.
1.2 Select the product component solutions based on selection criteria.

2) Product or product component designs are developed.
2.1 Develop a design for the product or product component.
2.2 Establish and maintain a technical data package.
2.3 Design product component interfaces using established criteria.
2.4 Evaluate whether the product components should be developed, purchased or reused based on established criteria.

3) Product components, and associated support documentation, are implemented from their designs.
3.1 Implement the designs of the product components.
3.2 Develop and maintain the end-use documentation.

For someone not familiar with agile and whose only interest is in passing an appraisal, it would be easy to create waterfall processes to address each of these specific practices. To be fair, the above does read like a description of a waterfall process. Yuck! 

Luckily, agile techniques can address these same goals and practices. Let's map some agile techniques to the CMMI practices:

Spiking is an agile technique that allows a team to explore alternatives without the overhead of creating production quality code. The rules for a spike are to write only as much code as necessary to learn what is needed and then to throw that code away when done. A spike starts by creating the criteria for the solution you are looking for. During the spike, you evaluate alternatives to determine which meet these criteria. This might involve writing code, evaluating third-party products, measuring performance or whatever is necessary. A spike ends with a recommendation on how to move forward.

By spiking, you've accomplished the specific practice 1.1, 1.2 and 2.4.

Test-Driven Development (TDD) is an agile technique that is used to develop production-quality software. It follows a cycle of test-code-refactor. The idea is to write an automated unit test to describe what you want the system to do, do the simplest thing possible to make the test pass while keeping all other tests passing and finally refactor the simple solution to a good design. The outcome of TDD is not only production-quality code but also a suite of tests that ensure the software doesn't break and act as living technical documentation of your system. In addition, TDD naturally creates appropriate interfaces between components of your system.

By using TDD, you've accomplished the CMMI specific practices 2.1, 2.2, 2.3 and 3.1.

XP Iteration Planning, Kanban and Scrum are agile project management techniques that allow the customer to prioritize the stories that will be part of a release. Stories about the creation of end-user documentation are prioritized along with development stories.  On my project, the customer has explicitly prioritized end-user documentation out of our releases (in other words, they don't want it), which is perfectly acceptable to CMMI.

By using agile project management techniques, you've accomplished the CMMI specific practice 3.2.

The above mapping is meant as an example. There are many more agile techniques that support CMMI practices.

Where is the evidence?
The hardest part of preparing for a CMMI appraisal is finding the evidence to prove that you actually do all of the CMMI practices. After all, the Agile Manifesto states specifically that it values "Working software over comprehensive documentation." It turns out that it's easier than you might expect. You just have to know where to look. And that will be the subject of my next column... Agile and CMMI: Tips from the Trenches