The Goal

The SEI is often identified with its CMM® work. Over the years, the SEI has developed six Capability Maturity Model products. Some are new and build on the work of the older ones.

CMMs that the SEI is currently involved in developing, expanding, or maintaining are

* CMMI®(Capability Maturity Model Integration)

* P-CMM (People Capability Maturity Model)

* SA-CMM (Software Acquisition Capability Maturity Model)

Legacy CMMs that have been incorporated into CMMI models, and therefore are no longer maintained are

* Capability Maturity Model for Software (SW-CMM)

* Systems Engineering Capability Maturity Model (SE-CMM)

* Integrated Product Development Capability Maturity Model (IPD-CMM)

SEI work that is very closely related to the development, support, and maintenance of CMMs includes

* Publishing appraisal results - in the Maturity Profile

* Working with standards organizations to help further the cause of for software process improvement

* Improving and supporting CMM-based appraisals of organizations

The SEI's goals in developing CMMs include

* addressing software engineering and other disciplines that have an affect on software development and maintenance

* providing integrated process improvement reference models

* building broad community consensus

* harmonizing with related standards

* enabling efficient improvement across disciplines relevant to software development and maintenance

Extreme Programming

and the

Capability Maturity Model

Ron Jeffries

01/01/2000

A discussion on comp.software-eng asked what people thought of eXtreme Programming, suggesting that it might be approximately an SEI Level 1 process. In these pages, we'll look at the descriptions of the CMM levels and at some corresponding aspects of eXtreme Programming as practiced on the Chrysler C3 project.

My assessment overall is that XP has some characteristics in common with the higher SEI levels, up to and including level 5. However, I would not assert that an XP team is a level 5 team. It takes a lot more documentation and "proving" going on in CMM than we recommend for XP. XP is in some ways a "vertical" slice through the SEI levels 2 through 5.

Comments are welcome via wiki, or email.

In the following, sections in italics are quotations from The Capability Maturity Model, CMU/SEI, Paulk et al, Addison-Wesley, 1995, ISBN 0-201-54664-7.

[ Level 1 ] [ Level 2 ] [ Level 3 ] [ Level 4 ] [ Level 5 ]

SEI Level One

At the Initial Level, the organization typically does not provide a stable environment for developing and maintaining software. Overcommitment is a characteristic of Level 1 organizations, and such organizations frequently have difficulty making commitments that the staff can meet with an orderly engineering process, resulting in a series of crises. During a crisis, projects typically abandon

planned procedures, and refert to coding and testing. Success depends on having an exceptional manager and a seasoned and effective software team.

Success in Level 1 organizations depends on the competence and heroics of the people in the organization and cannot be repeated unless the same competent individuals are assigned to the next project. Thus, at Level 1, capability is a characteristic of the individuals, not of the organization.

ExtremeProgramming specifically prescribes two levels of scheduling, which make up the PlanningGame. These levels, called CommitmentSchedule and IterationPlan, are based on developers' own estimates for the production of the necessary software. The joint CommitmentSchedule process results in a comprehensive estimate of what will be produced, and when. The joint IterationPlan schedules a short interval, and results of each iteration feed back into the CommitmentSchedule to refine the schedule. C3 progress is in no way characterized by a series of crises.

The C3 team specifically prohibits heroics, and works almost no overtime. Instead, the team treats a desire for heroics as an indication that there is something wrong with the process. They dig in and determine what is going wrong, and fix the process.

While the C3 team members are quite competent, they are generally not exceptional. The team's PairProgramming practice brings two good minds to bear on each problem: this is generally better than bringing one excellent mind to bear.

The team manager offers no exceptional support. Rather, he serves only to track progress, and to interface to management, with all technical decisions and assignements being done jointly by the team and by a volunteer process.

A second Extreme Programming project, with a new team, has not yet been attempted at Chrysler, so we cannot yet speak to how well the success will be replicated. Our thoughtful opinion, however, is that it is our process, not us as individuals, that is making C3 work so well.

SEI Level Two - Repeatable

At the Repeatable Level, ... projects implement effective processes that are defined, documented, practiced, trained, measured, enforced, and improvable.

ExtremeProgramming clearly specifies a number of practices (Extreme Programming Rules). These are well-defined, and are documented. The team has been trained at the beginning of the project, has a full-time coach, and trains new members in the team practices. Practices are generally measured and enforced by the shared responsibility of the team. Pair Programming and an open process ensure that all developers know what is happening all over the system. In the rare instances where a developer may violate one of the team's practices, the offending developer will be advised, reprimanded, or, in rare cases, allowed to work on some other project.

The