4 Theory
4.3 CMMI and Agile Together
4.3.2 CMMI Practice Areas and Agile Ways of Working
There can be many activities in agile ceremonies followed by an organization. These ac-tivities can include planning, estimation, monitoring and control, review, demo and retro-spection. The most common activities in agile ceremonies are Backlog Grooming, Contin-uous Integration, Daily Scrum, Definition of Done, Epics/User Stories, Team Estimation, Pair Programming, Product Backlog, Refactoring, Release/Sprint Burn-down chart, Re-lease/Sprint Planning, Sprint Demo/Review etc. It is possible that if CMMI model is used for agile ceremonies then it will help them to improve. In this regard, it becomes important
48
to understand that what CMMI practice areas or practices are useful for specific agile ac-tivity. This can be explained with the following pictures and tables. (CMMI Institute, 2018b)
Backlog Grooming:
This is a common agile technique used by development team to produce a prioritized backlog of epics and user stories before and during sprints. This activity can benefit from a wide variety of CMMI practices such as Requirements Development and Management (RDM) and Project Planning (PLAN) as picturized below.
Figure 15. CMMI Practice Areas for Backlog Grooming (source: CMMI Institute, 2018b)
The most common CMMI practices followed for RDM can be defining requirements, con-verting customers and stakeholders needs into requirements, establishing product re-quirements, identifying interface rere-quirements, establishing operational concepts and sce-narios, establishing definition of required functionality and quality, analysing requirements, understanding requirements, validating requirements, obtaining management commit-ments to requirecommit-ments, managing changes to requirecommit-ments, maintaining bi-directional traceability, and ensuring alignment between project work and requirements.
CMMI practices for PLAN can be estimating scope for the project, establishing estimates for work product and task attributes, estimating effort and cost, controlling work products, and identifying and involving Relevant Stakeholders.
Continuous Integration:
This is an approach to continuous testing and product integration during software devel-opment. This activity can benefit from CMMI practice areas Verification and Validation (VV), Technical Solution (TS), Product Integration (PI), and Configuration Management (CM) as picturized below.
49
Figure 16. CMMI Practice Area for Continuous Integration (source: CMMI Institute, 2018b)
CMMI practices followed by VV can be establishing a validation or verification environ-ment, establishing validation or verification procedures or criteria, performing validation or verification, and analysing validation or verification results.
CMMI practices followed by PI can be establishing an integration strategy, establishing environment for product integration, confirming readiness to do product integration, re-viewing interface descriptions for completeness, and evaluating assembled components.
TS can follow practices of integrating solutions and collecting process related experiences for future improvements
CMMI practices followed by CM can be developing plan for environment, establishing cri-teria for environment and setting up the environment.
Daily Scrum:
This approach is used to monitor and control of progress of the project continuously, iden-tify issues and risks quickly and regularly, and increase collaboration between team mem-bers. It can demonstrate practices e.g. Monitoring and Control (MC), Risk and Opportunity Management (RSK), Managing Performance and Management (MPM), and Process Management (PCM).
Figure 17. CMMI Practice Areas for Daily Scrum (source: CMMI Institute, 2018b)
50
The practice area RSK can follow practices of identifying, evaluating risks, categorizing, prioritizing risks and opportunities. Later plans can be made to mitigate risks or harness opportunities.
The practice area MC can follow practices of monitoring project planning parameters, monitoring commitments, monitoring project risks, conducting progress reviews, and con-ducting milestones reviews.
The practice area PCM can follow practices of managing the project using integrated plans, managing stakeholder’s involvement and managing dependencies of the project.
MPM can follow practices of specifying measures, obtaining measurement data, analysing measurement data and communicating results.
Definition of Done (DoD):
This is an agreement within team that indicates what should be completed for the product to be ready for sprint review or demo. It must be done at user story level and agreed with-in team and properly defwith-ined withwith-in each story. DoD can follow practices of Project Plan-ning (PLAN), Process Assets Development (PAD), Verification and Validation (VV) and Product Integration (PI).
Figure 18. CMMI Practice Areas for Definition of Done (source: (CMMI Institute, 2018b)
PLAN practice area can follow practices of estimating the cope of project and establishing estimates of work products and task attributes. VV practice are can follow practices of performing verification and validation. PI can follow practices of determining integration sequence, establishing product integration environment and establishing product integra-tion procedures and criteria. PAD can follow practices of establishing standard process,
51
establishing tailoring criteria and guidelines, establishing organization’s process assets library and establishing work environment standards.
Sprint Planning/Release Planning:
The purpose of release planning and sprint planning is planning for release life cycle and sprint. Release planning is done for delivering an increment of product value. But during release planning the team does not plan for each detailed activity. While Sprint planning is done by the team to agree on the tasks performed during a sprint and is a negotiation between the team and product owner as to what value will be delivered in each sprint.
Sprint planning is an iterative and incremental form of planning as well as of the product backlog. These activities follow practice areas Requirements Definition and Management (RDM), Project Planning (PLAN), Estimation (EST) and Process Management (PCM) as picturised below.
Figure 19. CMMI PAs for Sprint/Release Planning (source: (CMMI Institute, 2018b)
PLAN practice area follows practices of estimating the scope of the project, establishing estimates of work products and tasks attributes, defining project lifecycle phases, estimat-ing effort and cost, establishestimat-ing the budget and schedule, identifyestimat-ing project risks, plan-ning stakeholder’s involvements, establishing the project plan, and obtaiplan-ning plan com-mitment from management.
RDM follows practices of obtaining commitments to requirements, managing changes to requirements, and maintaining bidirectional traceability of requirements
PCM follows practice of establishing the project’s defined process. EST follows Story and Task estimation in terms of time and resources.
Product Backlog:
52
This is a prioritized list of items such as features, bugs, documentation changes, and simi-lar things that can be included in the product. The well-defined product backlog ensures that the product owner understands the requirements of the product and is committed to accomplish it. These artefacts of agile ceremony depend on following practice areas such as Requirements Definition and Management (RDM), Project Planning (PLAN), and Pro-cess Management (PCM) as picturised below.
Figure 20. CMMI PAs for Product Backlog (source: (CMMI Institute, 2018b)
The practice area PLAN follows the practice of establishing the project plan. RDM follows the practices of understanding requirements, obtaining management commitments to re-quirements and managing changes to rere-quirements. PCM follows the practice of integrat-ing development plans.
Sprint Demo/Review:
This is an iterative and incremental collaborative activity to ensure that all stakeholders become aware of the value being delivered at the end of each sprint by the team. This activity can be improved through the application of practices of practice areas Project Monitoring and Control (MC), Process Management (PCM), Requirements Development and Management (RDM) and Verification and Validation (VV) picturised as follows.
Figure 21. CMMI PAs for Sprint Demo/Review (source: (CMMI Institute, 2018b)
53
The practice area PCM follows practices of integrating process plans, managing the pro-cess using the integrated plans, managing stakeholder’s involvement and resolving coor-dination issues.
Another practice area RDM follows practices of obtaining management commitments to requirements, managing changes to requirements and maintaining bidirectional traceabil-ity of requirements
MC follows practices of monitoring commitments, monitoring stakeholder’s involvement, conducting progress review, conducting milestone reviews and managing corrective ac-tions.
VV follows practices of selecting products for verification and validation, identifying and involving relevant stakeholders, performing verification and validation and reviewing status with higher level management.
Epics/User Stories:
Epics are large user stories that is broken down into individual user stories. A user story is a simple description of discreet piece of functionality of the product. This is created as a result of using practices of practice areas Requirements Definition and Management (RDM), Process Management (PCM) and Verification and Validation (VV) picturised as follows.
Figure 22. CMMI PAs for User Stories/Epics (source: (CMMI Institute, 2018b)
The practice area RDM follows practices of defining needs, transforming stakeholder’s needs into customer requirements, understanding requirements, obtaining management commitment to requirements, managing changes to requirements and maintaining bidirec-tional traceability of requirements.
54
PCM follows practices of integrating development plans, managing the project using inte-grated plans, managing stakeholder’s involvement and resolving coordination issues.
VV follows practices of establishing verification procedure and criteria, establishing verifi-cation environment and performing verifiverifi-cation.
Sprint/Release Burn-Down Chart:
A burn-down chart is an information radiator that visually depicts the trajectory of each sprint or overall release. It is a mechanism to monitor the progress of project in a sprint or for a release. The team can effectively use burn-down chart by following practice areas Managing Performance and Measurement (MPM), Monitoring and Control (MC) and Pro-cess Management (PCM) picturised as follows.
Figure 23. CMMI PAs of Sprint/Release Burndown Chart (source: (CMMI Institute, 2018b)
PCM follows practices of establishing the project’s defined process and using organiza-tional process assets for planning project activities.
MPM can follow practices of specifying measures, obtaining measurement data, analysing measurement data and communicating results.
MC can follow practices of monitoring project planning parameters, monitoring manage-ment commitmanage-ments to project, monitoring stakeholder’s involvemanage-ment in the project and conducting progress reviews.
Pair Programming:
This is an activity in which two software developers work together to accomplish a coding task. This activity helps in improving quality, increasing efficiency and reducing cost of code production in long run. It can be accomplished by following practice areas Require-ments Development and Management (RDM), Technical Solutions (TS) and Verification and Validation (VV) picturised as follows.
55
Figure 24. CMMI PAs for Pair Programming (source: (CMMI Institute, 2018b)
TS can follow practices of implementing the design and collecting process related experi-ences for future improvements
RDM can follow practices of defining needs, transforming stakeholder’s needs into cus-tomer requirements, establishing product requirements, identifying interface requirements, establishing a definition of required functionality and quality attributes, analysing and vali-dating requirements.
VV can follow practices of selecting product for validation, planning the validation envi-ronment, planning the validation method, conducting validation of product, and analysing the validation results.
Refactoring:
Refactoring is a technique that focuses on improving the internal structure, style, opera-tions and condition of software code while maintaining its external functionality and behav-iour. This can be improved by the guidelines present in Requirements Definition and Man-agement (RDM), Process ManMan-agement (PCM), Technical Solutions (TS), Project Planning (PLAN) and Verification and Validation (VV) picturised as follows.
Figure 25. CMMI practice areas for Refactoring (source: (CMMI Institute, 2018b)
56
TS can follow the practice of implementing the design for code. PCM can follow the prac-tice of contributing to organizational process assets. RDM can follow pracprac-tices of defining requirements, transforming stakeholder’s needs into customer requirements, establishing product requirements, establishing a definition of required functionality and quality attrib-utes, analysing and validating requirements. PLAN can follow practices of monitoring pro-ject planning parameters, monitoring management commitments and conducting progress reviews. VV can follow practices of selecting refactored code for validation, planning the validation environment, planning the validation method, conducting validation and review-ing results with other stakeholders.