Can Scrum help to improve the project management process? A study of the relationships between Scrum and Project Management process areas of CMMI-DEV 1.3.

Dr. Javier Garzás
Kybele Research and Kybele Consulting
Rey Juan Carlos University
Tulipán s/n
Móstoles – Madrid –Spain

Dr. Mark C. Paulk
Institute for Software Research
Carnegie Mellon University
5000 Forbes Avenue, Wean Hall 5101
Pittsburgh, PA 15213

Abstract: Scrum has emerged as one of the most popular agile methods. Currently, CMMI-DEV is the de-facto framework for software process improvement and for determining the organizational maturity of software development companies. This paper focuses on the relationships between Scrum and Project Management process areas of CMMI-DEV 1.3, and how there is great synergy between Scrum with CMMI-DEV.

Keywords: Scrum, Agile, CMMI-DEV, project management process areas.

1.     Introduction

As Austin [1] argues, every decade or so development methodologies come into conflict, and the first decade of the 21st century has been no different with supporters of agile methods doing battle with the SW-CMM / CMMI world. However today the current trends lie somewhere in the middle and the old war between CMMI and Agile has given us the opportunity to make both approaches better. Increasingly, agile methodologies are widely used with CMMI (Coleman, O’Connor, 2008) and most authors suggest that great synergy comes from using agile methods with CMMI [2].
Scrum, originally described by Jeff Sutherland and Ken Schwaber, has emerged as one of the most popular agile methods. Scrum could be described as a project management methodology, or an iterative and incremental development framework. Scrum can be characterized by a relatively small set of agile practices. Scrum may be adapted and is frequently adopted with other agile practices or methods such as Extreme Programming (XP) [3].Capability Maturity Model Integration for Development (CMMI-DEV)[4] is currently the de-facto framework for process improvement and for determining the organizational maturity of software development companies, and many organizations have gained greater levels of productivity and product quality from achieving “levels” of CMMI-DEV.
CMMI-DEV and Scrum share certain characteristics, even though they were developed for different purposes. They can be complementary to each other, and they are not (necessarily) in competition. In this paper we will argue that both can be used. Each focuses on a different level of abstraction: CMMI focuses on what organizations do, including their projects, and Scrum focuses on how projects develop products. As Glazer and colleagues [5] argue, Scrum provides a software project management how-to that is missing in CMMI, and CMMI provides the process management to continuously improve the use of Scrum. CMMI-DEV outlines “what to do,” but it doesn’t explain “how to do” it. Agile methods, such as Scrum, are best practices that contain a how-to for a particular type of environment [6][5]. Johnson and Sutherland (2010)suggest that great synergy comes from using Scrum with CMMI-DEV: Scrum brings increased value to CMMI-DEV and CMMI-DEV brings increased value to Scrum.
For some time now, there have been several initiatives specifically oriented at putting together processes and agile method. Different studies present mappings between agile practices and software development process models such as CMMI-DEV. Authors such as [5] and [2]comment that CMMI and agile methods can work together, because they work at different levels of abstraction, CMMI-DEV sets out what to do while agile methods are guidelines on how to carry it out. In the case of Scrum, [7] and [8] discussed the relationships between CMMI-DEV Level 5, high level maturity, and Scrum. Other authors, such as [9] identified the relationships between CMMI-DEV and Scrum. Similar studies, those of [10], [11]and Neil Potter and Mary Sakry [11], identified equivalences between CMMI and Scrum.
This paper focuses on the relationships between Scrum and the Project Management Process Areas of CMMI-DEV 1.3.The process areas of CMMI-DEV can be grouped into four categories: Project Management, Process Management, Engineering and Support. Scrum is mainly an agile methodology for project management. While there are some specific relationships between Scrum and other groups of process areas, the main relationships are with the Project Management group.
The article is structured as follows. An overview of related works is shown in section 1.Section 2 shows the relationships between Scrum and the Project Management process areas of CMMI-DEV 1.3. A discussion of this work is outlined in Section 3.Finally, we present the conclusions.

2.     Scrum and project management process areas

As we expressed before, Scrum is mainly a methodology for project management. Sutherland and Johnson [2] commented that the CMMI-DEV Level 2 process areas such as “Measurement and Analysis”, “Process and Product Quality Assurance” and “Configuration Management” are outside the scope of Scrum. Other authors such as [9], only identified relations between “project management”, “metrics” and “requirements” processes of CMMI-DEV, while [11] identified the relationships between Specific Practices (SP) of the “Project Planning (PP)”, “Requirements Management (REQM)” and “Project Monitoring and Control (PMC)” process areas of CMMI-DEV and Scrum practices.
Therefore, this research focuses on all Project Management process areas of CMMI-DEV 1.3. The process areas in CMMI-DEV 1.3 are as follows:

  • Integrated Project Management (IPM)
  • Project Monitoring and Control (PMC)
  • Project Planning (PP)
  • Quantitative Project Management (QPM)
  • Requirements Management (REQM)
  • Risk Management (RSKM)
  • Supplier Agreement Management (SAM)

The potential relationships between Specific Goals (SG) of Project Management process areas of CMMI-DEV 1.3 and Scrum practices are shown below. Table 1summarizes Scrum’s potential to satisfy SGs of CMMI. The first column contains SGs and process areas; the second contains Scrum potential satisfaction of the SGs.

Process area Satisfaction
Requirements Management (REQM)
  • SG 1 Manage Requirements

++

Project Planning (PP)
  • SG 1 Establish Estimates

++

  • SG 2 Develop a Project Plan

+

  • SG 3 Obtain Commitment to the Plan

++

Project Monitoring and Control (PMC)
  • SG 1 Monitor the Project Against the Plan

+

  • SG 2 Manage Corrective Action to Closure

++

Integrated Project Management (IPM)
  • SG 1 Use the Project’s Defined Process

  • SG 2 Coordinate and Collaborate with Relevant Stakeholders

++

Quantitative Project Management (QPM)
  • SG 1 Prepare for Quantitative Management

  • SG 2 Quantitatively Manage the Project

Risk Management (RSKM)
  • SG 1 Prepare for Risk Management

  • SG 2 Identify and Analyze Risks

  • SG 3 Mitigate Risks

Supplier Agreement Management (SAM)

 

  • SG 1 Establish Supplier Agreements

  • SG 2 Satisfy Supplier Agreements


Table 1. Scrum satisfaction of SG of process areas. + Partially addressed in Scrum; + + Largely addressed in Scrum; — Not addressed in Scrum
Scrum addresses “Requirements Management” through its use of user stories in the Product Backlog and Sprint Backlog. To understand the requirements, the Product Owner and Development Team review the Product Backlog. The Sprint Planning Meeting, Daily Scrum Meeting and Sprint Review are used to identify issues, inconsistencies and to make commitments. To manage the requirements effectively, elements such as change history or impact are recommended; Scrum addresses these. Since, according to the [12], the Product Backlog is the source of requirements for any changes to be made to the product; including all bug fixes that constitute changes to be made to the product in future releases. CMMI-DEV specifies verification and validation rather than explicitly saying software testing, but testing is not an explicit Scrum practices, although regression testing and continuous integration are an implicit part of agile implementations. These tests help to maintain the bidirectional traceability of requirements specified in CMMI-DEV and to ensure alignment between project work and requirements.
Scrum addresses “Project Planning” through its use of story points to estimate, the iterative / incremental life-cycle, ceremonies such as the various meetings, and Product and Sprint Backlogs. The Daily Scrum and Sprint Planning Meetings are used to review plans that affect the project, to understand project commitments and to reconcile the project plan to reflect available and estimated resources. However to plan a project effectively, elements such as risk, data management, and resources skills are recommended, and these are not explicitly covered by Scrum.
Scrum addresses “Project Monitoring and Control” through its use of Burndown Charts and meetings. The Burndown Charts track the effort remaining, and the completed story points. Sprint Review Meetings and Daily Scrum Meetings allow for the monitoring of the project and tracking actions. However, to monitor the project effectively, elements such as a full list of stakeholders or monitoring the Risks and Data Management are recommended and these are not explicitly covered by Scrum.
Scrum addresses part of “Integrated Project Management” through its use of roles and meetings. While Scrum does not help conduct a project using a defined process tailored from the organization’s standard processes, its roles and meetings support coordination and collaboration between the project and relevant stakeholders. Although there are only three roles in Scrum (the Product Owner, the Development Team and the Scrum Master), most projects end up needing many other roles.
Although Scrum is a software project management framework, it does not cover the process areas “Supplier Agreement Management” or “Risk Management”, which are typically out of the scope of agile practices.“Supplier Agreement Management” applies only to organizations that do subcontracting. “Quantitative Project Management” which applies statistical thinking to develop a quantitative understanding of the expected performance of processes, is also not covered.
Potential relationships between Specific Goals (SG) and Specific Practices (SP) of project management process areas of CMMI-DEV 1.3 and Scrum are shown in Table 2.

Process area Satisfaction
Requirements Management (REQM)

 

  • SG 1 Manage Requirements

+

  • SP 1.1 Understand Requirements

++

  • SP 1.2 Obtain Commitment to Requirements

++

  • SP 1.3 Manage Requirements Changes

++

  • SP 1.4 Maintain Bidirectional Traceability of Requirements

+

  • SP 1.5 Ensure Alignment Between Project Work and Requirements

+

Project Planning (PP)
  • SG 1 Establish Estimates

++

  • SP 1.1 Estimate the Scope of the Project

++

  • SP 1.2 Establish Estimates of Work Product and Task Attributes

++

  • SP 1.3 Define Project Lifecycle Phases

++

  • SP 1.4 Estimate Effort and Cost

++

  • SG 2 Develop a Project Plan

+

  • SP 2.1 Establish the Budget and Schedule

++

  • SP 2.2 Identify Project Risks

  • SP 2.3 Plan Data Management

  • SP 2.4 Plan the Project’s Resources

++

  • SP 2.5 Plan Needed Knowledge and Skills

  • SP 2.6 Plan Stakeholder Involvement

++

  • SP 2.7 Establish the Project Plan

+

  • SG 3 Obtain Commitment to the Plan

++

  • SP 3.1 Review Plans That Affect the Project

++

  • SP 3.2 Reconcile Work and Resource Levels

++

  • SP 3.3 Obtain Plan Commitment

++

Project Monitoring and Control (PMC)
  • SG 1 Monitor the Project Against the Plan

+

  • SP 1.1 Monitor Project Planning Parameters

++

  • SP 1.2 Monitor Commitments

++

  • SP 1.3 Monitor Project Risks

  • SP 1.4 Monitor Data Management

  • SP 1.5 Monitor Stakeholder Involvement

+

  • SP 1.6 Conduct Progress Reviews

++

  • SP 1.7 Conduct Milestone Reviews

+

  • SG 2 Manage Corrective Action to Closure

++

  • SP 2.1 Analyze Issues

++

  • SP 2.2 Take Corrective Action

++

  • SP 2.3 Manage Corrective Actions

++

Integrated Project Management (IPM)
  • SG 1 Use the Project’s Defined Process

  • SG 2 Coordinate and Collaborate with Relevant Stakeholders

+

  • SP 2.1 Manage Stakeholder Involvement

++

  • SP 2.2 Manage Dependencies

+

  • SP 2.3 Resolve Coordination Issues

+

Quantitative Project Management (QPM)
  • SG 1 Prepare for Quantitative Management

  • SG 2 Quantitatively Manage the Project

Risk Management (RSKM)
  • SG 1 Prepare for Risk Management

  • SG 2 Identify and Analyze Risks

  • SG 3 Mitigate Risks

Supplier Agreement Management (SAM)

 

  • SG 1 Establish Supplier Agreements

  • SG 2 Satisfy Supplier Agreements


Table 2. Scrum Satisfaction of SGs of Process Areas. (+ Partially addressed in Scrum; + + Largely addressed in Scrum; — Not addressed in Scrum)

3.  Discussion

In this section we will highlight some relevant aspects of the relationships between Scrum and Project Management process areas of CMMI-DEV 1.3.
The lack of paper evidence
Some Scrum practices do not leave a paper trail that can retrospectively demonstrate the implementation of some of the SGs of CMMI. For example, using a blackboard on which tasks or user stories are captured on post-it notes is evidence of planning and tracking progress, but this kind of evidence may not be easy to demonstrate in a formal CMMI-DEV appraisal process since it is transient. Some software companies may need to add other artifacts in order to be appraised. Often these could be considered “artificial evidence”, and the team can spend a lot of time collecting it. This is the main criticism of Scrum teams. As [11] observed, “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”.
Scrum and risk management
According to the glossary of CMMI [4], “project planning includes estimating the attributes of work products and tasks, determining the resources needed, negotiating commitments, producing a schedule, and identifying and analyzing project risks.” Most of these tasks are covered by Scrum, with the exception of the risk topics.
The stakeholders and the Product Owner
According to the glossary of CMMI-DEV 1.3[4], a stakeholder is “a group or individual that is affected by or is in some way accountable for the outcome of an undertaking. Stakeholders may include project or work group members, suppliers, customers, end users, and others.”Whereas, according to the Scrum Guide 2011, in a Scrum project the “Product Owner is responsible for maximizing the value the product and the work of the Development Team; how this is done may vary widely across organizations. The Product Owner is one person, not a committee, however the Product Owner may represent the desires of a committee”. Scrum addresses the CMMI stakeholders through its Product Owner, however it is important to note that in CMMI a stakeholder can be a group, and in Scrum the Product Owner is one person. For this, the Product Owner must compile and represent the needs of the different people involved in the project.

4.     Conclusions

Scrum practices should be considered best practices for project management, by the majority of organizations. Scrum can be an excellent support to project management practices of CMMI-DEV, even if Scrum practices do not completely address all of them, and topics such as “risk management” must be complemented with other methodologies beyond Scrum. The potential ability of CMMI-DEV and Scrum when merged together successfully can create synergy. Scrum’s practices can be fundamental for organizations implanting the CMMI-DEV, and we can thus consider CMMI-DEV and Scrum complementary.
In this paper the relationships between Scrum and the Project Management process areas of CMMI-DEV 1.3 have been presented. This allowed us to view the synergies among them. The main finding from the study that was carried out is that Scrum addresses “Requirements Management”, “Project Planning”, “Project Monitoring and Control”, “Integrated Project Management” considerably through its use of backlogs, roles and meetings. On the other hand, Scrum does not cover process areas like “Supplier Agreement Management”, “Quantitative Project Management” or “Risk Management”; typically, these are out of scope of the agile practices.

References

[1] R. D. Austin, «CMM Versus Agile: Methodology Wars in Software Development» Harvard Business School Press, 2007.
[2] J. Sutherland and K. Johnson, «Using Scrum to avoid bad CMMI-DEV® implementation», 2010;http://aplndc.com/eventSlides/JeffSutherlandCMMI-DEV.pdf.
[3] K. Beck, «Extreme Programming Explained: Embrace Change», Addison-Wesley Professional, 1999.
[4] M. B. Chrissis, M. Konrad and S. Shrum, «CMMI for Development®: Guidelines for Process Integration and Product Improvement», 3rd ed., SEI Series in Software Engineering, Addison-Wesley Professional, 2011.
[5] H. Glazer, D. Anderson, D. J. Anderson, M. Konrad and S. Shrum, «CMMI ® or Agile : Why Not Embrace Both!» ,2008, pp. 48;http://www.sei.cmu.edu/library/abstracts/reports/08tn003.cfm.
[6] M. C. Paulk, «Extreme Programming from a CMM Perspective», IEEE Software, vol. 18, no. 6, 2001, pp. 19-26.
[7] J. Sutherland, R. Jakobsen and K. Johnson,» Scrum and CMMI Level 5: The Magic Potion for Code Warriors», Hawaii International Conference on System Sciences, Proceedings of the 41st Annual, 2008;http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4293608.
[8] C. R. Jakobsen and K. A. Johnson, «Mature Agile with a Twist of CMMI», Proceedings of the Agile 2008, 2008;http://portal.acm.org/citation.cfm?id=1443221.1443497.
[9] A. S. C. Marcal, F. S. Furtado Soares and A. D.Belchior, «Mapping CMMI Project Management Process Areas to Scrum Practices», Proceedings of the 31st IEEE Software Engineering Workshop, 2007;http://dx.doi.org/10.1109/SEW.2007.64.
[10] C. R. Jakobsen and J. Sutherland, «Scrum and CMMI Going from Good to Great», Proceedings of the 2009 Agile Conference, 2009;http://dx.doi.org/10.1109/AGILE.2009.31.
[11] N. Potter and M. Sakry, «Implementing Scrum (Agile) and CMMI® Together», 2011;http://www.agilejournal.com/articles/columns/column-articles/5794-implementing-scrum-agile-and-cmmi-together.
[12] K. Schwaber and J. Sutherland, «Scrum Guide», 2011;http://www.scrum.org/storage/scrumguides/Scrum%20Guide%20-%20ES.pdf#view=fit.

Javier Garzás

2 comentarios en “Can Scrum help to improve the project management process? A study of the relationships between Scrum and Project Management process areas of CMMI-DEV 1.3.”

  1. Zurisadai Benjamin

    Excelente post, gran panorama que da de la relación. Ya vi algunas de las referencias que das y nos puede ayudar mucho a ser una mejora cuantitativa ya que somos una empresa nivel 5 y no implementamos SCRUM como debe de ser, si lo hacemos ya sabemos qué líneas base nos puede ayudar a mejorar.
    Gracias.

  2. Juan J. Olmedilla

    Good point, I would add some remark: I don’t agree with the criticism by some (not by the authors as they only collect this widespread concern) about the impossibility of leaving a paper trail of planning and tracking progress. It is true that many organizations use white or blackboards and post-it notes to do this tracking, however it is everyday more and more common to use tools such as JIRA and Greenhopper to do this, so that it is everyday easier to produce evidence for an eventual CMMi appraisal without this being «artificial».
    I am currently working in such an environment and we do use these tools for the value they add, and nobody is thinking about going through any kind of appraisal.
    Thanks for the post, Javier.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Ir arriba