A little about CMMI and its overheads

The Software World is going agile by embracing practices and styles that best suit their business vision and achieve a market edge by keeping customer satisfaction at an all-time high. The practice areas include: CMMI and Agile (Scrum).

The Capability Maturity Model Integration (CMMI), is a well-structured approach in the software development stage. It provides a framework that guides users on what process areas to follow. These process areas outline all stages in the Systems Development Life Cycle (SDLC). Companies that practice CMMI consistently generate higher product quality and customer satisfaction, because it provides better ways to manage a project’s data and documentation. However, it demands considering additional resources, such as: documentation, a substantial amount of effort, higher costs, and extra time.

Avoiding CMMI overheads

The limitations in CMMI are covered by using the Scrum approach from the Agile Manifesto, this educates users on what-to-do.

In Agile, we focus more attention to the things on the left rather than on the right:

(Ref. http://www.agilemanifesto.org/)

Individuals and interactions over processes and tools
working software over comprehensive documentation
Customer collaboration over contract negotiation
responding to change over following a plan

Producing a higher quality product that responds to requirement changes in any stage of development, is the most valuable approach in this scenario. Scrum believes in delivering frequent business values that serve as a working software, while also increasing customer satisfaction as the software continues to grow. Scrum welcomes changes at any time and accommodates them with no foreseeable costs. It believes in face-face communication rather than relying on the artificial means like, tools and other techniques. CMMI and Scrum can be easily merged because they facilitate each other by fulfilling one another’s voids.

CMMI & Scrum Altogether

Below is a brief mapping area that describes the process areas of CMMI engaging Scrum methodologies:

CMMI Maturity Level 2 and Scrum systematically work together to provide an easy mapping process. They complement each other by describing what-to-do and how to do it. (Ref. http://cmmi.de/cmmi/reqmsg-1-manage-requirements)

ReqM – CMMI Scrum
SP 1.1 Develop an understanding with the requirements providers on the meaning of the requirements.
  • Develop a Product Backlog consisting of all the product requirements
  • Review of the Product Backlog
SP 1.2 Obtain commitment to the requirements from the project participants.
  • Prioritize items in the Product Backlog
  • Obtain commitment of the entire team on Sprint Planning
SP 1.3 Manage changes to the requirements as they evolve during the project.
  • New or changed requirements are made part of the Product Backlog and prioritized accordingly for next Sprints
SP 1.4 Maintain Bidirectional Traceability of Requirements
  • Traceability in Scrum is maintained using Sprints.
SP 1.5 Ensure that project plans and work products remain aligned with requirements
  • Daily Scrum Meetings are conducted to identify the gaps between planned work and actual work performed. These meetings also cater any impediments faced by the team members
  • Product Burndown charts are developed in order to track the project’s health and status focusing on the remaining effort required

                                                   

How Project Planning in CMMI is mapped with Scrum

The mapping is elaborated in the table below:

(Ref. http://cmmi.de/cmmi/project-planning-pp-cmmi-dev)

Project Planning – CMMI Scrum
SP 1.1 Establish a top-level work breakdown structure (WBS) to estimate the scope of the project. The project related tasks are documented in the Product Backlog classified into manageable 2-3 week long work-products called sprints.
SP 1.2 Establish and maintain estimates of the attributes of the work products and tasks. Story Points are developed to estimate the effort required to accomplish a particular user story or requirement.
SP 1.3 Define the project life-cycle phases upon which to scope the planning effort. The Scrum process comprises of a sustainable approach of managing the work related tasks in potentially shippable working software chunks.
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. Sprint Backlog, Scrum estimates (in Ideal Time) and Project Task board fulfill the requirement in Scrum.
SP 2.2 Identify project risks Project risks are identified, managed and mitigated in Sprint Review meetings and Retrospectives.
SP 2.3 Plan for the management of project data Data is managed Sprint-wise in Scrum.
SP 2.4 Plan for necessary resources to perform the project. Sprint Backlog, Scrum estimates (in Ideal Time) and Project Task board fulfill the requirement in Scrum.
SP 2.5 Plan Needed resources and Skills Scrum team, Scrum Master and Product Owner are nominated for the project keeping in view the required skills and knowledge.
SP 2.6 Plan the involvement of identified stakeholders. Scrum process roles (including team, Scrum Master, Product Owner).

[Note: The stakeholders are not just limited to the Scrum team. They may also include client liaisons, customer representatives etc.]

SP 3.1 Review all plans that affect the project to understand project commitments. The Scrum team is dedicated to a specific sprint for a shorter period of time e.g. 2-3 weeks to avoid any dependencies. The self-organizing teams observe their team behavior and adjust their work accordingly to deliver the best on time.
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 The entire Scrum team works to develop a Product Backlog having all the requirements in it. Scrum also welcomes changes in the requirements at any stage of the development life-cycle.

 

Configuration Management is another process area in CMMI Maturity Level 2, but it is not specifically addressed by Scrum. This does not reflect on the bond CMMI and Scrum are capable of. Measurement and Analysis in Scrum is implemented by using Burndown Charts that reflect the remaining efforts required to get the work done. These charts can effectively track the overall progress of any project, and can tell you if a project is on-time and on-budget.

For Project Monitoring and Control in CMMI, we have Burndown data and Release data in Scrum. Daily Scrum meetings are conducted to determine where Sprint and Release Burndown data are collected, reviewed, and analyzed for the project’s health. The Process and Product Quality Assurance in CMMI is an important task that is repeatedly performed by the Scrum Master. The Scrum Master carefully observes team members to ensure they are following the Scrum Process and if needed makes changes accordingly.

Conclusion

CMMI is an group consisting of the best practices from the experiences of market leaders in the software industry. It provides information on where to go and exactly what to achieve, and it can easily improve an organization’s culture. Scrum is the best coach in providing solutions and reaching goals recommended by CMMI’s best practices. CMMI and Scrum complement each other by carrying out the entire effort effectively. They work as a combination of discipline and professionalism, and they respectively add remarkable business value to organizations.

References