Channels ▼
RSS

Agile CMMI: No Oxymoron


Agile CMMI

"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.

 

Agility vs. the Team Software Process
Agile software development is anything but antithetical to TSP.

Agile Value Statement How TSP Relates
Individuals and interactions over processes and tools TSP holds that the individual is key to product quality and effective member interactions are necessary to the team's success.
  • Project launches strive to create gelled teams.
  • Weekly meetings and communication are essential to sustain them.
  • Teams define their own processes in the launch.

Working software over comprehensive documentation

 TSP teams can choose evolutionary or iterative lifecycle models to deliver early functionality—the focus is on high quality from the start. TSP does not require heavy documentation.

  • Documentation should merely be sufficient to facilitate effective reviews and information sharing.

Customer collaboration over contract negotiation

Learning what the customer wants is a key focus of the launch. Sustaining customer contact is one reason for having a customer interface manager on the team.

  • Focus on negotiation of a contract is more a factor of the organization than of whether TSP is used.

Responding to change over following a plan

TSP teams expect and plan for change by:

  • Adjusting the team's process through process improvement proposals and weekly meetings.
  • Periodically relaunching and replanning whenever the plan is no longer a useful guide.
  • Adding new tasks as they are discovered; removing tasks that are no longer needed.
  • Dynamically rebalancing the team workload as required to finish faster.
  • Actively identifying and managing risks.


Mike Konrad is a senior member of the technical staff at the Carnegie Mellon Software Engineering Institute and has been co-leader or leader of every CMMI model development effort since 1998. Konrad joined the SEI in 1988; his 24 years' experience in software includes positions in commercial and defense industries and universities. James W. Over is also a senior member of the SEI's technical staff, in charge of the Team Software/Personal Software Process Program. Before joining the SEI in 1987, Over was director of information systems for Pulitzer Publications in Chicago.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Comments:

Video