Blending Agile with CMMI®

Cutter Journal, Jim Highsmith Editor
Blending Agile Development Methods with CMMI®
by Glen Alleman
There are two popular myths living on opposite poles of the software development globe
[Glaz01]. The first myth, which lives in the high–ceremony world of government contractors and
corporate IT outsourcing organizations, holds that agile development processes are the same as
“hacking” — undisciplined, ad hoc, and prone to rapid change by external forces. The other
myth, which lives in software firms that practice some variant of an agile development
methodology (Extreme Programming, Scrum, etc.), holds that CMMI® [CMMI] is a dinosaur that
will go the way of all dinosaurs.1
This camp claims that the CMMI® processes do not address the
core issue of software — validating that the customer is getting what [they] want in the presence
of changing requirements.
Like most myths in the software development business, each carries a grain of truth along with a
large dose of falsehood. Further examination shows both myths to be flawed in important and
misleading ways. This paper attempts to put both agile development process and the CMMI® in a
context where each myth–holder can see the motivation, purpose, benefit, and applicability of
each side by describing how CMMI and XP–inspired processes are blended at Rocky Flats
Environmental Technology Site www.rfets.gov.
WHERE TO START?
Much of the problem with discussing the blending of CMMI with agile has to do with where the
discussion starts. One difficulty with the conversation is the assumption by both sides that they
understand how the other side works. CMMI’ers assume they understand agile enough to know it
has problems, and agilists assume they understand enough about CMMI to know it will be trouble
for their approach to development. This situation is not unusual where strongly held positions
produce barriers to discussion.
The first step in closing the gap in these assumptions is the realization that CMMI and Agile are
philosophically compatible but still culturally separated. In spite of this cultural gap, their goals
have much in common:
• They seek to improve the performance of software development organizations.
• Rigorous planning is part of their core processes.
• Rules form the basis of the work processes.
• Neither is comprehensive or suitable for all software development or acquisition problems.
• Both are based on experience from past successes and failures.
MOTIVATION FOR CMMI
Improvement in software quality has been associated with higher levels of CMMI compliance
[Herb94], [Gold03]. These improvements include:
• Reduced rework
• Predictable engineering milestones
• Measurable improvements of products and services
1
In the agile literature there is confusion between CMM and CMMI. In some sense CMM is a
dinosaur and has already gone away. [STSC] is a good reference for the differences between
CMM and CMMI.
1/14

• Greater customer satisfaction
MOTIVATION FOR AGILE
Continued problems with cost, schedule, and functionality of software development projects have
motivated a segment of the software community to search for alternatives to traditional
development methodologies. One difficulty faced by agile processes in the presence of a CMMI
culture is “where’s the proof” that these new methods add value?
If you are an adherent of Geoffrey Moore’s Crossing the Chasm [Moor02] then you’ll understand
that “proof” is asked by those on the right side of the adaptation curve. Agile is in the innovative,
early adopters, and early majority part of the curve [Ambl04].
Figure 1 – Incorporating agile development into CMMI involves crossing the chasm and becoming
an early adopter. Asking for proof before adopting is done by the late majority and laggards.
For early innovators and adopters the motivation for agile is to move from the current paradigm
to something new. They’re “moving away” from the current paradigm. Late majority and
laggards need to “move toward” something new with the assurances that whatever this new thing
is, it will not disrupt their old paradigm.
WHAT IS THE CMMI ALL ABOUT?
CMMI is a framework for improving the processes of software organizations that is premised on
the idea that “the quality of a system or product is highly influenced by the quality of the process
used to develop or maintain it.” It was strongly influenced by Watts Humphrey’s work
[Hump89], which provided the basic principles of a “capability maturity model.” The Software
Engineering Institute’s (SEI) research shows there are three critical dimensions that organizations
typically focus on: people, procedures and methods, and tools and equipment [Gold03].
The core idea in CMM is – it’s the process that delivers the quality. Institutionalizing the
process assures it will deliver. This is different from the core idea in an agile
methodology, where individuals and their interactions are guided by the principles of
agile. [integrate into preceding or following paragraph?]
CMMI is a collection of Process Area components that are institutionalized across an
organization. There are several CMMI process frameworks. For this paper I’ll use the CMMI for
Software, Staged Representation [SEI02]. There are innumerable examples and pictures of these
five levels, so I won’t reproduce them here. It is important, though, to understand these five levels
build on each other. Higher levels of maturity include the process areas of the lower levels or
have enhanced versions of the same process areas.
As a result, prematurely mandating achievement of a specific level leads to failure. Some firms
applying CMMs have little knowledge of their use in process improvement. They impose a
CMMI level without understanding the effort, cultural changes, or resource impact.
2/14

Without understanding the taxonomy of CMMI, the “agilist” can easily claim CMMI is too
complex. The fact that the CMMI for software is 624 pages and there are equally large books just
to explain the CMMI easily supports this claim.
CMMI in One Chart
The five (5) levels of maturity, the process areas for each maturity level and their relationship to
the process categories are shown in Table 1. 2
Maturity Level Process Areas by Maturity Level Category
ProcessManagement
ProjectManagement
Engineering
Support
5 Optimizing
Continuous process
improvement
CAR Causal Analysis and Resolutions
OID Organizational Innovation and Deployment
4 Quantitatively
Managed
Quantitative
management
QPM Quantitative Project Management
OPP Organizational Process Performance
3 Defined
Process
Standardization
DAR Decision Analysis And Resolution
RSKM Risk Management
IPM Integrated Project Management
OT Organizational Training
OPD Organizational Process Development
OPF Organizational Process Focus
VAL Validation
VER Verification
PI Product Integration
TS Technical Solution
RD Requirements Development
2 Managed
Basic project
management
CM Configuration Management
PPQA Process and Quality Assurance
M&A Measurement and Analysis
SAM Supplier Agreement Analysis
PMC Project Monitoring and Control
PP Project Planning
REQM Requirements Management
1 Initial
Table 1 — Five Maturity Levels, Their Processes and Categories
WHAT ARE AGILE PROCESSES ALL ABOUT?
Agile software development processes come in several “flavors” [Pekk02], [Kale02]. The most
recognizable is Extreme Programming (XP). Others include Crystal, Scrum, Dynamic Systems
Development Method (DSDM), Adaptive Software Development, Test Driven Design (TDD),
2
All this detail seems unnecessary in the agile world and is representative of the complexity
of CMMI. There may be a grain of truth here, but very little if any of the Process Areas found
in CMMI are not applicable to any software development methodology. The problem comes
when the CMMI is used as a club to beat quality into an organization rather than as a
framework for improving the development processes – as it is designed to do.
3/14

and Xbreed, which is a mix of XP and Scrum. Background and supporting materials for agile
development methods can be found at the Agile Alliance web site www.agilealliance.org.
Extreme Programming and the CMMI
Extreme Programming (XP) is a good starting place for mapping agile development practices to
the CMMI’s process areas. Other agile processes could also be a starting point, but XP practices
provide a unique insight into the values and culture of agile development. XP makes use of the 13
practices shown in Table 2.3
Customer Practices Programming Practices Support Practices
Planning Game – predicts
what will be accomplished by
the due date
Simple Design – start with
simple code and through
testing keep it simple
Continuous Integration –
keeps system running at all
times
Small Releases – provides
code in very small sets of
functionality
Pair Programming – two
developers participate at one
work station
Coding Standards – follow
common coding standard
Whole Team – on site
customer, co–located with
the development team
Test Driven Development –
defines automated test first
to verify code
Collective Code Ownership –
any pair can improve any
code at any time
Customer Acceptance Test –
live tests on working code
Refactoring – removes
duplication, increases
cohesion, and lowers coupling
Sustainable Pace – maintain
a sustainable pace
Metaphor – guide
development with a simple
story of how the whole
system works
Table 2 — The 13 practices of Extreme Programming
INSTALLING AGILE IN A CMMI PROCESS
As stated before, there are two approaches to blending CMMI and Agile: start with CMMI or
start with agile. The former is the example described here. The latter seems difficult because of
the culture of agile development.
Table 3 describes the mapping between agile practices and CMMI process areas.
Legend
– XP match
– XP moderate match
– XP partial match
– XP provides little support
PlanningGame
SmallReleases
Metaphor
SimpleDesign
TestDriveDevelopment
Refactoring
CustomerAcceptance
PairProgramming
CollectiveCodeOwnership
ContinuousIntegration
SustainablePace
WholeTeam
CodingStandards
Causal Analysis And Resolution CAR
Organizational Innovation & Deployment OID
Quantitative Project Management QPM
Organizational Process Performance OPP
Decision Analysis And Resolution DAR
3
There are 12 practices defined in [Beck99]. The 13th
practice, “whole team” was
added in some descriptions of XP.
4/14

Legend
– XP match
– XP moderate match
– XP partial match
– XP provides little support
PlanningGame
SmallReleases
Metaphor
SimpleDesign
TestDriveDevelopment
Refactoring
CustomerAcceptance
PairProgramming
CollectiveCodeOwnership
ContinuousIntegration
SustainablePace
WholeTeam
CodingStandards
Risk Management PM
Integrated Project Management IPM
Organizational Training OT
Organizational Process Development OPD
Organizational Process Focus OPF
Validation VAL
Verification VER
Product Integration PI
Technical Solution TD
Requirements Development RD
Configuration Management CM
Process And Quality Assurance PQA
Measurement & Analysis M&A
Supplier Agreement Management SAM
Project Management and Control PMC
Project Planning PP
Requirements Management REQM
Table 3 — Mapping CMMI Process Areas to XP Practices
The First Stage Is Denial…
The process of installing agile development practices in a CMMI framework goes through several
emotional, cultural, and technical lifecycles:
1. Adding XP can’t be done simply because CMMI does not provide the means for an agile–
centric development process.
2. After some more thought and much hand waving, adding agile can be done because CMMI
does not describe the actual details of implementation.
3. Once over this hurdle, it turns out to be harder than it looks because the two distinct cultures
need to be brought together. Both cultures need to understand each other and search for join
points.
4. Then it becomes easier than it looks once the cultural aspects are overcome and the search for
process improvement and software quality are joined in both cultures.
5. Then it becomes hard again once the first major problem is encountered. The naysayers will
naturally say, “I told you not to do that.” The supporters will naturally say, “Give it a chance and
we’ll work out the kinks.”
The last two items (4) and (5) will repeat for some time until experience, consensus, and cultural
connections are reached about the benefits, risks, issues, and costs of incorporating agile in the
CMMI framework.
Critical Success Factors for Agile inside CMMI
The critical success factors for deploying agile process into a CMMI framework include:
5/14

• The CMMI processes need to be well understood, in place, and operational. Formal
assessment is not necessary, but the displacement of the CMMI culture is not the goal of the
agile introduction process.
• Agile development processes need to be well understood, in place, and operational in some
form. This doesn’t mean full XP or Scrum is being used but rather, XP–inspired processes
have some experience base with the team. Using Table 3, each XP–inspired practice needs to
find a specific home in a CMMI process area.
• Use the terminology of CMMI when joining the two cultures. Agile is the newly arrived
foreigner to the “new world” of CMMI so learning the native language is critical to rapidly
becoming integrated with the CMMI society, so the Lingua Franca should be CMMI.
• The development of macro–level schedules and budgets through delivery of working code
rather than Big Design Up front (BDUF) must be understood agreed to by management .
• The realization that the agile practices are found in any good development method. What is
significantly different is the frequency and granularity with which they are performed.
Practices of Agile on a CMMI Project
Having an understanding of what to do and doing it are two distinct things. The following
behaviors have allowed our Rocky Flats Information and Communication technology (ICT) team
to blend XP–inspired development processes inside a CMMI framework. Let’s look at the
Process Areas for Level 2 and see how agile processes fulfill their requirements. 4
One critical difference between an agile project and a CMMI–based project is the collection and
analysis of long–term data for process improvement. CMMI identifies several process areas that
are dedicated to collection and analysis. This would be considered unnecessary on an XP project.
Table 4 describes how agile methods can be used to fulfill [CMMI Practice Area]. This is a brief
description, since the details are beyond the space of this paper. The details for each agile method
be found in their respective texts: Adaptive Software Development [High01], Crystal [Cock02],
DSDM [Stap03], Extreme Programming [Beck99], Scrum [Schw01], Test Driven Development
[Beck02].
A Word of Caution
Before getting too enthusiastic about how easy it will be to blend CMMI and agile, [the items
described] in Table 4 are not only brief, they are a bare minimum effort to comply with CMMI.
This approach is “pure agile” since only the minimum needed to deliver the value is one of the
underlying axioms of any agile process. In fact more is needed to comply with the “intent” of
CMMI. This additional effort is almost always centered on documentation, formal training, and
the management of the process improvement process.
4
Starting with Level 2 is important. A critical understanding in CMMI is to not skip levels on
the way to some desired level. If levels are skipped, gaps appear in the supporting structure
for the next level up. Each Specific Practice (SP) for the Process Areas is described in detail
in [SEI02]. The reader should be familiar with the structure of the CMMI framework [to the
level of understanding] the Process Areas for Level 2 and the Specific Practices for each
Process Area. With this understanding the connection between agile and CMMI will be much
easier.
6/14

Connecting Agile to the CMMI Process Areas
Table 4 describes how an XP–inspired software development process can be integrated with a
CMMI Level 2 framework. 5
Level 2 CMMI
Process Area
XP–Inspired Agile Practices
(Summary of CMMI process area activities)
Requirements
Management
REQM
Manage requirements of product and identify inconsistencies
between those requirements and the plans and work products.
SP1.1: Requirements are managed through “story cards.”
SP1.2: Face–to–face communication confirms requirements.
SP1.3: Traceability provided through face–to–face communication.
Key Point
Unlike a traditional XP shop where old story cards are torn up and tossed, the
evolution of the requirements needs to be maintained as the requirements evolve
[Meke03]. This requirements configuration control is done through a version
numbering scheme. Here’s where electronic means help, since handling all the cards
and keeping the requirements straight manually does not scale well.
Project Planning
PP
Establish and maintain plans that define the project’s activities.
SP1.1: Project scope is established through the Planning Game.
SP1.2: Story cards are used to estimate the work products.
SP1.3: Rigorous steps are followed during each iteration.
SP1.4: Planning Game produces Estimates of effort and cost.
SP2.1: Schedules are established in the Planning Game.
SP2.2: Risk assessment is part of each XP practice.
SP2.3: The data management processes are outside XP.
Key Point
Total project budgets can be estimated, but agile processes are better suited for
emergent budgets. The solution is to establish a “not to exceed budget” and deliver
features within that value. History shows that budgets and end–to–end schedules for
software projects are notoriously wrong. Acceptance that agile methods develop this
information through feedback and delivery processes is a critical success factor.
[Boeh04]
Project
Monitoring
and Control
PMC
Understand the project’s progress so that appropriate corrective
actions can be taken in the presence of deviations.
SP1.1: Parameters monitored through continuous feedback.
SP1.2: Commitments monitored through daily standups.
SP1.3: Project risks are monitored through daily standups.
SP1.4: Data management monitored through external resources.
SP1.5: Stakeholder involvement monitored by direct conversations.
SP1.6: Progress reviews conducted at the end of each iteration.
SP1.7: Milestone reviews conducted at the end of each iteration.
SP2.1: Corrective actions are taken at the end of each iteration.
SP2.2: Reviews are used in Planning game for the next iteration.
SP2.3: Corrective actions managed by the collective team.
Key Point
One issue in an agile team is “What is the role of a project manager?” One answer is
5
It is assumed the reader has access to a CMMI reference. Each Process Area (PA), Specific
Practice (SP) can be referenced in the CMMI documentation.
7/14

that the project manager oversees the relationship between the customer, the
development team, and the supporting processes.
Supplier
Agreement
SAM
Manage acquisition of products from suppliers.
SP1.1: The acquisition process starts with an agile environment.
SP1.2: Suppliers selected by ability to adapt to the agile.
SP1.3: Agreements need to be informal as possible.
SP2.1: COTS products must have an agile capability as well.
SP2.2: The supplier agreements are not through paper contracts.
SP2.3: Acceptance testing identical to the internal products.
SP2.4: Products transitioned on iteration boundaries not “big bang”.
Key Point
A critical factor in supplier relationships is their ability to adapt to the agile paradigm.
A supplier wanting a firm fixed price contract or one wanting a “hands off”
relationship will not be a good partner in an agile development situation.
Measurement
and Analysis
M&A
Develop and sustain a measurement capability that is used to support
management information needs.
SP1.1: Stories delivered in code at the end of the iteration.
SP1.2: Measures defined in quantifiable terms.
SP1.3: The data collection in “big visible charts.”
Key Point
Measurement and analysis are provided through “big visible charts” hanging on the
wall in the development area. In an agile environment, pair programming and shared
development are common. The performance of the team is based on the completion
of the selected stories for an iteration. The critical success factor is to have the
development team tell the customer what can be done in an iteration rather than
have the deliverables specified by project management or some outside source.
Process and
Product
Quality
Assurance
PPQA
Provide staff and management with objective insight into processes
and associated work products.
SP1.1: Process objectively evaluated during the Planning Game.
SP1.2: Work products evaluated daily through 100% unit tests.
SP2.1: Noncompliance is communicated directly to customer.
SP2.2: Records of noncompliance are kept by the team.
Key Point
This is one problematic area for agile processes. Agile quality assurance processes are
powerful and flexible, but their document “footprint” is very low compared to more
formal practices.
Configuration
Management
CM
Establish and maintain the integrity of work products using
configuration identification, control, status accounting, and audits.
SP1.1: Configuration items are identified through unit tests.
SP1.2: CM system critical to success of agile development project.
SP1.3: Baselines performed daily in XP projects.
SP2.2: Change requests tracked through stories and task cards.
SP2.2: Agile depends on tight configuration control.
SP3.1: Configuration records takes place through the unit tests.
SP3.2: Configuration audits take place through the unit tests.
Key Point
Tracking change requests in a formal manner requires configuration control of story
and task cards. Having just the current cards is not sufficient. A historical file of
cards, their change history, and the “conversations” around the changes are also
8/14

needed.
Table 4 — Mapping agile processes to CMMI Level 2 Process Areas
Agile and CMMI Comparison
Agile and CMMI are philosophically compatible but still separated culturally and even more
separated in many practice areas. Inserting an agile development process into a CMMI framework
is often met with resistance. There is no guidance on how to do this or even how to talk about
doing this. Since the agile community is on the “outside looking in,” it falls on the CMMI
community to take the first steps [Reif03].
A simple comparison between CMMI and agile is provided in Table 5. This comparison is naïve,
of course, but it shows similarities as well as the significant differences to meeting the goal
delivering software on cost, on schedule, with high quality that meets the customer’s
requirements. [CSE02].
Agile CMMI
Core Values
Customer response drives change Measurements drive change
Participants are:
comfortable,
creative, and
risk takers
Participants are:
disciplined,
follow rules, and
risk averse
Communication is person to person at
the “micro” level
Communication is organizational at the
“macro” level
The management of knowledge is [held]
by the participants
The management of knowledge is [held]
by the process assets
Characteristics
Improvements take place within the
project initiated by the participants.
Improvements take place across the
organization initiated by the software
process improvement team.
Variance drives improvements. Low variance is sought
Process knowledge is personal, evolving,
and temporal.
Process knowledge is cross dimensional
and standardized.
Shortcutting of rules is encouraged. Shortcutting of rules is discouraged.
Management is by individuals. Management is by committees.
Trust with the customer is built by
delivering working software.
Trust with the customer is built by
adherence to the process infrastructure.
Test–driven design Front–loaded design
Small and directed at a [project focused
scope of view]
Broad, inclusive, and directed at an
[organization scope of view]
Level of discussion limited to the
problem at hand
Level of discussion based on words,
definition, enduring concepts, and
comprehensible paradigm
Approach
Descriptive
Qualitative
Situational
Product deliverables
Tactical
“Just do it”
Risk management: reactive
Prescriptive
Quantitative
Universality
Process activities
Strategic
“What do we call it?”
Risk management: proactive
9/14

Agile CMMI
Focus
Business focus
External
Innovative
Business focus
Internal
Rules based
Challenges
Scaling up Scaling down
Table 5 — Comparison between Agile and CMMI
Getting it to work
The approach of inserting agile into a CMMI framework may seem difficult at first. But there are
several “no brainer” processes and outcomes that must be understood from an agile as well as
CMMI point of view.
• 100% unit tested code is trusted code. Trusted code is configured to pass tests and configured
to provide functionality.
• Continuous feedback between the customer and the development team is the basis of trusted
schedules and requirements compliance assurance.
• A fully engaged team raises the level of quality, job fulfillment, and customer candor no
matter what the development process.
• Start small and avoid “big bang” for any change process.
• Treat process improvement as a project just like software development.
• Get customers involved at the same level of the developers.
Closing the Gaps
After all this technical and philosophical background, the issue of blending agile with CMMI
comes down to a simple concept. Kent Beck has a critical quote that cements Agile with CMMI:
“In software development, optimism is a disease; feedback is the cure.” CMMI strives to replace
the optimism in Kent Beck’s quote with measurement and analysis. 6
CMMI–based process improvement initiatives drive an organization toward repeatability of work
and data gathering, but they do not specify what the data looks like or how often it is gathered.
Agile processes specify the data needed to satisfy the process areas of CMMI. This data includes:
• Verification that 100% of the unit and functional tests pass on fine–grained sample intervals.
• On–site customers provide the “macro level” measure of functional compliance with needs of
the stakeholders.
• Viability of the schedule is determined through real project performance data. XP uses
velocity; agile projects in CMMI domains can use Earned Value.
The majority of software development projects are not conducted under conditions of rationality.
Software projects are not repetitive, stable, or linear. They are unique; driven by unstable
requirements, technology, and market forces; and contain many nonlinear activities. Software
development is complex, and the exact business and technical outcome is difficult to plan. The
6
This idea of data, control systems and project management in the CMMI context comes from
a near daily conversations with my colleague here at Rocky Flats – Martin Radley. Martin is a
contributor to Using Microsoft Project 2002, Tim Pyron editor, Que 2002. [ref]
10/14

processes used to manage the outcome may be chaotic. Software projects are often subjected to
forces outside the control of the project manager, developers, and stakeholders.
If CMMI and Agile processes are to be successfully “merged:”
• Customers must augment requirements specifications with their physical presence
• Feedback for quality, functionality, and team productivity is available on fine–grained
boundaries – days and weeks.
• Real project performance data replaces the optimism of management.
• Viability of the schedule is shared by the developers and the customer through continuous
integration, feedback, and performance measures.
When these processes are inserted into the CMMI Level 2 framework, agile development
processes become fully integrated and indistinguishable from the current CMMI–compliant
processes.
OUR LESSONS LEARNED
Mistakes (or lessons learned) are tuition costs on the way to knowledge. We have many lessons
learned that have improved our knowledge of deploying agile inside CMMI.
Our motivations for agile were well founded on previous use of XP and agile management, so we
were not novices, but we struggled with the political and organizational aspects. Several team
members came from prestigious XP shops in the Denver area. One senior member worked in this
shop as well as at a major aerospace firm where agile and earned value were used inside CMMI.
Other members had experience with agile methods in commercial and Web services firms. We
“talked the talk.” We had empowered teams, motivated management, and a clear sense that this
was going to work.
We were not prepared for the level of effort it takes to move an organization from “command and
control” to agile self–directed teams. Using the agile manifesto as a template, our difficulties are
summarized below.
Individuals and Interaction over Processes and Tools
Hanging on the wall in our primary work space is a “swim lane” chart of our CMMI Level 3
software process. It is 27 feet long and 4 feet high. This chart is our CMMI process map.
Moving the vocabulary from that chart to the vocabulary used in agile was very difficult. The
terms in XP were not only confusing, they were seen as obfuscating. Managers did not have a feel
for what the terms meant, how they were used, or even why we needed new terms to describe the
obvious.
Following a defined process was part of the air. We naïvely thought team building would be a
simple step toward agility. “We’ll have self–directed teams, we’ll have engaged customers, we’ll
do XP, and we’ll all move to a higher plane of existence!” It turns out installing self–directed
teams in a culture of “command and control” is very difficult. Allowing individuals to make
decisions that were previously made by functional and a line manager borders on insurrection.
“You simply can’t turn over the project to the team and the customer! Why, it’ll be chaos by the
first week.” And it was.
We had not prepared for the disruptive event [effect?] of removing the “command and control”
management structure had on the organization. As individuals, we had high expectations for
everyone. They’d become “self–actualized” to use Maslow’s term. What emerged was confusion
about being “self–directed.” Opinion ranged from autonomous decision making by the teams to
11/14

line managers thinking self–directed meant “come see me to confirm your direction.” Senior
management thought it meant “I don’t have to be concerned about the details, because you’re
self–directed now.”
It took several months to sort out how the teams were to interact with management, customers,
and internal audit functions. We had not planned for this, and our credibility as “change agents”
was damaged for not providing resources and training to move from our old “command and
control” to agile.
Working Software over Comprehensive Documentation
In our high–ceremony world, specifications are king. Replacing these specifications with working
software was a major cultural disruption.
Cards on the cubicle wall are not the same as walking through a 50 page document. The latter is a
linear process — reading the specification. The former is a multi–dimensional process where
someone with context and interpretation skills is needed to pull everything together.
We needed a “road map” to follow. This was provided by assembling the story cards to follow the
WBS of the master schedule. Encoding the cards with project WBS numbers was the solution.
Assigning effort in units of measure familiar to management – dollars and man hours. Velocity
was replaced with earned value to produce an accurate “estimate at completion” (EAC). 7
Customer Involvement over Contracts
Lack of customer commitment would be a likely problem, but in our case it was a lack of
developer commitment. The development team had too many projects on their plate and could not
dedicate their efforts to a single project.
There were to two false starts due to this lack of commitment. The solution was to move the
developers from our high rise building to the near by customer site, rather than have the
customers come to the development location. A trailer on the construction site was found where
customers and developers lived and worked on the project. Once this “forced” proximity was
created, the team jelled, and code started to appear that met the customer’s needs.
Responding to Change over Following a Plan
Change control and change management are core to CMMI. The formality of change
management is embedded in our culture is [of?] mission–critical systems development.
Introducing a “team based” change control process required embedding CM and SV&V staff on
the team. This staff was accustomed to receiving change packages through formal channels – the
Change Control Board (CCB).
We first attempted to keep the CCB and SV&V teams at the boundaries of the release cycles.
This created friction not from the XP team but from the CCB and SV&V team members. They
wanted to be “on the team” and operate inside the process. In the past they were in a hands–off
relationship, but now they wanted to be fully connected.
Finally, Success
Agile work processes can be installed in a CMMI framework if they can demonstrate:
7
The concepts of Earned Value Management can be easily found on the web. EV is used in
many industries. It has a “natural” connection to testable requirements and incremental and
iterative development.
12/14

• Agile practices exist independent of the team — in a “manual” — and are passed on to any
new members.
• Someone oversees the application of the agile “rules.”
• When the rules are not followed, there is an independent means to get the team back on track.
• The effectiveness of the rules and practices is measured in some way.
• The artifacts of the project are measured for quality, compliance with requirements, and
project performance.
• There is a means of adjusting the rules through some form of measurement.
• There is an independent assessment of the effectiveness of the agile process.
The search for “better” development methods is the goal of CMMI. Agile methods bring “faster”
and “cheaper” attributes to this search.
REFERENCES
[Ambl04] Ambler, Scott, “Answering the ‘Where is the Proof That Agile Methods Work’
Question,” www.agilemodeling.com, 2004.
[Beck99] Beck, Kent, eXterme Programming Explained, Addison Wesley, 1999.
[Beck02] Beck, Kent, Test Driven Development: By Example, Addison Wesley, 2002.
[Boeh04] Boehm, Barry, Windsor Brown, Victor Basili, and Richard Turner, “Spiral Acquisition
of Software–Intensive Systems of Systems,” CrossTalk, May 2004, pp. 4–9.
[Cock02] Cockburn, Alistair, Agile Software Development, Addison Wesley, 2001
[CMMI] Capability Maturity Model Integrated – Systems Engineering/Software,
www.sei.cmu.edu/cmmi/products/models.html
[CSE02] “Agile Methods and CMMI,” Annual research Review & Executive Workshop, Post
Workshop Progress Report, March 14, 2002
[Glaz01] Glazer, Hillel, “Dispelling the Process Myth: Having a Process Does Not Mean
Sacrificing Agility or Creativity,” CrossTalk, November 2001, pp. 27–30.
[Gold03] Goldenson, Dennis R. and Diane L. Gibson, “Demonstrating the Impact and Benefits of
CMMI®: An Update and Preliminary Results,” CMU/SEI–2003–SR–009, Software Engineering
Institute, October 2003.
[Herb94] Herbsleb, J., “Benefits of CMM–Based Software Process Improvement: Initial Results,”
CMU/SEI–94–TR–013, Software Engineering Institute, August 1994.
[High00] Highsmith, James A., Adaptive Software Development: A Collaborative Approach to
managing Complex Systems, Dorset House, 2000.
[Hump89] Humphrey, Watts S., Managing the Software Process, Addison Wesley, 1989.
[Kale02] Kalermo, Jonna and Jenni Rissanen, “Agile Software Development in Theory and
Practice,” Master’s Thesis, Software Business program, Department of Computer Science and
Information Systems, University of Jyväskulä, June 2002.
[Meke03] Mekelburg, Diana, “Project Expectations: The Boundaries of Agile Development,”
CrossTalk, April 2003, pp. 28–30.
[Moor02] Moore, Geoffrey, Crossing the Chasm, Harper Business, 2002.
13/14

[Pekk02] Abrahamsson, Pekka, Puti Salo, Jussi Ronkainen, and Juhani Warsta, “Agile Software
Development Methods,” VTT Publications 478, ESPOO 2002.
[Reif03] Reifer, Donald J., “XP and CMM,” IEEE Software, 20(3), pp. 14–15, 2003.
[Schw01] Schwaber, Ken and Mike Beedle, Agile Software Development with Scrum, Prentice
Hall, 2001
[SEI02] Capability Maturity Model Integration for Software Engineering, version 1.1, Staged
Representation, CMU/SEI–2002–TR–029, Carnegie Mellon, Software Engineering Institute,
2002.
[SEI04] Process Maturity Profile, CMMI V1.1, SCAMPI V1.1 Appraisal Results, 2003 Year End
Update, Software Engineering Institute, March 2004.
[Stap03] Stapleton, Jennifer, DSDM: Business Focused Development, Addison Wesley, 2003.
[STSC] “CMMI–SE/SW V1.1 to SW–CMM V1.1 Mapping,”
http://www.stsc.hill.af.mil/consulting/cmmi/cmmiseswippdv11.pdf.
Glen Alleman is Vice President of Program Management for CH2M HILL’s Communication
Group. CH2M HILL provides services to Rocky Flats Environmental Technology Site (RFETS) in
Golden, Colorado. Rocky Flats is a former nuclear weapons complex that is operated by the US
Department of Energy and is scheduled for closure by the end of 2006. Mr. Alleman’s office
provides project management services to the information and communications services groups at
RFETS. This involves program management, earned value management, portfolio management,
and direct involvement in over 300 software and infrastructure projects.
Before joining CH2M HILL, Mr. Alleman was the Principal Consultant for Niwot Ridge
Consulting, where he specialized in the management of enterprise application integration
projects for ERP, document management, and product data management systems in
manufacturing, petrochemicals, and electric utilities. Prior to his consulting work, Mr. Alleman
worked in a variety of aerospace and high–technology firms as a manager and technical
contributor. His education includes undergraduate and graduate work in physics at the
University of California as well as an MBA from the University of Southern California.
Mr. Alleman can be reached at CH2M HILL, Rocky Flats Environmental Technology Site, 10808
Highway 93, Unit B, Bldg. 060, MV72, Golden, CO 80502, USA. Tel: +1 303 966 5865; E–mail:
glen.alleman@rfets.gov.
14/14
View publication statsView publication stats

Blending Agile with CMMI®

More Related Content

What's hot

Similar to Blending Agile with CMMI®

More from Glen Alleman

Recently uploaded

Blending Agile with CMMI®