Coexistence of

®
Agile & CMMI
(The Balancing Act)

®Capability Maturity Model, Capability Maturity Modeling, CMM, and CMMI are registered in the U.S. Patent and Trademark Office by Carnegie
Mellon University. SMCMM Integration, IDEAL, and SCAMPI are service marks of Carnegie Mellon University.
 Agenda
1. Workshop Objective and Context Setting

2. Introduction to Agile Methodology

– Why and What is Agile?

– Agile Concepts, methods and Agile Practices

3. Introduction to CMMI Framework

– Overview to CMMI Dev model Framework ?

– CMMI Framework Concepts – Specific and Generic Goals, Practices

4. CMMI Dev and Agile – Myths and Realities
– Agile and CMMI philosophy and approaches
– Pros and Cons of CMMI framework and Agile Practices
– Complement or Contradict
– Documentation vs. No documentation
– Process and People
2
 Agenda
5. Integrating CMMI Dev Framework and Agile Methodology
– Organizational context and Project Scenarios
– Practical challenges in mapping Agile Practices to CMMI process areas
– Leveraging the best of both frameworks

6. CMMI and Agile Practices mapping (Level 2 and Level 3)

– CMMI Level 2 and Level 3 Process areas and Agile Practices

7. CMMI High Maturity (ML4 and ML5) Process Area Mapping

8. Conclusion

3
 Participant Introduction

• Name
• Organization / Department
• Total years of experience
• Years of experience and exposure to CMMI framework
and implementation
• Years of experience and exposure in Agile and related
methodologies
• Your expectations from the workshop

4
Logistics

5
 Course Approach

• Lecture
• Exercises
• Questions and answers
• Discussions
• Participation by all

6
 Rules of Engagement

Participate.

One person speaks at any given time.

Keep discussions and questions to the point.

Turn off your cell phones and other communication

devices.

Be prompt returning from breaks.

Provide feedback as to where course can be improved – it

will be useful for sub-sequent sessions

7
 Typical Organizational Scenarios

All Projects are Majority (say 80%) of

CMMI compliant , the projects are
now there is need CMMI compliant and
for some projects to 20% of the projects
transition to Agile are Agile
methods

Organizational
Context

All projects in
organization follow Significant part of
Agile practices
Integrating Agile(60% and
Projects
Processabove)
and Tools
in organization
follow Agile methods
others follow
traditional methods

8
 Workshop Objective

To provide clarity on

• What is CMMI Framework and Agile Methodology

• Can CMMI and Agile Co-exist

– Is it required?
– How can we leverage best of both frameworks?

• What are the business drivers for CMMI and Agile to

co-exist in Organizational and Project context
– If required how can we approach?

9
Introduction to Agile Methodology

Why and What is Agile?

Agile Concepts, methods and Agile

Practices
 Traditional Approach

Requirements
Gathered

Architecture
Designed

Coding
Completed

Testing

Sequential – series of steps

Product Completed after months, if not years

11
 Waterfall Insights

This is the place we least want to find any defects

Project Timeline
Start Finish

Start Analysis Design Code Test Finish

The design of waterfall means that we will always be at our most vulnerable just
when we least want to be and that defects will be found when they are the
most expensive to fix.

12
 The Shunt Effect

4 weeks 4 weeks 40 weeks 4 weeks

analysis design code test

Construction

4 weeks 5 weeks 42 weeks 1week

analysis design code test

As each phase of the project is delayed, the remaining phases get moved back
but the deadline remains the same, causing compression in the last stages.
Delays are often caused by individuals who are reticent to sign-off the preceding
stage.

13
 Some interesting facts..

Source: http://www.standishgroup.com/visitor/chaos.htm

14
 What customer really needs?

• Design documents?
• Plans?
• UML diagrams?
• New technology implementations?

Customer needs working software that improves his / her business!

15
It’s All About…

Change!

16
Agile Manifesto

17
 Twelve Agile Principles
Our highest priority is to satisfy the Working software is the primary
customer through early and continuous measure of progress
delivery of valuable software

Welcome changing requirements, Agile process promote sustainable

even late in development. Agile development. The sponsors, users and
process harness change for the developers should be able to maintain a
customer’s competitive advantage constant pace indefinitely

Deliver working software frequently, from a Continuous attention to technical

couple of weeks to a couple of months, with a excellence and good design enhances
preference to the shorter time scale agility

Business people and developers Simplicity- the art of maximizing the

must work together daily amount of work done – is essential
throughout the project

Build projects around motivated The best architecture, requirements

individuals. Give them the environment and designs emerge from self
and the support that they need, and trust organizing teams
them to get the job done

The most efficient and effective At regular intervals, the team reflects
method of conveying information to how to become more effective, then
and within a development team is and adjusts its behavior
face-face conversation accordingly

18
Core Values of Agile

19
 Agile Methods

• Each of the Agile Methods although

unique in approach, share
– Common vision
– Core Values
– Incorporate Iteration & Continuous
feedback
– Continuous planning, testing,
integration and evolution
– Lightweight and adaptable
– Empower people to collaborate
and make decisions together
quickly and effectively

Agile software development methods offer potential for business benefits and process improvement
opportunities if adopted properly. But, it can cause significant disruption if one adopts it improperly.

20
Agile Practices

21
 SCRUM – How it works

Input from End-Users,

Customers, Team and
Other Stakeholders

Product
Scrum Master Daily Scrum
Backlog Meeting & Artifacts Update
Refinement

Team
Sprint
1-4 Weeks
Product Owner Review

Team Selects Potentially Shippable

How Much To
Product
Commit To Do
Increment
By Sprint’s End
Retrospective
Product
Sprint Planning Sprint No Changes
Backlog
Meeting Backlog in Duration or Goal

22
 In Summary Agile is Characterized by
Agile is….
An umbrella term for several iterative and incremental software development methodologies.
An approach where typically requirements & solutions evolve through collaboration of cross
functional teams.
Collection of many methods that focus at developing software projects in time boundaries,
referred as iterations.

Agile is NOT a standard….It’s a project management and engineering lifecycle methodology

(collection and sequence of practices) which must be carefully interpreted & selectively applied to
gain the true benefits!!

PEOPLE

Process Technology

23
Introduction to CMMI Framework

Overview to CMMI Dev model

Framework

CMMI Framework Concepts – Specific

and Generic Goals, Practices
 CMMI® Framework

• CMMI® models are a collection of best practices that help

an organization improve its processes.

• A reference model for process improvement and

assessments

• A Complete Suite, including:

– Formal Training Set
– Appraisal Methodology
– Detail Model Description

25
 CMMI® for Development
• Process Improvement Maturity Model for development of
products and services

• Best Practices that address development and maintenance

activities covering product lifecycle from conception through
delivery and maintenance

• Integrates bodies of knowledge essential for development and

maintenance like software, systems, hardware & design, and
acquisition

• CMMI-DEV first such constellation representing development

area of interest

• It has 22 Process Areas

26
 Organizational Process Maturity

Process Maturity
• The extent to which a specific
process is explicitly defined,
managed, measured, controlled
and effective

As an organization matures, the process becomes better

defined and more consistently implemented in projects
throughout the organization
27
 Staged View of Process Areas : CMMI-DEV

Organizational Performance
5 Management Causal Analysis & Resolution
5

Organizational Process
4 Quantitative Project Management Performance
4

Requirements Development
Technical Solution Organizational Training
3 Product Integration
Integrated Project Management
Risk Management
Organizational Process Definition Decision Analysis & Resolution 3
Verification Organizational Process Focus
Validation

Project Monitoring and Control

Project Planning Configuration Management
2 Supplier Agreement Management Process & Product QA 2
Requirements Management Measurement & Analysis

Engineering Project Management Process Management Support

28
Process Areas in CMMI® - Design View

Source: SEI/CMU-2006-TR-008

29
 Required/Expected/Informative components

• Required components are Specific and Generic Goals

• Expected components are Specific and Generic Practices

• Informative components are Sub practices, Typical Work

Products, Amplifications, Generic Practice elaborations,
Goal and Practice titles, Goal and Practice notes and
references are examples of informative components

30
 Process Area, Specific and Generic Goals

• A Process Area (PA) is a cluster of related practices

• A set of practices need to be performed to satisfy goals of a
process area
• There are two kinds of goals in each PA
– Specific goals
• Address the unique characteristics that describe what must be
implemented to satisfy the purpose of the process area

– Generic goals
» Achievement of each of these goals in the process area
signifies whether the implementation and institutionalization of
the process area is effective, repeatable, and lasting
» These are common across all Process Areas
» They provide institutionalization features

31
 In Summary CMMI model is Characterized by

Underlying Premise of Process Improvement

“The quality of a product is largely People

determined by the quality of the
process that is used to develop and
maintain it.”

Model Characteristics -> Institutionalize PROCESS Technology

the Best Practices across the organization

• Say what you do

• Do what you say

• Analyze the Process performance

• Focus on Continuous Process Improvement

32
CMMI Dev and Agile – Myths and Realities

Agile and CMMI philosophy and approaches

Pros and Cons of CMMI framework and Agile

Methods

Complement or Contradict

Documentation vs. No documentation

Process and People

 Agile and CMMI
Primary goals
• CMMI: Predictability, Stability, high assurance
• Agile: Customer satisfaction, Speed

Scope
• CMMI: Broad, Inclusive and Organizational
• Agile: Small, Focused, Project

Improvement focus
• CMMI: Process
• Agile: People
Ultimate Motivation

Both want to develop high performance organizations

34
 Agile and CMMI
CMMI model provides guidance to use when developing process content
for an organization and serves as a guide for process improvement

CMMI does not advocate any specific methodology to be followed

CMMI and Agile can co-exist – perceived differences are often in

approach rather than in substance.

Agile emphasizes trust where as CMMI requires oversight

Bad Agile results in chaos or a hacker-driven environment while CMMI

when overdone results in paralysis – neither of them is good when
not followed in true spirits

When used judiciously, the two can complement each other, with CMMI
providing the “what” and Agile defining the “how”.
 Agile and CMMI Philosophy and approaches
CMMI
• CMMI primarily describes “what “
must be done, but leaves “how “ to
the organization themselves
• CMMI provides an infrastructure for
organization learning and systematic
improvement
• CMMI provides a path for effective
use of processes, measurement,
training, and improvement
• CMMI has an expanded people focus
at organizational level by establishing
an environment where individuals can
excel.
• Focus is on Top down approach
Agile
• Agile methods provide software
development how-to’s that are
missing in CMMI
• Scope of Agile is focused at project
level intensely practical and bias
towards action
• Agile emphasis on tacit knowledge
rather than explicit knowledge like
documentation
• can be high risk in many
environments like government
contracting etc.,
• Only predictable on micro versus
macro level
• Agile has a team and individual focus.
• Bottom up approach
36
 Agile and CMMI Philosophy and approaches
CMMI Agile
• CMMI embodies sound systems • Early adopters of agile methods
engineering and software engineering generally focused on smaller single
principles applicable in project team development projects with
contexts that agile approaches were volatile requirements in a software
not intended to address only environment
• Overall system capabilities to be
developed , including non • Agile methods have flourished in a
technical requirements domain of low cost of failure.
• Scope, schedule, cost and risk
Examples within this domain include
trade offs
• Product (or service) architecture internet commerce, social
• CMMI was developed in a domain of networking and games development
high cost of failure “if a plane
• The success of agile methodologies
crashes, the cost of failure is
depends on the emergent properties
extremely high”
of the set of practices as a whole
• Early CMMI adopters were
developers of large-scale, risk-
averse, mission critical systems with
high levels of management oversight
and hierarchical governance.
37
 Agile and CMMI Philosophy and approaches
CMMI
• Measure and Improve Process
• Better Process and Product
• People Characteristics
• Disciplined , follow rules, risk
averse
• Communication
• Organizational , Macro
• Knowledge management
• Process assets
CMMI Challenges
Scaling Down
- Doable, but difficult
Agile
• Customer response
• Minimal overhead
• Requirements Refinement
• Metaphor
• Business case
• People characteristics
• Comfortable, risk takers, innovative
• Communication
• Person to person , micro
• Knowledge management
• People
• An architectural description of the system
that provides a tour of the top-level design
can be invaluable for maintainers which is
sometimes not given enough focus in agile
Agile Challenges
Scaling Up
- Undefined
38
 Agile Ecosystem and Myths
• Perceive agility as meaning they don’t have to model and they don’t
have to write documentation

• Using Agile means that you can do what you like.

• Doing Agile means no Architecture or upfront Planning

• It's a silver bullet that will solve all your problems

• Agile approaches means avoiding commitments – price and schedule

• Agile is just an iterative and incremental process

• Agile does not work with CMMI

• Agile Development Methods Don’t scale

• Thinking Agile stops at engineering teams and

wont affect the rest of the organization

39
Integrating CMMI Dev Framework and
Agile Methodology

Patterns of Agile Implementations

Organizational context and Project

Scenarios

Practical challenges in mapping Agile

Practices to CMMI process areas

Leveraging the best of both frameworks

 Patterns of Agile Implementations

Technical
Practices First
or Iterative First

Start Small or All In

Public display of
Stealth Mode or Agility

41
Agile implementation Challenges - Organizational context
• To compete in IT market – exploring the option of building software on onsite and
offshore model has become a reality
• Providing IT services - Client mandating the team to follow Agile methods
• Faster development cycle - Delivery model that satisfies the developers and
executing teams
Organizational • Large Programs
• Varied commercial models of project execution
Project • Fixed Price
Landscape • Time and Material
• Process that advocates customer sense of belongingness
• Methodology that provides flexibility to address
• Trust and Team work
• Different Time zones
• Requirements misunderstanding

• A reality whether we want it or not, Difficult to have co-located teams

• Manage Communication

• Build trust and team bonding

Distributed • Cultural differences

development • Administrative differences like accounting, legal

• Agile Coach and Product owner operating from onsite

• Agile teams operating in onsite and offshore

42
Agile implementation Challenges - Organizational context

• The product owner

• Availability of business users to the execution teams
• The technical roles for agile projects
• Technical/Solution Architects role in Agile project
Customer • Test lead/test architect role in agile projects
Participation • Customer Involvement
• Participation in demos, Iteration planning and review etc
Stakeholder involvement • Planning
& planning • Time boxed planning
• Scope Planning in agile
• Velocity driven planning
• MOSCOW Prioritization

• Comparatively High Attrition

• Makes it difficult to have self organizing teams
• Requires more handovers or documentation

• Enormous amount of Freshers

Indian IT • Less design capabilities in a team which has large number of fresher's
• Fresher's may not have seen even one cycle of product and do not appreciate
Context some of the design constraints and issues
People related Issues • More handholding needed to build self organizing team

• Cultural
• Education system
• Asking Questions
• Colleges are yet to catch up on agile methodologies

43
 Agile Implementation Patterns and Challenges
• Partial adoption

• Dilution of agile principles

• Multiple interpretation

• Variants of agile practices

• No Formal training on methodology

• Just do it !! -> lack of awareness on the why part

The success of agile projects depends on the implementation

of complete components of practices as a whole

44
 How to address some of the limitations explicitly

Management • How do we set the expectation of

expectations management and relevant stakeholders
on the methodology

Different project & team • Do we have a method to address different

project and team scenarios
scenarios

• Can we have basic checks and balances

Predictable & consistent in the system to ensure predictability and
outcomes consistency

• How can we get an insight on how are we

Are Cycle times, performing and how much we have
Quality & Productivity improved in cycle time and productivity.
improving

• Can we plan knowledge management

Learning & Improving at systems to capture tacit knowledge and
Organization level learning’s that can be shared with wider
audience

45
 Agile Life Cycle Methodology Definition

Organizational
Best Practices

XP Practices

SCRUM Practices
Agile Lifecycle CMMI Practices
Model

Other Agile Practices

Industry Best Practices

Points to ponder during definition • Framework compliance

• Project types • Infrastructural needs
• Team location - Centralized or distributed • Measurements for continuous improvement at organizational
• Organizational objectives level

46
CMMI and Agile Practices mapping

CMMI Level 2 Process areas and Agile

Practices
Level - 2 Process Areas
(CMMI-DEV)
Optimizing

Quantitatively
Managed

Defined

Managed

Initial
© Software Engineering Institute
 Staged View of Process Areas : CMMI-DEV

Organizational Performance
5 Management Causal Analysis & Resolution
5

Organizational Process
4 Quantitative Project Management Performance
4

Requirements Development
Technical Solution Organizational Training
3 Product Integration
Integrated Project Management
Risk Management
Organizational Process Definition Decision Analysis & Resolution 3
Verification Organizational Process Focus
Validation

Project Monitoring and Control

Project Planning Configuration Management
2 Supplier Agreement Management Process & Product QA 2
Requirements Management Measurement & Analysis

Engineering Project Management Process Management Support

- 49 -
 Requirements - Management
Purpose:
The purpose of Requirements Management 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.

• Manage Requirements (SG1)

CMMI Version 1.3 elaboration about Requirements Management:

• In Agile environments, requirements are communicated and tracked through
mechanisms such as product backlogs, story cards, and screen mock-ups.
• Commitments to requirements are either made collectively by the team or an
empowered team leader.
• Work assignments are regularly (e.g., daily, weekly) adjusted based on progress
made and as an improved understanding of the requirements and solution emerge.
• Traceability and consistency across requirements and work products is addressed
through the mechanisms already mentioned as well as during start-of-iteration or
end-of-iteration activities such as “retrospectives” and “demo days”

Refer: “Interpreting CMMI When Using Agile Approaches” in Part I of CMMI DEV V1.3

- 50 -
 Mapping of Practices – CMMI and Agile (REQM)
CMMI
SP No. Practice Statement
Develop an understanding
with the requirements
SP 1.1
providers on the meaning of
the requirements.
Obtain commitment to the
SP 1.2 requirements from the project
participants.
Manage changes to the
SP 1.3 requirements as they evolve
during the project.
Maintain bidirectional
traceability among the
SP 1.4
requirements and the work
products.
Ensure that project plans and •
SP 1.5 work products remain aligned
with requirements
Agile
Practices Artefacts
• Capturing requirements through User Stories during
story writing workshops along with the
customer/customer team/product owner • Product backlog / User stories /
• Review of the same during iteration planning / Storyboards
backlog refinement meeting with the
customer/Product owner
• Commitments given by the agile team to complete
set of epics/product backlog items/user stories during
release planning and iteration planning • Release backlog, Sprint backlog
• Commitments given by the agile team on the and clearly defined DOD
definition of done at Release planning and iteration
planning meeting
• Refinement done to the product backlog by the
• Updated product backlog (which
product owner during backlog refinement meeting,
showcases the changes in
iteration planning and iteration review
requirements or changes in
• Adding Requirements Changes/ Changes to the
priorities, changes in estimates)
priorities to Product Backlog
• Traceability from Epics to user
• Traceability is maintained from Epics - User stories - stories to tasks shown in either an
Tasks and Epics - User stories - Acceptance tests Agile Tool (like Scrum works) or
maintained in an excel
Alignment in release plans and refinement to project • Alignment to release plans (de-
backlog items to be discussed as a part of next scoping, re-prioritization, re-
iteration planning meetings estimation etc)
- 51 -
 Project Planning
Purpose:

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

• Establish Estimates (SG1)

• Develop a Project Plan (SG2)

• Obtain Commitment to the Plan (SG3)

- 52 -
 Project Planning

CMMI Version 1.3 elaboration about Project Planning:

• In Agile environments, performing incremental development involves planning,
monitoring, controlling, and re-planning more frequently than in more traditional
development environments. While a high-level plan for the overall project or work effort
is typically established, teams will estimate, plan, and carry out the actual work an
increment or iteration at a time.
• Teams typically do not forecast beyond what is known about the project or iteration,
except for anticipating risks, major events, and large-scale influences and constraints.
Estimates reflect iteration and team specific factors that influence the time, effort,
resources, and risks to accomplish the iteration.
• Teams plan, monitor, and adjust plans during each iteration as often as it takes (e.g.,
daily). Commitments to plans are demonstrated when tasks are assigned and accepted
during iteration planning, user stories are elaborated or estimated, and iterations are
populated with tasks from a maintained backlog of work.

Refer: “Interpreting CMMI When Using Agile Approaches” in Part I of CMMI DEV V1.3

- 53 -
 Mapping of Practices – CMMI and Agile (PP)

CMMI Agile
SP
Practice Statement Practices Artefacts
No.
• Establishing the overall release scope, next
Establish a top-level work breakdown release’s scope through selected epics and • Product backlog for
SP
structure (WBS) to estimate the scope of product backlog based on business priorities and release and tasks
1.1
the project technical estimates. identified for the sprint
• Sprint backlog (tasks) is next level of WBS

SP Establish and maintain estimates of the • Story point estimation or ideal days estimation done • Product backlog with story
1.2 attributes of the work products and tasks for epics / user stories points or Ideal days

SP Define the project life-cycle phases upon • Definition of agile lifecycle with well defined phases • Project lifecycle method in
1.3 which to scope the planning effort (e.g. SCRUM Process and its extensions) QMS

• Story Points approach to estimate the difficulty of a

Estimate the project effort and cost for the
SP Story (requirement). Computing velocity for an • Velocity & no. of iterations
work products and tasks based on
1.4 iteration using story points. Then deriving the no. of calculation
estimation rationale
iterations necessary for a release.
• Alignment to release
Ensure that project plans and work • Discussion in iteration plan meeting based on
SP plans (de-scoping, re-
products remain aligned with refinement to Product backlog items and
1.5 prioritization, re-
requirements alignment in release plans
estimation etc)

- 54 -
 Mapping of Practices – CMMI and Agile (PP)
CMMI Agile
SP
Practice Statement Practices Artefacts
No.
SP
Establish the Budget and Schedule
2.1 • Release and Sprint planning sessions
• Task breakdown and task identification by team
SP during sprint planning
Identify Project Risks
2.2 • Daily planning meeting for reviewing and re planning • Estimates (Story points
SP tasks and project activities Ideal Time).
Plan Data Management • Estimates of what work
2.3
• A release plan to be maintained to establish the will be in each release.
SP major milestones of the project. • Release Plan, Sprint
Plan the Project’s Resources • Apart from this concept like "Sprint 0" to be defined Backlog and
2.4
prior to every release to capture dependencies, assignments(task board.)
SP assumptions, constraints, risks, resources and • Agile project Plan and
Plan Needed Knowledge and Skills
2.5 stakeholders. Knowledge and skills training Release Plan
SP required pertaining to that release.
Plan Stakeholder Involvement
2.6
SP • Establish and maintain an Agile project plan for
Establish the Project Plan
2.7 every release
• Scrum team roles, Product owner, Scrum Master
SP and team members
Review all plans that affect the project to
3.1 • Review of release plan and Agile project plan with
understand project commitments.
agile team and relevant stakeholders (external to
team) • Logs of Release , Sprint
SP planning and daily Scrum
Reconcile the project plan to reflect • Based on Sprint 0 review - inspect and adapt the sessions
3.2
available and estimated resources. Agile Project Plan and Release Plan

Obtain commitment from relevant

SP • Review of release plan with relevant stakeholders
stakeholders responsible for performing
3.3
and supporting plan execution.

- 55 -
 Project Monitoring and Control
Purpose:
• The purpose of Project Monitoring and Control 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.

• Monitor Project Against Plan(SG1)

• Manage Corrective Action to Closure (SG2)

CMMI Version 1.3 elaboration about Project Monitoring Control:

• In Agile environments, the sustained involvement of customer and potential end
users in the project’s product development activities can be crucial to project
success; thus, customer and end-user involvement in project activities should be
monitored.

Refer: “Interpreting CMMI When Using Agile Approaches” in Part I of CMMI DEV V1.3

- 56 -
 Mapping of Practices – CMMI and Agile (PMC)
CMMI Agile
SP.
Practice Statement Practices Artefacts
No.
• Visual chart/Project Task Board used to track
stories (requirements) that are done, in progress, • Iteration / release burndown
or ones that need to complete DOD criteria. chart
SP 1.1 Monitor Project Planning Parameters • Sprint burndown chart that tracks effort remaining. • Agile project management tool
• Release burndown chart that tracks completed (Rally, Version one, Scrum
story points. This shows how much of the product works etc.,) for task tracking
functionality is left to complete.
• Daily Standup meeting. • Daily stand-up logs and
SP 1.2 Monitor Commitments
• Sprint review meeting iteration review log
• Risks identified during Sprint 0 & new risks
monitored during the iteration planning (to check • Updated risk log or maintain a
SP 1.3 Monitor Project Risks
the occurrence of the risk during iteration) during risk burndown chart
daily stand-up & iteration review.
• Updated project task board, Sprint burndown,
SP 1.4 Monitor Data Management • Daily stand up log
release burndown
• Discussions at the: Daily Scrum meeting and
SP 1.5 Monitor Stakeholder Involvement
Sprint review meeting.
• Updating Release burndown chart, Sprint burn Logs of
SP 1.6 Conduct Progress Reviews • Daily Scrum meeting.
down chart and Impediments
• Sprint Review meeting.
SP 1.7 Conduct Milestone Reviews • Sprint review and release review • Retrospectives.
• Analyzing issues (impediments) from daily Scrum
SP 2.1 Analyze Issues
meeting and demo during Sprint review
• Actions taken on the issues /impediments by the
SP 2.2 Take Corrective Action
Scrum Master and team • Issues log
Tracking of actions from:
SP 2.3 Manage Corrective Actions • Daily Scrum meeting.
• Sprint review meeting

- 57 -
 Supplier Agreement Management
Purpose:
• The purpose of Supplier Agreement Management (SAM) is to manage the
acquisition of products and services from suppliers.

• Establish Supplier Agreements(SG1)

• Satisfy Supplier Agreements(SG2)

- 58 -
 Mapping of Practices – CMMI and Agile (SAM)

CMMI Agile
SP.
Practice Statement Practices Artefacts
No.

Determine the type of acquisition for each

SP 1.1
product or product component to be acquired

Select suppliers based on an evaluation of their

SP 1.2 ability to meet the specified requirements and
established criteria.

• This process area should be implemented as it is defined in CMMI.

SP 1.3 Establish and maintain supplier agreements. However, while establishing supplier agreements the Agile way of
working should be described and agreed upon with the supplier
Perform activities with the supplier as specified
SP 2.1
in the supplier agreement

Ensure that the supplier agreement is satisfied

SP 2.2
before accepting the acquired product

Ensure the transition of products acquired from

SP 2.3 the supplier.

- 59 -
 Measurement Analysis
Purpose:
The purpose of Measurement and Analysis is to develop and sustain a measurement
capability that is used to support management information needs.

• Align Measurement and Analysis Activities(SG1)

• Provide Measurement Results (SG2)

- 60 -
 Mapping of Practices – CMMI and Agile (MA)
CMMI
SP.
Practice Statement
No.
Establish and maintain measurement •
objectives that are derived from
SP 1.1
identified information needs and
objectives.
Specify measures to address the
SP 1.2
measurement objectives.
Specify how measurement data will
SP 1.3
be obtained and stored.
Specify how measurement data will
SP 1.4
be analyzed and reported.
SP 2.1 Obtain specified measurement data.
Analyze and interpret measurement
SP 2.2
data.
Manage and store measurement
SP 2.3 data, measurement specifications,
and analysis results.
Report results of measurement and
SP 2.4 analysis activities to all relevant
stakeholders.
Agile
Practices Artefacts
Apart from Sprint burndown and • Sprint burndown chart that tracks effort
release burndown mandatory remaining.
measurements, the MA objectives can • Release burndown chart that tracks
be identified based on Acceptance completed story points. This shows how
Criteria and Definition of Done for the much of the product functionality is left to
release and iteration as agreed with complete.
the customer and the team. • Agile project management tool
• Measure of Acceptance criteria
(example: 0 Major defects, % of
coverage, cyclomatic
complexity)
• Other project related measures
could be (No. of user stories
done against committed,
seamless build or % of build
breaks, velocity etc).
• Slippage of Release & Sprint - is • Sprint burndown
tracked using Release Burndown, • Release burndown
Sprint burndown charts • Base and derived measurement data
• Daily Scrum meeting where Sprint and sets
Release burndown charts are • Analysis results and draft reports
reviewed.
• Sprint Retrospectives can be
used for analysing metrics captured
during the sprint
- 61 -
 Process and Product Quality Assurance
Purpose:
• The purpose of Process and Product Quality Assurance (PPQA) is to provide staff
and management with objective insight into processes and associated work
products.
.
• Objectively Evaluate Processes and Work Products(SG1)

• Provide Objective Insight (SG2)

CMMI Version 1.3 elaboration about Process and Product Quality Assurance:
• In Agile environments, teams tend to focus on immediate needs of the iteration
rather than on longer term and broader organizational needs. To ensure that
objective evaluations are perceived to have value and are efficient, discuss the
following early: (1) how objective evaluations are to be done, (2) which processes
and work products will be evaluated, (3) how results of evaluations will be
integrated into the team’s rhythms (e.g., as part of daily meetings, checklists, peer
reviews, tools, continuous integration, retrospectives).
Refer: “Interpreting CMMI When Using Agile Approaches” in Part I of CMMI DEV V1.3

- 62 -
 Mapping of Practices – CMMI and Agile (PPQA)

CMMI Agile
SP.
Practice Statement Practices Artefacts
No.
Objectively evaluate selected performed • Some basic PPQA are being done • Tracking to closure
processes against applicable process through Scrum Master role in Corrective actions derived
SP 1.1 descriptions, standards, and procedures. facilitating the implementation of during retrospective meeting
scrum process and removing process in subsequent sprints
barriers and inefficiencies
• Audit reports
Objectively evaluate selected work products • Participation of other Scrum Master in
against applicable process descriptions, Sprint Retrospectives to provide
SP 1.2 standards, and procedures. independent view point of
effectiveness of Scrum process
• Subjecting Agile projects to auditing
cycle as per the Agile methodology
Communicate quality issues and ensure defined in QMS
SP 2.1 resolution of noncompliance issues with the
staff and managers.

Establish and maintain records of the quality

SP 2.2
assurance activities.

- 63 -
 Configuration Management
Purpose:
• The purpose of Configuration Management (CM) is to establish and maintain the
integrity of work products using configuration identification, configuration control,
configuration status accounting, and configuration audits.

• Establish Baselines(SG1)

• Track and Control Changes (SG2)

• Establish Integrity (SG3)

Refer: “Interpreting CMMI When Using Agile Approaches” in Part I of CMMI DEV V1.3

- 64 -
 Configuration Management

CMMI Version 1.3 elaboration about Configuration Management:

• In Agile environments, configuration management (CM) is important because of
the need to support frequent change, frequent builds (typically daily), multiple
baselines, and multiple CM supported workspaces (e.g., for individuals, teams,
and even for pair-programming).
• Agile teams may get bogged down if the organization doesn’t: 1) automate CM
(e.g., build scripts, status accounting, integrity checking) and 2) implement CM as
a single set of standard services.
• At its start, an Agile team should identify the individual who will be responsible to
ensure CM is implemented correctly. At the start of each iteration, CM support
needs are re-confirmed. CM is carefully integrated into the rhythms of each team
with a focus on minimizing team distraction to get the job done.

Refer: “Interpreting CMMI When Using Agile Approaches” in Part I of CMMI DEV V1.3

- 65 -
 Mapping of Practices – CMMI and Agile (CM)
CMMI
SP.
Practice Statement
No.
Identify the configuration items, components,
SP 1.1 and related work products that will be placed •
under configuration management.
Establish and maintain a configuration
SP 1.2 management and change management
system for controlling work products.
Create or release baselines for internal use
SP 1.3
and for delivery to the customer.
Track change requests for the configuration
SP 2.1
items.
SP 2.2 Control changes to the configuration items.
Establish and maintain records describing
SP 3.1
configuration items.
Perform configuration audits to maintain
SP 3.2
integrity of the configuration baselines.
Agile
Practices Artefacts
• Establishing basic versioning approach by labeling
items like product backlog story points (e.g. “V1.1,”
or “Story dated 1/2/YY”)
Identify the configurable items(Product backlog, CM Strategy in Sprint 0
Release backlog, Iteration backlog, Agile Project
Plan etc) and baselines to be placed under CM
system during Sprint 0
• Small releases, and continuous integration
• Maintaining repository of CI items (e.g. Photo of CM system and CI tool
whiteboard discussion on design, user stories…)
• Baselines during each iteration
• Description of baselines per iteration
• Changes to be tracked by the Product owner and
the decision and priorities are made visible in
Product backlog, release backlog
• Other documents in Agile are iteratively developed
and tracked in each iteration
• Code changes is managed by CM system
• One of the agile team member to take the
responsibility to Assess the integrity of baselines
• Status of configuration items Issues or impediments
to be discussed during
daily stand-up or
iteration retrospective
- 66 -
CMMI and Agile Practices mapping

CMMI Level 3 Process areas and Agile

Practices
Level - 3 Process Areas
(CMMI-DEV)
Optimizing

Quantitatively
Managed

Defined

Managed

Initial
© Software Engineering Institute
 Staged View of Process Areas : CMMI-DEV

Organizational Performance
5 Management Causal Analysis & Resolution
5

Organizational Process
4 Quantitative Project
Management
Performance
4

Requirements Development
Technical Solution Organizational Training
3 Product Integration
Integrated Project Management
Risk Management
Organizational Process
Definition Decision Analysis & Resolution 3
Verification Organizational Process Focus
Validation

Project Monitoring and Control

Project Planning Configuration Management
2 Supplier Agreement
Management Process & Product QA 2
Requirements Management Measurement & Analysis

Engineering Project Management Process Management Support

- 69 -
 Requirements Development
Purpose:
The purpose of Requirements Development is to produce and analyze customer,
product, and product-component requirements.

• Develop Customer Requirements(SG1)

• Develop Product Requirements (SG2)

• Analyze and Validate Requirements(SG3)

- 70 -
 Requirements Development
CMMI Version 1.3 elaboration about Requirements Development:
• In Agile environments, customer needs and ideas are iteratively elicited,
elaborated, analyzed, and validated. Requirements are documented in forms
such as user stories, scenarios, use cases, product backlogs, and the results of
iterations (working code in the case of software).
• Which requirements will be addressed in a given iteration is driven by an
assessment of risk and by the priorities associated with what is left on the
product backlog. What details of requirements (and other artifacts) to document
is driven by the need for coordination (among team members, teams, and later
iterations) and the risk of losing what was learned.
• When the customer is on the team, there can still be a need for separate
customer and product documentation to allow multiple solutions to be explored.
As the solution emerges, responsibilities for derived requirements are allocated
to the appropriate teams.”

Refer: “Interpreting CMMI When Using Agile Approaches” in Part I of CMMI DEV V1.3

- 71 -
 Mapping of Practices – CMMI and Agile (RD)
CMMI Agile
SP.
Practice Statement Practices Artefacts
No.
• Story board or list of user
SP 1.1 Elicit Needs
stories
• Story writing workshops deriving Release backlog and
the Iteration product backlog items • Product backlog which is
Transform Stakeholder Needs into
SP 1.2 a prioritised list of
Customer Requirements
requirements
Establish Product and Product • Evolving high level conceptual architecture during story
SP 2.1 writing workshops and arriving at the product component
Component Requirements
requirements and tracing in turn to the Epics • Product Architecture doc
Allocate Product Component • Also evolving the interface between the product (having dependency and
SP 2.2 components (Epics, Features)
Requirements interface chart )

SP 2.3 Identify Interface Requirements

• Conceptually user stories articulates the operational
• Annotations / Notes
Establish Operational Concepts scenario,
SP 3.1 written on User story
and Scenarios • The acceptance criteria and the annotations/notes
card
attached to each user story
During story writing workshops
• Discussion with Product owner during Iteration planning
Establish a Definition of Required
• Discussion and clarification sessions by team with
SP 3.2 Functionality and Quality
product owner during development sprint
Attributes
• Sprint review and subsequent changes to product
backlog functionality based on demo

SP 3.3 Analyze Requirements • Brainstorming done between the team and the
customer/product owner during the story writing
Analyze Requirements to Achieve workshop and Iteration Planning • Story writing workshop
SP 3.4 • Product backlog refinement meetings • Demo’s in sprint review
Balance
• Prioritization and Re-prioritization of backlog items
SP 3.5 Validate Requirements • Demo's done during Iteration review

- 72 -
 Technical Solution
Purpose:
The purpose of Technical Solution is to design, develop, and implement solutions to
requirements. Solutions, designs, and implementations encompass products, product
components, and product-related life-cycle processes either singly or in combinations
as appropriate.

• Select Product-Component Solutions(SG1)

• Develop the Design(SG2)

• Implement the Product Design(SG3)

- 73 -
 Technical Solution
CMMI Version 1.3 elaboration about Technical Solution:
• In Agile environments, the focus is on early solution exploration. By making the
selection and tradeoff decisions more explicit, the Technical Solution process
area helps improve the quality of those decisions, both individually and over
time.
• Solutions can be defined in terms of functions, feature sets, releases, or any
other components that facilitate product development. When someone other
than the team will be working on the product in the future, release information,
maintenance logs, and other data are typically included with the installed
product.
• To support future product updates, rationale (for trade-offs, interfaces, and
purchased parts) is captured so that why the product exists can be better
understood. If there is low risk in the selected solution, the need to formally
capture decisions is significantly reduced.

Refer: “Interpreting CMMI When Using Agile Approaches” in Part I of CMMI DEV V1.3

- 74 -
 Mapping of Practices – CMMI and Agile (TS)
CMMI Agile
SP.
Practice Statement Practices Artefacts
No.
Develop alternative solutions and • Developing Design solutions at the beginning of the • Spike Iteration
SP 1.1 selection criteria. agile project during Sprint 0
• Creation of a design for a set of User Stories which
make up an Epic. While creating the design
Select the product-component
component capturing the alternative designs
SP 1.2 solutions that best satisfy the considered and rationale for selecting a design
criteria established. alternative
Develop a design for the product
SP 2.1
or product component.
Establish and maintain a technical • Iterative development of design, metaphor, simple
SP 2.2
data package. design
• Implementation and refinement of design through
Design product component
refactoring • Design Flow doc or diagram
SP 2.3 interfaces using established
• Establishing a baseline design and updating the • User story notes section
criteria
design during periodic milestone e.g. End of Sprint should capture these details
Evaluate whether the product or release demos
components should be developed,
SP 2.4
purchased, or reused based on
established criteria.
• Implemented design. Implementation and refinement
Implement the designs of the
SP 3.1 of design through refactoring
product components.

• End-user training materials

• User's manual
Develop and maintain the end-use • Just enough documentation which fulfils the
SP 3.2 • Operator's manual
documentation. business and customer need
• Maintenance manual
• Online help

- 75 -
 Product Integration
Purpose:
The purpose of Product Integration is to assemble the product from the product
components, ensure that the product, as integrated, functions properly, and deliver
the product.

• Prepare for Product Integration(SG1)

• Ensure Interface Compatibility(SG2)

• Assemble Product Components and Deliver the Product (SG3)

- 76 -
 Product Integration
CMMI Version 1.3 elaboration about Product Integration:
• In Agile environments, product integration is a frequent, often daily, activity. For
example, for software, working code is continuously added to the code base in a
process called “continuous integration.”
• In addition to addressing continuous integration, the product integration strategy
can address how supplier supplied components will be incorporated, how
functionality will be built (in layers vs. “vertical slices”), and when to “refactor.”
• The strategy should be established early in the project and be revised to reflect
evolving and emerging component interfaces, external feeds, data exchange,
and application program interfaces.

Refer: “Interpreting CMMI When Using Agile Approaches” in Part I of CMMI DEV V1.3

- 77 -
Mapping of Practices – CMMI and Agile (PI)
CMMI Agile
SP.
Practice Statement Practices Artefacts
No.
Establish and Maintain a product integration • Automated integration of user story
SP 1.1
strategy components and continuous integration
Establish and maintain the environment needed to (almost daily)
SP 1.2
support the integration of the product components. • Establishing Continuous integration • Automated
environment to assemble and evaluating a Continuous integration
single build or as a progression of & build framework
Establish and maintain procedures and criteria for
SP 1.3 incremental builds
integration of the product components.
• Automatically performing sanity/integration
testing of user stories in each iteration
Review interface descriptions for coverage and
SP 2.1 • Keeping the continuous integration
completeness. • Improvements to the
environment up-to-date w.r.t. the latest
Manage internal and external interface definitions, continuous integration
product and product component interfaces
SP 2.2 designs, and changes for products and product environment
components.
Confirm, prior to assembly, that each product
component required to assemble the product has
SP 3.1 been properly identified, behaves according to its • Build breaks
description, and that the product component • Automated test
interfaces comply with the interface descriptions. failures
• Practices of Continuous integration, • System/compiler
Assemble product components according to the combined with continuous testing, Test
SP 3.2 warnings
product integration strategy and procedures. automation
• Daily build and continuous integration • Coverage reports etc
• Meeting DOD,
Evaluate assembled product components for
SP 3.3 Acceptance Criteria
interface compatibility.

Package the assembled product or product

SP 3.4
component and deliver it to the customer.

- 78 -
 Verification
Purpose:
The purpose of Verification is to ensure that selected work products meet their
specified requirements.

• Prepare for Verification(SG1)

• Perform Peer Reviews(SG2)

• Verify Selected Work Products (SG3)

- 79 -
 Verification
CMMI Version 1.3 elaboration about Verification:
• In Agile environments, because of customer involvement and frequent releases,
verification and validation mutually support each other. For example, a defect can
cause a prototype or early release to fail validation prematurely. Conversely, early
and continuous validation helps ensure verification is applied to the right product.
• The Verification and Validation process areas help ensure a systematic approach to
selecting the work products to be reviewed and tested, the methods and
environments to be used, and the interfaces to be managed, which help ensure that
defects are identified and addressed early. The more complex the product, the
more systematic the approach needs to be to ensure compatibility among
requirements and solutions, and consistency with how the product will be used.
• Examples of verification methods include the following:
• Software architecture evaluation and implementation conformance evaluation
• Path coverage testing
• Load, stress, and performance testing
• Decision table based testing
• Functional decomposition based testing
• Test case reuse
• Acceptance testing
• Continuous integration (i.e., Agile approach that identifies integration issues early)

Refer: “Interpreting CMMI When Using Agile Approaches” in Part I of CMMI DEV V1.3
- 80 -
 Mapping of Practices – CMMI and Agile (VER)
CMMI Agile
SP.
Practice Statement Practices Artefacts
No.
Select the work products to be verified
SP 1.1 and the verification methods that will be • Identifying the work products for verification
used for each. approach during Sprint 0
• Verification procedure (e.g. team to follow
Establish and maintain the environment • Verification strategy
SP 1.2 Test Driven Development
needed to support verification. during Sprint 0
• Automated testing setup (at least for unit /
Establish and maintain verification regressing / integration testing)
SP 1.3 procedures and criteria for the selected • Dedicated Sprint for Integration and Testing
work products.
Prepare for peer reviews of selected
SP 2.1
work products. • Peer reviews done through pair programming • Pairs identified for pair
practice programming
Conduct peer reviews on selected work • if not practicing pair programming then planning for • Peer review planned in
SP 2.2 products and identify issues resulting peer review during iteration planning meeting Sprint Plan
from the peer review. • Identifying review as task • Visual chart or Project
• Analyse the review data during iteration task board capturing
Analyze data about preparation, retrospective to improve in the next iteration review activity
SP 2.3
conduct, and results of the peer reviews.

Perform verification on the selected work

SP 3.1
products.
• Continuous Testing, TDD, Code refactoring
• Practices of Continuous integration, combined with • Automated test failures
continuous testing, Test automation
Analyze the results of all verification
SP 3.2
activities and identify corrective action.

- 81 -
 Validation
Purpose:

The purpose of Validation is to demonstrate that a product or product component

fulfills its intended use when placed in its intended environment

• Prepare for Validation(SG1)

• Validate Product or Product Components(SG2)

- 82 -
 Mapping of Practices – CMMI and Agile (VAL)
CMMI Agile
SP.
Practice Statement Practices Artefacts
No.
Select products and product components to be
SP 1.1 validated and the validation methods that will • Deciding the validation and
be used for each. acceptance procedure during Sprint 0
(e.g. End user domo or functional demo
Establish and maintain the environment needed • Validation strategy during
SP 1.2 or pilot etc)
to support validation. Sprint 0
• User stories and features
• Selecting the product or product
identified for validation during
components (User stories ) to be
Iteration review
Establish and maintain procedures and criteria validated during each iteration for
SP 1.3
for validation. Incremental delivery of working and
potentially acceptable product

Perform validation on the selected products and • Demo of the completed User stories • Sprint review and demo
SP 2.1
product components. done during Iteration Review meeting feedback
• Acceptance of user story
feature / product backlog
updation
•
• Demo Analysis report , acceptance of
Analyze the results of the validation activities
SP 2.2 user story feature / product backlog
and identify issues.
updation

- 83 -
 Organizational Process Focus
Purpose:
The purpose of Organizational Process Focus is to plan, implement, and deploy
organizational process improvements based on a thorough understanding of the
current strengths and weaknesses of the organization’s processes and process
assets.

• Determine Process Improvement Opportunities(SG1)

• Plan and Implement Process Improvement Activities(SG2)

• Deploy Organizational Process Assets and Incorporate

Experiences (SG3)

Process improvement occurs in the context of the organization’s needs and

is used to address the organization’s objectives. The organization
encourages participation in process improvement activities by those who
perform the process

- 84 -
 Mapping of Practices – CMMI and Agile (OPF)
CMMI Agile
SP.
Practice Statement Practices Artefacts
No.
Establish and maintain the description of the
SP 1.1 process needs and objectives for the
organization.
Appraise the processes of the organization
periodically and as needed to maintain an
SP 1.2
understanding of their strengths and
weaknesses.
• Establishing vision for implementing Agile methods in the organization
Identify improvements to the organization's • Establishing Agile Lifecycle Management System
SP 1.3
processes and process assets. • Evaluating the strengths and weaknesses of the Agile practices and
improvement plan
Establish and maintain process action plans to • Establishing organization wide Agile COE or Agile forum where agile
SP 2.1 address improvements to the organization's project teams can share best practices and learning’s between projects
processes and process assets. • Establishing periodic organization wide Agile forum meetings where each
project or group presents status report as well as
Implement process action plans across the
SP 2.2 • sharing what practices are working well
organization.
• what practices are not working well
Deploy organizational process assets across • any improvements made and learning’s that one can share
SP 3.1
the organization • Create "Socializing Agile" plan for deploying the agile LMS across the
Deploy org set of std process at their start-up organization
SP 3.2 • Agile Forums or Agile Councils at project level to monitor implementation
and deploy changes through out lifecycle
and also to capture process related experiences
Monitor the implementation of the organizations
SP3.3 set of standard processes and use of process
assets on all projects
Incorporate process related experiences
derived from planning and performing the
SP3.4 process into organizational process assets.

- 85 -
 Organizational Process Definition
Purpose:
• The purpose of Organizational Process Definition (OPD) is to establish and
maintain a usable set of organizational process assets, work environment
standards, and rules and guidelines for teams.

• Establish Organizational Process Assets(SG1)

• Organizational process assets enable consistent process execution across

the organization and provide a basis for cumulative, long-term benefits to the
organization.

- 86 -
 Mapping of Practices – CMMI and Agile (OPD)
CMMI Agile
SP.
Practice Statement Practices Artefacts
No.
Establish and maintain the organization's set of
SP 1.1
standard processes.

• Establishing Agile life cycle methodology as part of QMS

Establish and maintain descriptions of the life- • Establishing Agile knowledge sharing portal as a part of process asset
SP 1.2 cycle models approved for use in the library to share best practices, methods, tools, artifacts and sprint
organization. retrospective learning’s
• Establishing guidelines to address different project & Team scenarios and
guideline for Agile Methodologies.
Examples: Extreme Programming, Scrum, Kanban, Lean etc or
Establish and maintain the tailoring criteria and combination of these methods
SP 1.3 guidelines for the organization's set of standard • Establishing and Maintaining an Agile metrics system to capture all the
processes. agile related metrics from the agile projects

Establish and maintain an organizational

SP 1.4
measurement repository
Establish and maintain the organization's
SP 1.5
process asset library.
Establish and maintain the work environment • Establishing and maintaining the Agile Way of working guidelines. Similar
SP 1.6
standards to "Just Rules" practice of Extreme Programming
• Establishing and maintaining the guidelines to setup a cross functional
Establish and maintain organizational rules and agile teams that has all the skill sets necessary for producing a potentially
SP 1.7 guidelines for the structure, formation, and shippable product.
operation of teams. Example: Agile teams should be 7 + or - 2 people per team, reporting
structure, handling HR related issues

- 87 -
 Organizational Training
Purpose:
The purpose of Organizational Training is to develop the skills and knowledge of
people so that they can perform their roles effectively and efficiently.

• Establish an Organizational Training Capability(SG1)

• Provide Necessary Training(SG2)

An organizational training program involves the following activities:

• Identifying the training needed by the organization
• Obtaining and providing training to address those needs
• Establishing and maintaining a training capability
• Establishing and maintaining training records
• Assessing training effectiveness

- 88 -
 Mapping of Practices – CMMI and Agile (OT)

CMMI Agile
SP.
Practice Statement Practices Artefacts
No.
Establish and maintain the strategic training
SP 1.1
needs of the organization

Determine which training needs are the

SP 1.2 responsibility of the organization and which will
be left to the individual project or support group
• This process area should be implemented as it is defined in CMMI.
• However, inputs for Agile training needs to derived from “Socializing Agile”
Practice of OPF.
Establish and maintain an organizational
SP 1.3 • Establishing Organizational level Agile methods training and training
training tactical plan
records
• Carrying out team training plan in Agile projects during the Sprint 0 phase
Establish and maintain training capability to and release planning phase
SP 1.4
address organizational training needs • Imparting Agile methodology training to teams (e.g. Specific agile
practices trainings like Pair Programming, Test driven development,
Deliver the training following the organizational Continuous integration, test automation etc.,)
SP 2.1
training tactical plan

Establish and maintain records of the

SP 2.2
organizational training

Assess the effectiveness of the organization's

SP 2.3
training program

- 89 -
 Integrated Project Management
Purpose:
The purpose of Integrated Project Management is to establish and manage the
project and the involvement of the relevant stakeholders according to an integrated
and defined process that is tailored from the organization's set of standard processes.

• Use the Project’s Defined Process(SG1)

• Coordinate and Collaborate with Relevant Stakeholders(SG2)

Integrated Project Management involves the following activities:

• Establishing the project’s defined process at project startup by tailoring the
organization’s set of standard processes
• Managing the project using the project’s defined process
• Establishing the work environment for the project based on the
organization’s work environment standards
• Establishing teams that are tasked to accomplish project objectives
- 90 -
 Mapping of Practices – CMMI and Agile (IPM)
CMMI Agile
SP
No. Practice Statement Practices Artefacts
Establish and maintain the project's defined process from • Establishing tailored Agile methodology for the project based
SP 1.1 on QMS, tailoring guidelines, project scenarios (distributed
project start-up through the life of the project
Use the organizational process assets and measurement agile team, Onsite PO, Scaling SCRUM etc.,)
SP 1.2 repository for estimating and planning the project's
activities. • Refining project defined process based on inputs from sprint
retrospectives
Establish and maintain the project's work environment
SP 1.3
based on the organization's work environment standards. • Collective ownership of the team on project deliverables
Integrate the project plan and the other plans that affect
SP 1.4 • Customer representative on the team strengthens stake
the project to describe the project's defined process.
holder involvement and helps maintain project shared vision
Manage the project using the project plan, the other
SP 1.5 plans that affect the project, and the project's defined • Daily Stand up meetings, sharing impediments and Scrum
process. master role addressing the impediments and process
SP 1.6 Establish and maintain teams inefficiencies, helps in addressing Integrated Project
Management
Contribute process related experiences to organizational
SP 1.7
process assets.
Manage the involvement of the relevant stakeholders in
SP 2.1
the project.

Participate with relevant stakeholders to identify,

SP 2.2
negotiate, and track critical dependencies.

SP 2.3 Resolve issues with relevant stakeholders.

- 91 -
 Risk Management
Purpose:
The purpose of Risk Management (RSKM) is to identify potential problems before
they occur so that risk handling activities can be planned and invoked as needed
across the life of the product or project to mitigate adverse impacts on achieving
objectives.

• Prepare for Risk Management(SG1)

• Identify and Analyze Risks(SG2)

• Mitigate Risks (SG3)

Risk management can be divided into the following parts:

• Defining a risk management strategy
• Identifying and analyzing risks
• Handling identified risks, including the implementation of risk mitigation
plans as needed

- 92 -
 Risk Management
CMMI Version 1.3 elaboration about Risk Management:
• In Agile environments, some risk management activities are inherently
embedded in the Agile method used. For example, some technical risks can be
addressed by encouraging experimentation (early “failures”) or by executing a
“spike” outside of the routine iteration.
• However, the Risk Management process area encourages a more systematic
approach to managing risks, both technical and non-technical. Such an
approach can be integrated into Agile’s typical iteration and meeting rhythms;
more specifically, during iteration planning, task estimating, and acceptance of
tasks.

Refer: “Interpreting CMMI When Using Agile Approaches” in Part I of CMMI DEV V1.3

- 93 -
 Mapping of Practices – CMMI and Agile (RSKM)
CMMI
SP.
Practice Statement
No.
Determine risk sources and
SP 1.1
categories.
Define the parameters used to
analyze and categorize risks, and
SP 1.2
the parameters used to control the
risk management effort.
Establish and maintain the strategy
SP 1.3
to be used for risk management.
SP 2.1 Identify and document the risks.
Evaluate and categorize each
identified risk using the defined risk
SP 2.2
categories and parameters, and
determine its relative priority.
Develop a risk mitigation plan in
SP 3.1 accordance with the risk
management strategy.
Monitor the status of each risk
SP3.2 periodically and implement the risk
mitigation plan as appropriate.
Agile
Practices Artefacts
• Use of short iterations, sprint review, involvement
of customer in demo of working software at the
end of sprint are potential instruments to mitigate
risks
• Best way of dealing with risk is transparency ,
transparency is the hallmark of most agile
• Risk management section in
methods
the Agile Project plan
• Agile practices handles technical, product and • Risk assessment sheet
engineering related risks well
• Establish mechanism for handling risks related to
project resources and stakeholder issues
• Ensure risk identification, risk analysis and risk
categorization during sprint 0 phase.
• Risk assessment sheet
• Updated lists of risk status
• Documented handling options for each identified
risk • Updated assessments of risk
• Risk mitigation plans likelihood, consequence, and
• Contingency plans thresholds
• List of those who are responsible for tracking and • Updated list of risk handling
addressing each risk options
• Monitor the status of risks during the release • Updated list of actions taken
planning, iteration planning to handle risks
• Risk mitigation plans of risk
handling options
- 94 -
 Decision Analysis and Resolution
Purpose:
• The purpose of Decision Analysis and Resolution (DAR) is to analyze possible
decisions using a formal evaluation process that evaluates identified alternatives
against established criteria.

• Evaluate Alternatives(SG1)

A formal evaluation process involves the following actions:

• Establishing the criteria for evaluating alternatives
• Identifying alternative solutions
• Selecting methods for evaluating alternatives
• Evaluating alternative solutions using established criteria and methods
• Selecting recommended solutions from alternatives based on
evaluation criteria

- 95 -
 Mapping of Practices – CMMI and Agile (DAR)
CMMI Agile
SP No. Practice Statement Practices Artefacts

Establish and maintain guidelines to determine which issues are

SP 1.1
subject to a formal evaluation process.

Establish and maintain the criteria for evaluating alternatives, and • This process area to be implemented as it is
SP 1.2
the relative ranking of these criteria. defined in CMMI.
• Sprint planning affords a frequent opportunity to
evaluate the direction of project, examines
SP 1.3 Identify alternative solutions to address issues.
alternatives and makes informed decisions
• Decisions on Product architecture and technical
SP 1.4 Select the evaluation methods.
solution during exploration phase
Evaluate alternative solutions using the established criteria and • Product backlog prioritization using MOSCOW
SP 1.5 principles (Business value, Risks, Technical
methods.
issues)
• Decision and Analysis in Product backlog
refinement meetings
Select solutions from the alternatives based on the evaluation
SP 1.6
criteria.

- 96 -
CMMI High Maturity (ML4 and ML5)
Process Area Mapping

Conclusion
Level - 4 Process Areas
(CMMI-DEV)
Optimizing

Quantitatively
Managed

Defined

Managed

Initial
© Software Engineering Institute
Staged View of Process Areas : CMMI-DEV

Organizational Performance
5 Management Causal Analysis & Resolution
5

4 Quantitative Project Management Organizational Process

Performance 4

Requirements Development
Technical Solution Organizational Training
3 Product Integration
Integrated Project Management
Risk Management
Organizational Process Definition Decision Analysis & Resolution 3
Verification Organizational Process Focus
Validation

Project Monitoring and Control

Project Planning Configuration Management
2 Supplier Agreement Management Process & Product QA 2
Requirements Management Measurement & Analysis

Engineering Project Management Process Management Support

- 99 -
 Organizational Process Performance
Purpose:
• The purpose of Organizational Process Performance is to establish and maintain a
quantitative understanding of the performance of the organization's set of standard
processes in support of quality and process-performance objectives, and to provide
the process performance data, baselines, and models to quantitatively manage the
organization's projects.

• Establish Performance Baselines and Models (SG1)

• Measuring quality and process performance can involve combining existing

measures into additional derived measures to provide more insight into
overall efficiency and effectiveness at a project or organization level.

- 100 -
Implementing OPP concepts in Agile projects

Agile practices focus is at project level, and does not advocate idea
of measuring process and maintaining baselines and models. Some
suggested steps could be

• Normalization or standardization of story point units across

common set of projects for a domain

• Establishing baselines on velocity, percentage of completion of

backlog items against the commitment made during sprint
planning

• Establishing baselines on defects and issues identified by

customer during sprint or release reviews

- 101 -
 Quantitative Project Management
Purpose:
The purpose of the Quantitative Project Management process area is to quantitatively
manage the project's defined process to achieve the project's established quality and
process-performance objectives.

• Prepare for Quantitative Management (SG1)

• Quantitatively Manage the Project (SG2)

Statistical and other quantitative techniques are used to develop an

understanding of the actual performance or to predict the performance
of processes. Such techniques can be applied at multiple levels, from a
focus on individual sub processes to analyses that span lifecycle
phases, projects, and support functions.

- 102 -
 Quantitative Project Management

CMMI Version 1.3 elaboration about Quantitative Project Management:

In Agile environments, Examples of project quality and process performance

objectives include:
• Maintain change request backlog size below a target value.
• Improve velocity in an Agile environment to a target value by a target
date.
• Reduce idle time by x% by a target date.
• Maintain schedule slippage below a specified percent.
• Reduce the total lifecycle cost by a specified percent by a target
date.
• Reduce defects in products delivered to the customer by 10%
without affecting cost.

Refer: “Interpreting CMMI When Using Agile Approaches” in Part I of CMMI DEV V1.3

- 103 -
Implementing QPM concepts in Agile Projects

• Establishing project level goals during sprint and release

planning on parameters like
• Velocity, percentage of completion of backlog items against
the commitment made during sprint planning, Defects and
issues to be identified by customer during sprint or release
reviews

• Doing analysis using quantitative techniques and discussing in

sprint retrospectives and performance across various sprint
cycles and doing post project analysis emphasizes the
importance of feedback loops and getting insight on cause and
effect in quantitative terms

- 104 -
Level - 5 Process Areas
(CMMI-DEV)
Optimizing

Quantitatively
Managed

Defined

Managed

Initial
© Software Engineering Institute
Staged View of Process Areas : CMMI-DEV

Organizational Performance
5 Management Causal Analysis & Resolution
5

4 Quantitative Project Management Organizational Process

Performance 4

Requirements Development
Technical Solution Organizational Training
3 Product Integration
Integrated Project Management
Risk Management
Organizational Process Definition Decision Analysis & Resolution 3
Verification Organizational Process Focus
Validation

Project Monitoring and Control

Project Planning Configuration Management
2 Supplier Agreement Management Process & Product QA 2
Requirements Management Measurement & Analysis

Engineering Project Management Process Management Support

- 106 -
 Causal Analysis and Resolution
Purpose:
The purpose of Causal Analysis and Resolution (CAR) is to identify causes of
selected outcomes and take action to improve process performance.

• Determine Causes of Selected Outcomes (SG1)

• Address Causes of Selected Outcomes (SG2)

• Causal analysis and resolution improves quality and productivity by

preventing the introduction of defects or problems and by identifying and
appropriately incorporating the causes of superior process performance.
• Reliance on detecting defects and problems after they have been
introduced is not cost effective. It is more effective to prevent defects and
problems by integrating Causal Analysis and Resolution activities into each
phase of the project.

- 107 -
 Implementing CAR concepts in Agile projects

• Effective Sprint retrospective meetings doing Causal analysis

and resolution on common issues and practices implemented.
Identifying actionable, new ideas, and implementing it in next
sprint cycles and sharing the learning’s across other projects
through Agile forums, COE’s etc.,

- 108 -
 Organizational Performance Management
Purpose:
The purpose of Organizational Performance Management (OPM) is to proactively
manage the organization’s performance to meet its business objectives.

• Manage Business Performance(SG1)

• Select Improvements (SG2)

• Deploy Improvements (SG3)

• The Organizational Performance Management process area enables the

organization to manage organizational performance by iteratively analyzing
aggregated project data, identifying gaps in performance against the
business objectives, and selecting and deploying improvements to close
the gaps.

- 109 -
 Implementing OPM concepts in Agile projects

• Aggregating learning’s in Sprint retrospective meetings, Project

performance data, Sprint review data in monthly agile forum
meetings in the organization.
• Establishing improvement opportunities in agile processes
through addition, deletion and modification of agile methods,
tools and processes to track overall improvements in the
performance of agile projects in the organization

- 110 -
 Conclusion

“CMMI framework can be leveraged to address some of the limitations of

Agile for broad basing across the organization”

Primary goals
• CMMI: Predictability, Stability, high assurance
• Agile: Customer satisfaction, Speed

Scope
• CMMI: Broad, Inclusive and Organizational
• Agile: Small, Focused, Project

Improvement focus
• CMMI: Process
• Agile: People

111
Key Elements of QAI’s ApproachABOUT QAI
QAI is
• a leading global consulting
Identifying and workforce
& Applying Agile development
practices organization, addressing the space
of “Operational Excellence”.
• That
QAI Global Services, thebest suit the
consulting organization
division needs
of QAI, addresses the&space
context
of Operational
Excellence, which includes the areas of Process Management, Quality Management, Innovation
Management, • Project
To selective
Management, areas within
IT Service the organization
Management that are most favorable
and others. for Agile Implementation
QAI Global Institute, the workforce development division of QAI, focuses on creating international
•
education Competency
and building
training products within
and services organization
to address on Agile,
the competence CMMI and their co-existence
development,
assessments and certifications to cater to the large pool of manpower requiring skills for increased INDIA
• Establishing
employability. a complete
e-Learning, VSAT andand
based delivery customized IT approaches
blended learning Lifecycle haveModelbeen(approach) [Integrated USA
taken. Process Architecture] CHINA
QAI's regional bases across the globe in the US, Singapore, China, Malaysia, UK, Canada and
India helps to• innovatively
That isdistribute
based on andAgile
managepractices
engagements across multiple locations. QAI MALAYSIA
clients include IBM, Accenture, Wipro, Prudential, Genpact, American Express, Sony, Tata Motors SINGAPORE
and 200 others• across 30 countries.
Ensures compliance with CMMI-PAs

• Re-uses existing processes & tools (as far as possible)

CONTACT US
• That is an addition to the Lifecycle Models already defined in the organization with clearly
defined usage scenarios
QAI India: QAI USA: QAI Malaysia:
1010 - 1012, Ansal Towers, 38 Nehru Place Windsor at Metro Center, 2101 Park Level 36, Menara Citibank, 165, Jalan
• Real time pilot implementation support and fine tuning before organization wide
New Delhi - 110019, India Center Dr., Suite 200, Orlando, FL Ampang, 50450 Kuala Lumpur, Malaysia
Phone: +91- 11- 26219792, 26220580 32835-7614 Phone: +603 2169 6241
deployment Phone: +407-363-1111

QAI Singapore: QAI China:

391B Orchard Road #23-01, Rm. 1211, No. 498 Guoshoujing Rd.
Ngee Ann City Tower B, Shanghai Zhangjiang Hi-Tech Park,
Singapore - 238874 Pudong New Area, Shanghai, China
Phone:+65-6225-8139 Zip: 201203
Phone : +86-21-51314155

© QAI
All rights reserved. No part of this document may be reproduced or distributed in any form or by any means,
or stored in a database or retrieval system, without prior written permission of QAI
112