Mapping the Agile Scrum and CMMI

Mapping the CMMI and Scrum 

CMMI practices are designed to provide value across a range of different situations and thus are stated in general terms. Because CMMI does not endorse any particular approach to development, little approach-specific information is provided. Therefore, those who don’t have prior experience implementing CMMI in situations similar to their current situation may find it difficult to interpret the practices. The following tables identify relevant CMMI practices for complying with maturity level 2 (using text taken from the model). They also show how Scrum practices were implemented in each CMMI specific practice (SP) on the large project. To be appraised at maturity level 2, the Scrum implementation had to show evidence of CMMI practices being performed. A discussion of the program’s CMMI maturity level 3 processes follows later.

CMMI Maturity Level 2 Process Areas Requirements Management The purpose of requirements management (REQM) is to manage the project’s products and product components requirements. It also helps to identify inconsistencies between those requirements and the project’s plans and work products. 

Project Planning 

The purpose of project planning (PP) is to establish and maintain plans that define the project’s activities.

Project Monitoring and Control 

The purpose of project monitoring and control (PMC) is to understand the project’s progress so that appropriate corrective actions can be taken when the project’s performance deviates significantly from the plan.

Configuration Management (CM) 

CM is not specifically called out in Scrum. However, in an Agile environment it is easy to add a layer of CM to protect work products. Even for groups that like to use white boards, you can be creative and at least establish some basic protection by labeling items (e.g., “V1.1” or “Story dated YYYY/MM/ DD”), by taking a photo, or by using other documenting techniques. The CM process area requires more than just versioning, but versioning is a good and fundamental start. Product and Process Quality Assurance (PPQA) Some basic PPQA activities are being accomplished naturally when the Scrum master checks that the Scrum process is being followed. Other PPQA activities are completed when a team performs code reviews, document reviews and validation testing. The Scrum master also removes process barriers and inefficiencies. However, Scrum does not specifically call out a level of objective process and product check, nor does it say that particular standards or processes should be defined and used. Therefore, Scrum does not automatically implement PPQA. However, refinements can be implemented to support a PPQA claim.

Supplier Agreement Management 

There are no practices in Scrum that deal with selecting and managing suppliers.

Measurement and Analysis 

The purpose of measurement and analysis (MA) is to develop and sustain a measurement capability to support management information needs. There are no practices in Scrum that establish a measurement program similar to the expectations of MA. However, the measures in Scrum can be used to implement MA