Implementing Scrum (Agile) and CMMI Together

4 February 2011

Neil Potter
The Process Group

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

 

REQUIREMENTS MANAGEMENT:  

 

 

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.

 

 

 

 

REQM CMMI Practice Scrum Practice
SP 1.1 Develop an understanding with
the requirements providers on the
meaning of the requirements.
• Review of Product Backlog (requirements) with Product owner and
team.
SP 1.2 Obtain commitment to the
requirements from the project
participants.
• Release planning and Sprint planning sessions that seek team
member commitment.
SP 1.3 Manage changes to the
requirements as they evolve
during the project.
• Add requirements changes to the Product Backlog.
• Manage changes in the next Sprint planning meeting.
SP 1.5 Identify inconsistencies between
the project plans and work
products and the requirements.
• Daily standup meeting to identify issues.
• Release planning and Sprint planning sessions to address
inconsistencies.
• Sprint burndown chart that tracks effort remaining.
• Release burndown chart that tracks story points that have been
completed. This shows how much of the product functionality is left
to complete.

 

 

 

 

 

 

 

PROJECT PLANNING

The purpose of Project Planning (PP) is to establish and maintain plans that define project activities.  

PP CMMI Practice Scrum Practice
SP 1.1 Establish a top-level work
breakdown structure (WBS) to
estimate the scope of the project.
• The standard tasks used in a Scrum process combined with specific
project tasks (Scrum Backlog).
SP 1.2 Establish and maintain estimates of
the attributes of the work products
and tasks.
• Story points, used to estimate the difficulty (or relative size) of a
Story (requirement).
SP 1.3 Define the project life-cycle phases
upon which to scope the planning
effort.
• The Scrum process.
SP 1.4 Estimate the project effort and cost
for the work products and tasks
based on estimation rationale.
• Scrum Ideal Time estimate (similar to billable hours or Full-time
Equivalents).
SP 2.1 Establish and maintain the project’s
budget and schedule.
• Scrum estimates (in Ideal Time).
• Estimates of what work will be in each release.
• Sprint Backlog.
• Project Taskboard.
SP 2.4 Plan for necessary resources to
perform the project.
• Scrum estimates in Ideal Time
• Release plan, Sprint Backlog and assignments.
SP 2.6 Plan the involvement of identified
stakeholders.
• Scrum process roles (including team, Scrum Master, Product Owner).
• [Note: The stakeholders listed in Scrum might not be the complete list
of stakeholders for the project, e.g., customers, other impacted teams.]
SP 2.7 Establish and maintain the overall
project plan content.
• Scrum release plan.
• Sprint Backlog.
• Project Taskboard.
• [Note: The term “plan” in CMMI refers to additional plan
components (such as risks and data management) that are not called
out specifically in Scrum.]
SP 3.1 Review all plans that affect the
project to understand project
commitments.
• Sprint planning meeting.
• Daily Scrum meeting.
SP 3.2 Reconcile the project plan to reflect
available and estimated resources.
• Sprint planning meeting.
• Daily Scrum meeting.
SP 3.3 Obtain commitment from relevant
stakeholders responsible for
performing and supporting plan
execution.
• Sprint planning meeting.
• Daily Scrum meeting.
• [Note: The stakeholders listed in Scrum might not be the complete list
of stakeholders for the project.]

 

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.

PMC CMMI Practice Scrum Practice
SP 1.1 Monitor the actual values of the
project planning parameters against
the project plan.
• Sprint burndown chart that tracks effort remaining.
• Release burndown chart that tracks completed story points. This
shows how much of the product functionality is left to complete.
• Project Task Board used to track stories (requirements) that are done,
in progress, or ones that need verification.
SP 1.2 Monitor commitments against those
identified in the project plan.
• Discussions on team commitments at the:
− Daily Scrum meeting.
− Sprint review meeting.
• Sprint burndown chart that tracks effort remaining.
• Release burndown chart that tracks story points that have been
completed. This shows how much of the product functionality is left
to complete.
SP 1.5 Monitor stakeholder involvement
against the project plan.
• Discussions at the:
− Daily Scrum meeting.
− Sprint review meeting.
• [Note: The stakeholders listed in Scrum might not be the complete list
of stakeholders for the project, e.g., customers, other impacted teams.]
SP 1.6 Periodically review the project's
progress, performance, and issues.
• Daily Scrum meeting.
• Sprint review meeting.
• Retrospectives.
SP 1.7 Review the accomplishments and
results of the project at selected
project milestones.
• Sprint review meeting.
SP 2.1 Collect and analyze the issues and
determine the corrective actions
necessary to address the issues.
• Notes from the:
− Daily Scrum meeting.
− Sprint review meeting.
[Note: Some teams track their outstanding actions on the Product
Backlog. It doesn’t matter where or how the items are tracked, as long
as they are.]
SP 2.2 Take corrective action on identified
issues.
• Actions from the:
− Daily Scrum meeting.
− Sprint review meeting.
SP 2.3 Manage corrective actions to
closure.
• Tracking of actions from:
− Daily Scrum meeting.
− Sprint review meeting.
• [Note: This assumes that teams will track (and not lose) actions.]

 

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 Quality Assurance (PPQA)
Some basic PPQA activities are being done 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 testing. The Scrum Master also plays a role of removing process barriers and inefficiencies. However, Scrum does not specifically call out a level of objective process and product check, nor does it state that particular standards or processes should be defined and used. Therefore Scrum does not automatically implement PPQA. However, refinements can be made such that it does.

Supplier Agreement Management
There are no practices in Scrum that deal with the selection and management of suppliers.

Generic Practices
Approximately half of the Level 2 Generic Practices of Requirements Management, Project Planning and Project Monitoring and Control are implemented by
Scrum. A mapping of these is at www.processgroup.com/scrum-cmmi-mapping-magp-v1.pdf.

Measurement and Analysis
The purpose of Measurement and Analysis (MA) is to develop and sustain a measurement capability that is used 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. A mapping showing the relationship between CMMI and Scrum measurements is at www.processgroup.com/scrumcmmi- mapping-ma-gp-v1.pdf.

How about Level 3?
There are two main areas where Scrum has gaps compared to Level 3. One is in the CMMI expectation that project data and lessons are shared among
projects via a common process asset library (or repository). Second, the expectation that the engineering phases of requirements, design, implementation, verification, integration and validation are well defined and implement the Level 3 engineering practices. These CMMI concepts can be done in an Agile/Scrum environment, but they don’t come with the common Scrum definition.

Scrum does suggest implementing Communities of Practice, to reach across teams to share lessons learned, and Retrospectives within a team. These ideas could certainly be used to populate an asset library and thereby codify best practices and tailoring guidelines. The following Level 3 components therefore are not readily implemented by Scrum without additional work:

• Organizational Process Focus
• Organizational Process Definition
• Organizational Training
• Integrated Project Management
• Risk Management
• Decision Analysis and Resolution
• Some engineering Specific Practices (e.g.,
requirements validation and verification data
analysis)
• Generic Goal 3 (i.e., using an organization-wide
and tailored process with measurements)

Summary
Scrum is a good implementation for some of the practices in Level 2. Therefore, a group can use Scrum and CMMI together. All the remaining practices in Levels 2 and 3 can be implemented while using Scrum.

Overview of Scrum

Scrum is a process that teams can adopt quickly to plan and manage their work. Each Scrum step has just enough detail to plan, design, build and test code, while tracking team progress. Its strength is that it is straightforward to use. The risk is that it can be used to focus on building components with less regard for the complete system. This risk can be managed.

Scrum has three primary roles: Product Owner, Scrum Master, and team member.

The Product Owner communicates the vision of the product to the development team. This includes representing the customer’s interests through requirements and prioritization.

The Scrum Master acts as a liaison between the Product Owner and the team. The Scrum Master does not manage the team but instead works to help the team achieve its Sprint goals by removing obstacles. The Scrum Master verifies that the Scrum process is used.

The team members do the project work. The team typically consists of software engineers, architects, analysts and testers.

The intent of Scrum is to build working components in small iterations, each iteration lasting between two and four weeks. A typical Scrum lifecycle has the following steps:
• Write the requirements (and store in the
Backlog)
• Plan the release (which could span more than
one 2-4 week Sprint)
• Plan the Sprint
• Conduct the Sprint
- Analysis
- Design
- Coding
- Testing
• Conduct Sprint retrospective

Daily stand-up meetings are held to track team progress and identify barriers.
[See www.scrumalliance.org]

Neil Potter and Mary Sakry are both certified Scrum Masters and certified High Maturity CMMI Lead Appraisers. Neil is a Six Sigma Greenbelt.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 3.7 (3 ratings)

Comments

Gabriela Mizarela Jardim, CSM, 2/9/2011 6:24:07 AM
Excellent article!
Mariano Nassif, CSM, 2/9/2011 7:27:28 AM
Hi Neil, great article. I've a doubt, what about Level 4 and 5?. It's posible to implement together?
Russell Pannone, CSM,CSPO, 2/17/2011 12:22:42 PM
Neil,

I am the Editor-In-Chief of the Agile Journal. I would like to publish this article in the Agile Journal.

If you would like to have it published send a MS Word version to me at Russell.Pannone@cmcmedia.com.

Take care,
Russell

Arijit Sarbagna, CSP,CSM, 3/2/2011 1:20:14 AM
Neil,
Excellent article. I am actively pursuing Scrum for over 5 years now & it seems that we can/should embrace the model that CMMi suggests - with relative ease. As it stands (& as you have explained), Scrum is internally practicing most of the processes that CMMi advises & with a bit of innovation or process tuning/tweaks, all of the SP/GPs could be well aligned with Scrum.
I look forward to use this forum to share my experience as well & look forward to more such articles.

Getting to Mariano's query: Yes, absolutely! Level 4 & 5 talks about OPP, QPM & CAR, OPM. Now, QPM & CAR are already there in Scrum. Perhaps I will take this opportunity to publish an article on L4/L5 mapping to CMMi model. Stay tuned. :)
Priyesh Gopalakrishnan, CSM, 3/3/2011 4:03:13 AM
Excellent article. I was looking for an article on this subject. Do you think SEI is aligned to this mappings and they will accept this as evidence during the appraisals
Tomo Lennox, CSM,CSPO, 3/11/2011 11:31:10 AM
I like the idea of taking the best ideas you can find and trying to use them for continuous improvement, so this is very interesting. But even though is can be done, should it be done?

I think Configuration Management is one of the corner stones of productive software and CMMI provides useful objectives for it. Scrum does not address it at all, and there is no conflict with it's underlying principles. So I agree that they go together nicely, especially if it can be automated, so that it does not conflict with the Agile "go fast" concept.

But even the half of the Level 2 practices that kind-of line up can generate a lot of extra overhead that directly trades off with the Agile principles. So trying to do both makes the Agile efforts less successful. Do the advantages make up for it? It doesn't feel like it would. Even though you got the words on the surface to sort of match up, I would hope to understand how the underlying objectives can be reconciled.

Most fundamentally, a major principle of CMMI is to reduce variation. Agile encourages variation in the form of creativity in diverse teams, and in its response to feedback. CMMI requires detailed documentation to support monitoring and analysis. Agile reduces documentation when it can help achieve the higher goal of rapid development.

I am pretty sure that I could find a lot of similar rules between football and baseball. I might be able to come up with a set of rules that described both games. But if you played by those rules, I don't think you would get a game that either football fans nor baseball fans would like, and there is no indication that anyone would find it fun.
Anita Upadhyay, CSM, 4/1/2011 8:44:50 AM
I would like to hear your thoughts on mapping to level 4 and level 5.
Mateus Pereira Dias, CSM, 4/29/2011 2:27:03 PM
Neil, excellent mapping! thanks for sharing your ideas!
Christopher Cobb, CSM, 3/12/2012 7:53:05 AM
I think its important to keep in mind that the only *REQUIRED* parts of CMMI are the Specific Goals (SGs), which are at a higher level and more general than the Specific Practices (SPs) listed here. You may want to have a peek at the SPs to understand what they are getting at with some of the more vaguely worded SGs. But all you are required to meet is the wording of the SGs. The Specific Practices are merely recommendations as to how you might meet a Specific Goal. As long as all of your defined processes have a clear Purpose, defined Inputs, testable Entry criteria, specific Activities, identified Roles, associated Measures, prescribed Verification steps, defined Outputs, and
testable Exit criteria, then you can focus on fulfilling the more general Specific *Goals* rather then the more detailed Specific Practices. This allows you to make your processes more Scrummish.
Abdelkader Rhouati, CSM, 5/21/2012 11:52:17 AM
excellent Article !

the most important thing in Scrum,, is the self-organization, this is why we can use any process, CMMI in this article, in the "Conduct Sprint step".

the mapping between Scrum and the CMM practices have been approved by the SEI for CMMI check ?
Neil Potter, CSM, 10/29/2013 3:03:50 PM
Well, sorry. I had no idea these comments were here. So for completeness.
a) I have appraised many organizations that used this mapping at both level 2 and 3. SEI/CMMI-I accepted the results - No problems.
b) "CMMI reduces process variation" is mostly true at Level 5. "Agile encourages variation" is a total different type of variation (creativity).
c) How about Level 4+5? These are possible to add to scrum, but nothing in scrum provides direct ML4/5 assistance, only a foundation on which to work.

I will now check this page more often!

You must Login or Signup to comment.