If you are a software engineer or IT professional, your group has very likely shown a strong interest in reducing costs, improving quality and productivity. Your group might also have looked at various pre-packaged frameworks, such as Agile (e.g., Scrum and Extreme Programming), CMMI1, and Six Sigma.
At first glance, each of these frameworks might look at odds with each other, making it difficult to use two or more. This typically occurs because much of the information shared regarding these frameworks is from success and failure stories, rather than understanding the specifics of each framework. Each framework can be implemented successfully depending on how much care is placed on its implementation.
In this article we compare CMMI and Scrum since they are two commonly used frameworks, and ones we have seen groups struggle with when using them together.
First, let us define each briefly.
Scrum is a pre-defined development lifecycle based on Agile principles. Agile methodologies promote a project-management process that encourages frequent inspection and adaptation, and a leadership philosophy using teamwork, self-organization and accountability.
CMMI for Development
CMMI is a collection of practices that organizations (software, hardware and IT) can adopt to improve their performance. The CMMI comes with two main views (representations), Staged and Continuous. Staged shows all the Process Areas (groups of related practices) in the form of a road map, allowing organizations to focus on basic improvements before attempting advanced topics. The Continuous representation has the same content but allows for any topic (Process Area) to be selected in an a la carte style. [See www.sei.cmu.edu/cmmi/tools/]
The Level 2 Process Areas focus on change and project management. Level 3 focuses on engineering skills, advanced project management and organizational learning. Levels 4 and 5 focus on the use of statistics to improve the organization’s performance by statistically controlling selected processes and reducing variation.
So the question is, how do these two frameworks relate, and how can an organization use both?
Scrum is an example implementation of some of the Maturity Level 2 practices. Below we have listed the main practices of CMMI that map cleanly to Scrum process steps. This doesn’t mean that an organization could not eventually add additional CMMI practices to its projects; it just means that in Scrum, there is no clear equivalent called out.
Although the practices of Scrum provide good implementation examples of many Level 2 CMMI practices, one catch is the level of artifacts needed to appraise at CMMI Level 2. If a Scrum team either discards or loses its project artifacts, then being appraised Level 2 will not be possible since there will be little evidence showing what happened. If however, a project team stores these data, an appraisal team can then use them for verification. Ideally, Scrum team members would naturally want to store their work so that they could refer to past iterations during lessons-learned sessions.
CMMI and Scrum mapping
In the tables below we show several CMMI practices (using CMMI text taken from the model definition) and how Scrum can implement each practice. To appraise Level 2, it is assumed that the Scrum implementation is robust and shows evidence of the CMMI practice being performed.
The purpose of Requirements Management (REQM) is to manage the requirements of the project’s products and product components and to identify inconsistencies between those requirements and the project’s plans and work products.
The purpose of Project Planning (PP) is to establish and maintain plans that define project activities.
PROJECT MONITORING AND CONTROL
The purpose of Project Monitoring and Control (PMC) is to provide an understanding of the project’s progress so that appropriate corrective actions can be taken when the project’s performance deviates significantly from the plan.
How about the other components of Level 2?
Configuration Management (CM)
CM is not specifically called out in Scrum. However, in an Agile environment it is pretty easy to add a layer of CM to protect your work. 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 1/2/YY”) and taking a photo. The CM Process Area does require more than just versioning, but versioning is an easy start.
Product and Process