Agile CMMI: No Oxymoron

"Taking explicit note of bad things that can happen (risks) and planning for them accordingly is a mark of maturity. But that's not the way we tend to use the word maturity in the IT industry. We software people tend to equate maturity with technical proficiency. We even have a five-level scheme for measuring such maturity, the Capability Maturity Model (CMM). (All we need now is a 12-step program to help us wean ourselves from measuring maturity in a five-level scheme.) But the word maturity in standard English has nothing to do with technical proficiency. It is, rather, a quality of grown-up-ness, an indication that a person or organism has reached its adult state." —Tom DeMarco and Timothy Lister, Waltzing with Bears (Dorset House, 2003)

In the ongoing battle between traditional and agile methodologies, many proponents of each side exhibit a general intolerance to the other's ideas. However, this adversarial attitude is not just unreasonable, it's counterproductive to the task at hand: developing the highest-quality software in the shortest possible time.

To that end, approaches must be limited by neither hidebound structuralism nor free-flowing flexibility. To the new generation of agile practitioners, the 13-year-old Capability Maturity Model (CMM) may seem to symbolize all that's stodgy in traditional development. However, the melding of Software CMM with the Carnegie Mellon University Software Engineering Institute's other main maturity models (for systems engineering, software acquisition, workforce management and product development) in the form of CMM Integration (CMMI) deserves another look.

CMMI for the Organization, TSP for the IT Shop

The CMMI Product Suite provides a set of models, training and an appraisal method for an organization embarking on a process improvement effort. The CMMI website offers information about these components of the CMMI product suite, as well as adoption reports, return-on-investment (ROI) reports, mappings to other models and standards, and other information.

CMMI models consist of up to 25 process areas organized into four categories: Process Management, Project Management, Engineering and Support. Organizations that "adopt CMMI" establish and improve their processes to better comply with one or more (or all) of these 25 process areas.

While CMMI gives examples of processes and practices at the organizational level, it doesn't provide specifics for software developers and their teams—and that's where SEI's Team Software Process comes in. TSP implements most of the practices a software project team would have, through CMMI Level 5. Championed in 1998 by Watts Humphreys, TSP complements CMMI, and accelerates adoption, by providing the "how to" of the "what to do" found in CMMI.

Aerospace and telecommunications companies have been the most assiduous adopters of CMMI—understandably so, as these industries face complex designs and many interfaces. Finance, automotive and IT services aren't far behind. Furthermore, CMMI adoption isn't limited to the United States. Companies in more than 25 other countries have also made the move to CMMI, although about half of the appraisal reports come from the U.S.

So what's behind the buzz? The original vision for Software CMM (SW-CMM) lay not in process improvement models, but in developing a discipline for software engineering. CMMI extends that vision beyond the software-specific view in SW-CMM to support improvement in other domains such as systems engineering, as well as updating the best practices defined in SW-CMM, most notably with a new process area for measurement and analysis at Level 2 and process areas related to integration at Level 3.

Organizations working with CMMI often complement or extend it with other best practice initiatives such as Product Line practices, Earned Value Management, operational and service organizations, COTS-based systems, acquisition, marketing, Six Sigma, or ISO 9000. Although CMMI applies to both large and small organizations, the latter often lack the resources and knowledge required to initiate CMMI-based process improvement. "Smaller organizations and projects are encountering some difficulty implementing the CMMI due to the number of expected practices and the level of sophistication inferred," says Burnsville, Minnesota-based CMMI assessor Pat O'Toole. "The model's practices need to be interpreted in light of the work to be performed and scaled to provide value, not overhead."

To help small firms adopt CMMI, the Software Engineering Institute has recently made guidance and aids available. There are also now about 10 books published on CMMI itself.

The Agile Context

About the time CMMI 1.1 was released, the Agile Manifesto came into being ("The Agile Manifesto," Martin Fowler and Jim Highsmith, August 2001). According to its creators, the Manifesto was, in part, a reaction to more formulaic and documentation-driven processes and methodologies such as CMM. On its website, the Manifesto signatories laid out four values that would seem to be at odds with CMMI-based process improvement:

1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.

But only at first glance. As Kent Beck expounds, "In software development, optimism is a disease; feedback is the cure." CMMI and the Team Software Process provide this cure by example. TSP is a collaborative, team-focused, dynamic process that also supports agile values and principles (See "Agility vs. the Team Software Process").

In agile software development, the focus is on the customer, the team and the individual developer. TSP also emphasizes the customer, team and individual developer. It realizes this focus through a defined team process, defined roles and other guidance for the individual developer and the team. The processes, roles and other elements in TSP establish a self-directed team concept wherein the team members make their own plans and track their work, with customer participation throughout. CMMI extends this focus to the organization by providing a powerful, long-term learning and communication mechanism.

Finding and Feeding Conviction

"Software engineers develop their personal practices when they first learn to write programs. Since they are given little or no professional guidance on how to do the work, most engineers start off with exceedingly poor personal practices," writes Humphreys in "Pathways to Process Maturity: The Personal Software Process and Team Software Process, a June 1999 article posted on the SEI website.

Programmer motivation is a key to successful projects, and enhancing this motivation is a key to maturing the software discipline. How do we get motivated? The Team Software Process offers methods, tools and feedback mechanisms so that individuals can learn from their experiences and gain working knowledge of best practices.

Among the activities that TSP proposes are:

1. Making a quality plan and setting targets.
2. Making detailed plans for each engineer for the next phase and merging them into a team plan.
3. Balancing the team workload.
4. Assessing risks and assigning responsibility for tracking those that are important, and holding a launch postmortem.

CMMI focuses on learning at the organizational level (and provides both project-based and organizationally based mechanisms for such learning). But some organizations implementing CMMI struggle to create the necessary environment and infrastructure for individual and team empowerment. TSP provides a "how to" solution consisting of team roles and other guidance that directly implement most CMMI practices while addressing the needs of both teams and individuals. A concise description of TSP with examples can be found in Watts Humphreys' Winning with Software: An Executive Strategy (Addison-Wesley, 2002). The TSP website also provides information about TSP technology, training and adoption reports, including a mapping to CMMI.

Since the release of CMMI 1.1, we've learned that organizations adopting TSP as well as CMMI can more rapidly and significantly improve their process improvement results. Naval Air Systems Command's (NAVAIR) AV-8B Joint System Support Activity (JSSA) incorporated TSP into the process improvement effort to advance from Level 1 to Level 4 in 30 months, or about 2.5 times faster than the reported average of six years. Because TSP implements most of the CMMI practices, it reduces or eliminates much of the work involved in creating a high-maturity process (see Lisa Pracchia's The AV-8B Team Learns Synergy of EVM and TSP Accelerates Software Process Improvement", CrossTalk: The Journal of Defense Software Engineering, Jan. 2004). While these results are promising, SEI intends to further investigate this connection in the coming year. TSP also improves predictability, productivity (by 78 percent, according to one study) and product quality (one to two orders of magnitude).

Thus, TSP holds promise as an accelerator, instilling the discipline that individual practitioners and teams need to be truly self-directed and empowered. CMMI provides the organizational learning and infrastructure necessary to successfully adopt TSP. Together, these two technologies promise to continue maturing the software engineering discipline and practice.

Toward a Continual Evolution

Planned for release in late 2006, CMMI 1.2 will consolidate both staged and continuous representations in a manner very similar to what was done in CMMI 1.1 and is detailed in CMMI Guidelines for Process Integration and Product Improvement by Mary Beth Chrissis, Mike Konrad and Sandy Shrum (Addison-Wesley, 2003). Version 1.2 will include hardware amplifications and possibly an extension to service delivery (as options). Otherwise, only minor changes to clarify intent or improve model-appraisal method interactions are planned. SEI is also looking at other ways to simplify the model presentation. In addition, new courses will include one for executives and a "hands on" course intended to help a software engineering process group implement the model in their particular organization.

Gaining Ground

Since the release of 1.1 three years ago, CMMI adoption has enjoyed an impressive pace. Over 25,000 individuals have taken the Introduction to CMMI course. By way of contrast, it took almost 10 years for SW-CMM to peak at a smaller figure. Over 690 Standard CMMI Assessment for Process Improvement (SCAMPI) appraisals have been conducted. Additionally, there are over 230 Introduction to CMMI authorized lead instructors and 350 SCAMPI lead appraisers. Smaller organizations can also benefit from CMMI, and TSP can help an organization more rapidly achieve a high-maturity process culture. Finally, agile software development and disciplined software engineering are not, in fact, antithetical—indeed, agility can be better enabled by high maturity.