[AgileCMMI] Practical Experience Report: Application of Project Management areas from CMMI model in an Agile development environment

2009
CMMI® 9th Technology Conference and User Group www.ndia.org/meetings/0110

Practical Experience Report: Application of Project
Management areas from CMMI model in an Agile
development environment

Author: Ahmed Mahdy
Senior Software Quality Engineer, Agile Coach
Raya Corporation, Egypt
aamahdys@gmail.com
ahmed_mahdy@rayacorp.com

Reviewer: Sree Yellayi
SCAMPI Lead Appraiser, SEI Authorized CMMI® Instructor, Certified Scrum Master
Siemens, Greater New York City Area
sree.yellayi@siemens.com
sreeramamurthy@yahoo.com

Abstract

The Capability Maturity Model Integration (CMMI) has been broadly used for assessing
organizational maturity and process capability throughout the world. Although most of the
customers give priority to CMMI certified organizations over others for guaranteeing the
quality, the nature of their rapid market change can no longer accept heavyweight plans,
requirements specification, change requests, contract negotiation, and other
documentation. Moreover, the rapid change in information technology has caused
increasing the frustration more, especially that there are new competitors started using
lightweight processes that invite to customer collaboration over contract negotiation and
working software over comprehensive documentation that is called “Agile” methodologies
that have been adopted to tackle this challenge. Agile development methods and CMMI are
often perceived to be at odds with each other. In fact, it’s possible to embrace both to
dramatically improve business performance. This paper focuses on the verification of
implementing CMMI Project Management process areas in agile organizations based on a
real and practical experience in Agile and CMMI successful projects.
The authors are going to share their practical experiences in interpreting the CMMI model's
project management practices in an Agile environment to address the model intent and not
compromising on the credibility or value of the practices.

1

2009

Agile CMMI
Why Agile CMMI?
Most of the promising objectives of any software development method or process are delivering
working software on time, quality and budget. Software Engineering Institute (SEI) has paid a lot
of efforts to mostly satisfy these objectives in its process improvement models, and version 1.3
of CMMI Development will be released soon.
Nevertheless, the world becomes convinced with adding another objective, which was somehow
neglected more than highly considered, which is delivering a business value to the customer. [1]

Agile Scrum methodology
I assume that the readers know what CMMI is, or/and has experience in its implementation.
Scrum is a software development methodology that teams can adopt quickly to plan and
manage their daily work. Every Scrum activity has enough detail to plan, design, build and
test output, while tracking team progress. There are multiple planning levels and its strength
is that it is straightforward and easy to use. The risk is that some scrum implementers may
focus on generating components regardless of the complete integrated system, and this risk
is managed. The paper will not go through explaining what scrum or CMMI is in detail and
how to implement it, online materials are more than enough for that. Let us jump to explain
how we could embrace both.

CMMI Project Management process areas:

Project Management process areas cover the project management activities related to
planning, monitoring, and controlling the project.
The Project Management process areas of CMMI are as follows:
• Project Planning
• Project Monitoring and Control
• Integrated Project Management
• Risk Management

The Basic Project Management process areas address the activities related to establishing
and maintaining the project plan, establishing and maintaining commitments, monitoring
progress against the plan, taking corrective action, and managing supplier agreements.

Project Planning

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

SP CMMI Practice Agile Practice
1.1 Establish a top-level work breakdown structure (WBS) to High level user stories (i.e. the
estimate the scope of the project. parent of user stories)

1.2 Establish and maintain estimates of the attributes of the Story points, used to estimate the

2

2009

work products and tasks. difficulty/complexity (or relative size)
of a Story (feature).

1.3 Define the project life-cycle phases upon which to scope The Scrum process.
the planning effort.

1.4 Estimate the project effort and cost for the work products Scrum Ideal Time estimate (similar
and tasks based on estimation rationale. to billable hours or Full-time
Equivalents).

2.1 Establish and maintain the project’s budget and Scrum estimates (in Ideal Time).
schedule. Estimates of what work will be in
each release.
Iteration Backlog.
Project Task board.

2.2 Identify and analyze project risks. Iteration Retrospective

2.3 Plan for the management of project data. Project Internal Chartering
2.4 Plan for necessary resources to perform the project. Scrum estimates in Ideal Time
Release plan, Iteration Backlog and
assignments.

2.5 Plan for knowledge and skills needed to perform the Project Internal Chartering
project. Release Planning (synchronized
with the internal chartering)
2.6 Plan the involvement of identified stakeholders. Scrum process roles
External and Internal Chartering

2.7 Establish and maintain the overall project plan content. Scrum release plan.
Iteration Backlog.
Project Taskboard.
[Note: The term “plan” in CMMI
refers to additional plan
components (such as risks and data
management) that are not
called out specifically in Scrum.]

3.1 Review all plans that affect the project to understand Iteration planning meeting.
project commitments. Daily Scrum meeting.

3.2 Reconcile the project plan to reflect available and Iteration planning meeting.
estimated resources. Daily Scrum meeting.

3.3 Obtain commitment from relevant stakeholders Iteration planning meeting.
responsible for performing and supporting plan Daily Scrum meeting.
execution. [Note: The stakeholders listed in
Scrum might not be the complete list

3

2009

of stakeholders for the project.]

The column of “Agile Practice” means either a previously defined practice in agile community or
a new proposed practice that does contradict with agile principles.

Project Monitoring and Control

The purpose of Project Monitoring and Control (PMC) is to provide an understanding of
the project’s progress so that appropriate corrective actions can be taken when the
project’s performance deviates significantly from the plan.

SP CMMI Specific Practice Agile Practice
SP1.1 Monitor the actual values of the project planning Iteration burndown chart that tracks effort
parameters against the project plan. remaining.
Release burndown chart that tracks
completed story points. This shows how
much of the product functionality is left to
complete.
Project Task Board used to track stories
(requirements) that are done, in progress,
or ones that need verification.

Monitor commitments against those identified in
the project plan.

SP Monitor commitments against those Discussions on team commitments at the:
identified in the project plan. − Daily Scrum meeting.
− Iteration review meeting.
• Iteration burndown chart that tracks
effort remaining.
• Release burndown chart that tracks
story points that have been
completed. This shows how much of the
product functionality is left to complete.
SP Monitor stakeholder involvement against the Discussions at the:
project plan. − Daily Scrum meeting.
• [Note: The stakeholders listed in Scrum
might not be the
complete list of stakeholders for the
project, e.g., customers, other impacted
teams.]
Periodically review the project's progress, Daily Scrum meeting.
performance, and issues. Iteration review meeting.
Retrospectives.
Review the accomplishments and results of the Iteration review meeting.

4

2009

project at selected project milestones.
Collect and analyze the issues and determine the Notes from the:
corrective actions necessary to address the − Daily Scrum meeting.
issues. − Iteration review meeting.
[Note: Some teams track their
outstanding actions on the Product
Backlog. It doesn’t matter where or how
the items are tracked, as long as they
are.]

Take corrective action on identified issues. Actions from the:
− Daily Scrum meeting.

Manage corrective actions to closure. Tracking of actions from:
− Daily Scrum meeting.
• [Note: This assumes that teams will
track (and not lose) actions.]

Integrated Project Management

The purpose of Integrated Project Management (IPM) 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.
Assumption:
There is an established Guidelines and Strategy of Agile Standards (GSAS) for agile projects:
- Data Management Strategy
- Lifecycle roadmap strategy (Agile roadmap or workflow with the connection dependencies,
conditions, input/output)
- People Management Plan:
- Agile People Roles, Skills and Responsibilities
- Any constraints

1.1 Establish and maintain the project's defined process from OPF and OPD is a reference for this
project startup through the life of the project. practice
Project process can be stated from
the internal/external chartering
meetings (it can be updated with re-
meeting the stakeholders throughout
the work because the nature of
software process is empirical)
1.2 Use the organizational process assets and measurement Given the Guidelines and Strategy of
repository for estimating and planning the project’s Agile Standards:
activities. Roadmap (Scope of Work)
Release Planning
Iteration Planning
(the estimation of stories – both high

5

2009

and low level)
1.3 Establish and maintain the project's work environment Given the Guidelines and Strategy of
based on the organization's work environment standards. Agile Standards:
List of required tools for agile or scrum
activities
Other requirements for work
environment that are standardized in
1.4 Integrate the project plan and the other plans that affect the Project Integrated Plan which
project to describe the project’s defined process. includes:
Roadmap (Scope of Work over the
releases)
Release Plan
Iteration Plan
( it’s important to integrate these plans
to be synchronized due to the
expected updates throughout the
work)
Using Rally, VersionOne, TFS 2010 or
any other similar tools definitely help
you in achieving that easily.
1.5 Manage the project using the project plan, the other plans Project Integrated plan
that affect the project, and the project’s defined process. Review meetings that may update
requirements and plans
1.6 Contribute work products, measures, and documented Iteration Retrospectives
experiences to the organizational process assets. Release Retrospectives
Project Lessons learned
2.1 Manage the involvement of the relevant stakeholders in the Updatable Schedule of the coming
project. events (Release planning and
retrospectives, Iteration planning and
retrospectives, customer meetings)
Roles and Responsibilities in GSAS
2.2 Participate with relevant stakeholders to identify, negotiate, Action items from standup meetings,
and track critical dependencies. iteration and release retrospectives
Story slicing that can show
dependencies
Senior Management meetings and its
action items
Action items should be assigned and
tracked in whatever tool
2.3 Resolve issues with relevant stakeholders. The tool of action items tracking
should show the status of all action
items, and all issues.
Results of action items’ tracking

Risk Management

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.

6

2009

Important Notes:
- It’s really *important* to manage your risks
- Early risk identification (discovering and exploring)
- Consider both internal and external chartering risks (cost, schedule,
performance, technical and other risks)
- Discuss any new risk
- Prepare a mitigation for the identified risk with the collaboration of other
stakeholders
- Assign the responsibility of such mitigation actions to people
- Monitor and follow up these mitigations in the agile meetings in your process
- I personally prefer using any tracking tool that help you in adding/updating
risks

1.1 Determine risk sources and categories. Risk Categories in iteration and
release retrospectives
1.2 Define the parameters used to analyze and categorize Discuss each risk in iteration and
risks, and the parameters used to control the risk release retrospectives , define the
management effort. parameters for risks, and not to
involve the management in all risks,
you can define threshold for
management involvement other than
the relevant risks by nature.
1.3 Establish and maintain the strategy to be used for risk Discuss the mitigation for each risk
management. with the stakeholders in iteration and
release retrospectives, identify
assigned action items and how to
monitored with due dates if possible.
2.1 Identify and document the risks. Here the call to use any tool for
documenting and monitoring the risks.
2.2 Evaluate and categorize each identified risk using the Discuss and analyze each risk with
defined risk categories and parameters, and determine its evaluating its defined parameters
relative (priority, impact, probability and any
priority. other parameter you need for your
organization)
3.1 Develop a risk mitigation plan for the most important risks to Discuss the actions for each identified
the project as defined by the risk management strategy. risk mitigation and plan for its follow
up and handling
3.2 Monitor the status of each risk periodically and implement Iteration and release retrospective can
the risk mitigation plan as appropriate. perform these actions:
Update the risks with additional risks,
status of old risks, status of actions
and mitigations,

References:

[1] Neil Potter and Mary Sakry, Process Group Newsletter Volume 16 No 2, March 2009
[2] CMMI Product Team, CMMI for Development Ver 1.2, Nov 2007
[3] Agile CMMI Workshop by Ahmed Sidky, Marian Tadros, Sree Yellayi , Egypt 2008
[4] Software Process Improvement Community Meetings, Egypt
7

2009

IMPORTANT NOTES:

• These practices are proposed and they may not be
the best practices for your organization,

• These practices are only for a proof of
AgileCMMI,

• Do NOT implement these proposed practices If
you think there are other practices that ADD
more value,

• Explore more practices !

8

[AgileCMMI] Practical Experience Report: Application of Project Management areas from CMMI model in an Agile development environment

More Related Content

What's hot (20)

Viewers also liked (18)

Similar to [AgileCMMI] Practical Experience Report: Application of Project Management areas from CMMI model in an Agile development environment (20)

Recently uploaded (20)

[AgileCMMI] Practical Experience Report: Application of Project Management areas from CMMI model in an Agile development environment