Professional Documents
Culture Documents
November 2008
TECHNICAL NOTE
CMU/SEI-2008-TN-003
The ideas and findings in this report should not be construed as an official DoD position. It is published in the
interest of scientific and technical information exchange.
This work is sponsored by the U.S. Department of Defense. The Software Engineering Institute is a federally
funded research and development center sponsored by the U.S. Department of Defense.
NO WARRANTY
Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark holder.
Internal use. Permission to reproduce this document and to prepare derivative works from this document for inter-
nal use is granted, provided the copyright and "No Warranty" statements are included with all reproductions and
derivative works.
External use. Requests for permission to reproduce this document or prepare derivative works of this document for
external and commercial use should be directed to permission@sei.cmu.edu.
This work was created in the performance of Federal Government Contract Number FA8721-05-C-0003 with
Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research
and development center. The Government of the United States has a royalty-free government-purpose license to
use, duplicate, or disclose the work, in whole or in part and in any manner, and to have or permit others to do so,
for government purposes pursuant to the copyright license under the clause at 252.227-7013.
For information about purchasing paper copies of SEI reports, please visit the publications section of our website
(http://www.sei.cmu.edu/publications/pubweb.html).
Table of Contents
Abstract iv
1 Problem Definition 1
8 Conclusion 29
References/Bibliography 38
The authors thank the following individuals for their significant contributions to this report: Mike
Phillips, Sabine Canditt, Noopur Davis, Bill Peterson, Mary Van Tyne, and Barbara White. We
greatly appreciate the insights and efforts of all of these individuals.
In addition, the authors would like to recognize those who attended Consultant’s Camp 2007. Ta-
ble 1 in Section 10 of this report builds on work done in a session at that event.
Agile development methods and CMMI (Capability Maturity Model® Integration) best practices
are often perceived to be at odds with each other. This report clarifies why the discord need not
exist and proposes that CMMI and Agile champions work toward deriving benefit from using
both and exploit synergies that have the potential to dramatically improve business performance.
iv | CMU/SEI-2008-TN-003
1 Problem Definition
Agile development methods and CMMI best practices are often perceived to be at odds with each
other. If these perceptions or their causes are not resolved, we are likely to see more confusion
and conflict as the adoption of each approach increases. In addition, each approach includes prin-
ciples of good software development often overlooked but needed by the other approach thus be-
ing knowledgeable in both is important to project success. In the long term, this discordant situa-
tion is not healthy for the software engineering profession.
Why the discord between Agile and CMMI camps? The purpose of this report is to clarify why
the discord need not exist and to ask for your help in making the software development communi-
ty aware that, when properly used together, CMMI and Agile can dramatically improve perfor-
mance.
We believe there are two primary reasons for the discord between the Agile and CMMI camps:
1. Early adopters of both CMMI and Agile methods represent extreme examples of their soft-
ware development paradigms. Early CMMI adopters were developers of large-scale, risk-
averse, mission-critical systems, often with high levels of management oversight and hierar-
chical governance; whereas the early adopters of Agile methods generally focused on small-
er, single-team development projects with volatile requirements in a software-only environ-
ment. These two extremes set the tone for all that followed.
2. The inaccurate information about CMMI and Agile and the misuse of both resulted in mis-
perceptions in both camps about the other. These negative perceptions that position CMMI
and Agile at odds with each other arose largely from the following factors:
a. Misuse—two decades of experience, first with the Capability Maturity Model (CMM®)
and then with CMMI models, in which practices were sometimes misused or applied to
(i.e., overlaid on) development activities that may have already been perceived by soft-
ware development teams as productive without them
b. Lack of Accurate Information—a dearth of accurate information about CMMI in the
Agile community and the corresponding dearth of accurate information about Agile me-
thods in the CMMI community
c. Terminology Difficulties—the use of terminology in CMMI (e.g., discipline, quality
assurance, and predictability) and Agile methods (e.g., continuous integration, test-
driven development, and collective code ownership) that carries context-specific conno-
tations and is thus easily misunderstood and abused
d. Top-Down Versus Bottom-Up Improvement Approach—the introduction of an ap-
proach that sometimes favors one “voice” (i.e., management versus practitioner) over
the other, which neglects the other important voice in how to effectively run the busi-
ness
1
We can’t speak for the Agile community given its diversity; but we feel that to some extent the same could be
said for Agile methods.
2
Example improvements include more attention to risk management, integrated teaming, and the work environ-
ment and less attention to starting with a fixed set of requirements and doing things “according to a documented
procedure.”
3
An incomplete draft of CMM version 2 that included some of these same improvements was created in 1997 but
was never formally released. Instead, it served as one of several sources for the initial draft of CMMI.
2 | CMU/SEI-2008-TN-003
2 Origins from Two Extremes
The perceived incompatibility of Agile methods and CMMI best practices can, in large part, be
attributed to their different origins. In this section, we describe the two extremes from which each
approach sprung: Agile from fast-moving markets consisting of small organizations and CMMI
from contractually-driven markets consisting of large organizations. These are generalizations,
but when you see the details about how each was created, you begin to see why they approach
software development from different perspectives.
4
This short history of Agile methods is provided for the benefit of those who might mistakenly believe that Agile
methods are a recent innovation without deep conceptual roots. For a complete history, there are books that
describe the events of the past seventy-five years that also contributed to the success of Agile methods.
5
By their nature, the parties to fixed-price contracts assume an unchanging project scope in unvarying develop-
ment and use environments. This nature makes it difficult to later modify project direction (without high-
ceremony activities) to take advantage of newly-discovered needs and constraints or new technologies.
4 | CMU/SEI-2008-TN-003
The Manifesto and Interdependence publications, books written by their original authors, the for-
mation of not-for-profit organizations to promote the Agile approach, and the widespread use of
the internet for research by software practitioners, has resulted in the rapid growth and broad
adoption of Agile methods throughout much of the software engineering profession. Some me-
thods, most notably Scrum, continue to grow beyond the software industry into professions that
desire the benefits provided by the same basic IIDD concepts first pioneered by Deming and his
predecessors.
6
This short history of CMMI focuses more on the past twenty years, but as in the case with Agile, the roots for
many of the product development, project management, and process concepts found in CMMI have a long his-
tory.
7
This definition of trust may be clearer but more elaborate: “the willingness of a party to be vulnerable to the
actions of another party based on the expectation that the other will perform a particular action important to the
trustor, irrespective of the ability to monitor or control that other party” [Mayer 1995]. For the purposes of this
report, the particular question being asked is whether there is a level of trust between the project and its cus-
tomer that will allow them to effectively negotiate scope as the project progresses, without the customer requir-
ing detailed accounts of project effort.
8
Two somewhat extreme examples of protecting one’s own interests include (1) a contractor that under bids,
hiding the real cost of the work to win the contract, then treating every change as an opportunity to reclaim
some of the investment; or, conversely (2) a government program manager who strongly encourages “cutting
corners” to meet aggressive cost targets, only to leave the resulting disaster-in-wait to fall on “the watch” of his
or her replacement.
9
When taken to an extreme, ceremonial dependence on plans, processes, and standards can replace common
sense, usurp accountability, and adherence to them can be used as an excuse for poor project performance
and poor product functionality.
10
In August 2006, CMMI for Development, Version 1.2 was released and in November 2007, CMMI for Acquisi-
tion was released. A third model covering service delivery is under development. Most of the comments in this
report apply to the first of these, CMMI for Development, as there has been less exposure to the newer models
in the CMMI family.
6 | CMU/SEI-2008-TN-003
3 Factors that Affect Perception
Perceptions that position CMMI and Agile at odds with each other largely arise from factors
present in the relatively more volatile commercial software development community. These fac-
tors may be generally attributed to market forces and human nature. We’ve described them as (1)
misuse, (2) lack of accurate information, and (3) terminology difficulties.
3.1 MISUSE
Whether analyzing the CMM or CMMI, there is one thing shared by both works that makes them
unique—they are models, not standards, for improving product quality and process performance.
However, for nearly two decades, the software industry has experienced the result of people mi-
susing appraisal ratings as entry criteria, confusing appraisal ratings for measures of business per-
formance, and misapplying a model as a standard in an environment in which products are created
to meet contractual requirements.
Used in this way, CMM and CMMI best practices were misinterpreted and misused. It is not an
exaggeration to say that any approach to improve an organization’s achievement of business ob-
jectives in such an environment would have difficulty overcoming an emphasis on RFP require-
ments and keen competition for multi-year contracts.
Does this situation mean that CMMI is wrong for software? Not in the least. It simply illuminates
the following reasons why some perceive CMMI to be incompatible with Agile ideals:
The context from which the CMM and CMMI originated was specific to a particular cus-
tomer base having unique challenges and characteristics of high risk and low trust.
The CMM and CMMI were a new paradigm introduced into a large (and dominant) industry
where paradigms, including the attitudes and beliefs associated with them, were in place for
many years (e.g., command and control).
Agile ideals developed as a backlash against the inefficient software development patterns
that arose in this industry.
These points describe the context in which the CMM and CMMI were developed. This context
enables us to understand some of the characteristics of the CMM and CMMI and how they have
been used over the past two decades. While the language of CMMI, admittedly, may retain some
of the flavor and phrasing of this context, each release of a CMMI model grows further away
from these roots to embrace a richer and more dynamic set of contexts11.
11
Users of older model versions may not fully make the transition as new versions are released, and older beliefs
and values may persist. Further, while CMMI and SCAMPI materials continue to evolve, it is simply not possible
to bring all users rapidly forward to the newer versions, government edicts and SEI encouragement notwith-
standing.
8 | CMU/SEI-2008-TN-003
Agile and CMMI have been available simultaneously since 2001, and while participation at con-
ference sessions has continued to grow in subject areas combining them, not before 2005 was
there a major presentation on the successful merging of the two concepts12 [Anderson 2005a]. It is
also worth noting that the Agile and CMMI communities don’t mix much. Few attendees of Agile
conferences also attend CMMI conferences and vice versa. Even more surprising, rarely do the
thought leaders in either community publish in the same sources.
Nonetheless, continuing research on the topic reveals that although momentum seems to be gain-
ing on the side of the successful merging of Agile and CMMI, it has yet to overtake (let alone ex-
tinguish) the existing perception that the two ideas are incompatible.
It may be worth addressing the demographics in the software development industry. How much of
the industry was Space and Defense in 1985? How much of it is Space and Defense today (meas-
ured by participation of the 15+ million software engineers worldwide)? Of those not in Space
and Defense, how many are so young that they never used a third generation language, such as C,
or worked on a true waterfall-style project? As a result of these demographics, a growing number
of members in our profession demonize traditional methods (which for some, CMMI symbolizes)
based on superstition or hearsay rather than experience.
We’ll return to the topic of available information in section 6.3, Current Published Research.
12
At the Agile conference in Denver in 2005, David Anderson recounted his experience developing Microsoft
Solutions Framework for CMMI Process Improvement as an Agile method compatible with CMMI maturity level
3.
13
In CMMI at maturity level 4, predictions are derived from an understanding of variation at the process-step level
combined with probabilistic or statistical models that predict the ranges in quality and process performance that
can be expected as project final or interim outcomes. For example, by investigating and characterizing the de-
fect injection and removal behavior of individual design, coding, and verification subprocesses as a function of
team skill and product complexity, and statistically modeling the relationship among these attributes and project
final or interim outcomes, a project can periodically evaluate whether it is still on track to achieving its quality
and process performance objectives. In a similar manner but by considering team velocity and the attributes af-
fecting team velocity, an Agile project can be “predictable,” even though the scope, schedule, and budget of the
project are changing and reacting to feedback and market conditions.
10 | CMU/SEI-2008-TN-003
4 The Truth About CMMI
In CMMI, process management is the central theme. It represents learning and honesty as demon-
strated through work according to a process. Process also enables transparency by communicating
how work should be done. Such transparency is within the project, among projects, and being
clear about expectations14. Also, measurement is part of process and product management and
provides the information needed to make decisions that guide product development.
However, if CMMI is used in the pursuit of maturity level numbers, the resulting process im-
provement efforts can sometimes lose sight of customer value, product, project value, and practic-
al business goals.
Also, when CMMI users establish (sets of) standard processes for use by the organization and its
projects, they sometimes fail to ensure that these processes are (1) successfully deployed to all
new projects; (2) periodically revised based on lessons learned from use; (3) compatible with in-
dividual and team practices and flexible enough for teams to adapt the processes to their needs
according to their experience; and (4) written using language and formalisms that practitioners
understand. The result can be rejection of the organization’s process improvement efforts by prac-
titioners.
There is a balance to achieve across organizational, project, and individual prerogatives and re-
sponsibilities that are a function of risk, task maturity, trust, and other business, fiduciary, and
cultural considerations. If the balance is weighted too heavily in favor of the organization,
projects and practitioners may lack the flexibility they need to be successful and motivation fails.
On the other hand, too much flexibility can expose the organization to excessive risk (e.g., from
mis-aligned teams) and missed opportunities for organizational learning that over the longer term
might lead to improved product quality and productivity. It is difficult to achieve the right bal-
ance.
14
In reality, CMMI and Agile share many of the same values.
12 | CMU/SEI-2008-TN-003
4.2 PROCESS AREAS, NOT PROCESSES
CMMI is comprised of goals and practices organized into process areas. To simplify this discus-
sion, no distinction is made between the types of goals or practices—suffice to say that each goal
is composed of several practices.
An example goal (SG 1) and practice (SP 1.2) from CMMI for Development, Version 1.2 reads as
follows:
SG 1 Establish Baselines
Baselines of identified work products are established.
15
Another way to express the need for informative material is that the value in a CMMI practice does not lie only
or even principally in the statement itself. Rather, the statement is a summary of a larger concept comprised of
activities or operations that will achieve a particular process area goal. To quote from the SEI website (i.e.,
http://www.sei.cmu.edu/cmmi/adoption/cmmi-informative.html), “[I]nformative material supports correct interpre-
tation and implementation of CMMI practices, but is neither required nor expected, nor is it to be used as part of
a checklist in an appraisal.” The informative material “takes on a critical role in explaining …the intent of the
practice, [and]… the practice’s dependencies with other parts of the model.” If the intent is met in some other
way or if the goal can be achieved through activities different from those specified in the CMMI practice state-
ments, then the CMMI model material associated with that practice or goal need not be further pursued from a
maturity rating standpoint. (Of course, it is possible that further process improvement is possible through further
consideration of informative material, but such pursuance must be weighed against higher priorities and better
opportunities for improvement to the business.)
14 | CMU/SEI-2008-TN-003
It is the job of an appraisal team, led by a lead appraiser, to discern the improvement activities of
the organization and to determine whether the practice implementation indicators16 objectively
indicate whether CMMI was implemented. It is how the above process story elements hold to-
gether that determine the outcome (often a rating) of the SCAMPI appraisal.
If an organization has been engaged in an effort to improve its processes, Agile or otherwise, the
SCAMPI method is used to ascertain which process area goals are being met. It then becomes
incumbent on the appraisal team to understand the context of the organization’s practices and the
relevance of their activities toward process improvement. In many cases, these activities—based
on the organization’s context—may not appear in a form or format familiar to those whose expe-
riences are limited to non-Agile development approaches. Nonetheless, it is the appraisal team’s
responsibility to interpret CMMI model practices and the organization’s artifacts of process im-
provement so that the appraisal team can correctly determine the overall process maturity and/or
capability profile of the organization being appraised.
Agile methods are not addressed specifically in either the model or the SCAMPI method because
Agile is a particular approach to development activities that contrasts with other approaches to
development. CMMI, not being a development approach, and SCAMPI, being agnostic on the
subject of development approaches, are not irrelevant or of no value because an organization
chooses to use Agile principles. An organization’s development approach is its choice.17
16
The fundamental idea of practice implementation indicators (PIIs) is that the conduct of an activity or the imple-
mentation of a practice results in “footprints” (i.e., evidence that provides a basis for verification of the activity or
practice implementation).
17
Likewise, the SEI has been asked over the years why CMMI does not promote specific methods, tools, or tech-
niques such as function points, RUP, or Six Sigma (or you name it). Again, by being a model that is imple-
mented as opposed to a standard process that is applied, CMMI, by its nature, must remain agnostic to such
selections, leaving the organization free to select the methods, techniques, and tools, most appropriate for its
use.
18
Agile teams and projects often assume low staff turnover (rightly or wrongly) because of the short nature of
projects and the small size of teams.
16 | CMU/SEI-2008-TN-003
the use of tools that can reverse engineer designs19 and other artifacts as well as conti-
nuously integrating code
the small size of the team.
Each increment potentially delivers value (e.g. working code). Value can also be what not to
do.
The delivered product is fully tested for each delivery. Products are often created by writing
rigorous tests first, then evolving the product to pass the tests.
Everyone owns quality, including the customer (or customer representative). Development
teams are often multi-disciplined, in which all developers are generalists and collectively
“own” the product. Customers are equally accountable to ensure the product meets their ex-
pectations. Products are prevented from advancing until a common understanding of the
product’s functionality, inclusions, and exclusions are established. There is a fail early atti-
tude with an underlying assumption that the cost of failure is low to negligible.
Detailed requirements are developed just in time and evolve along with the understood prod-
uct. Effort is not invested (i.e., wasted) by speculating on requirements or expectations. As
the product to be delivered evolves, the requirements become more and more detailed20.
Change is expected, embraced, welcomed, and/or accepted at any time. Acknowledged
sources of changes in traditional (i.e., serial) development are changes to requirements that
were baselined too early (from an Agile or Lean perspective). Furthermore, the expectation
of changes drives design decisions. By design, the product and architectural components are
not locked in so that developers can perform continuous trade-offs until all the component
requirements are available21.
Self-directed, empowered teams are used. Task-mature, well-trained, cohesive, high-trust,
small teams who take ownership of the product need little direction, management, or task-
feeding. Broad product, project, and business goals are shared with the team so that informed
managerial, organizational, and technical decisions can be made by the team to determine
what must be done, by when, by whom, and to what standards. Teams are allowed to re-
spond to current conditions rather than adhering to over-emphasized, over-detailed plans.
Thus, plans and planning are actually updated frequently and communication with superiors
(whether organizational or team) often takes place daily or nearly daily. Highly ceremonial
19
Again, there is a bias against documentation. People assume that documentation is complete and up to date,
which is often not the case. Without sustained effort over time to keep it up-to-date, it can become misinforma-
tion. Documentation is often a poor substitute for communication, especially for a co-located team.
20
There is a recent movement toward articulating this just-in-time requirements method through the use of Real
Options Theory. The key proponents are Chris Matts (from London), Olav Maassen (from Amsterdam), and
Kent McDonald (of the Agile Project Leadership Network, from Iowa).
21
Traditional assembly line production of code assumes a cost of change curve that accelerates with late discov-
ery. Hence, early discovery through analysis methods and inspections is desirable [Boehm 1976]. Some Agile
proponents (e.g., for eXtreme Programming) have argued that the cost of change rises quickly and asymptoti-
cally levels out [Beck 2000]. Actually, they are both often wrong assumptions—cost of change is contextual and
depends on where the capacity-constrained resources lie in the process flow [Anderson 2003]. Cockburn
showed that slack resources in development can be used to fix defects at no cost to productivity (i.e., through-
put) and hence, in some situations the cost of change in coding is as Beck suggested negligible [Cockburn
2006].
22
Some organizations, which are adopting both CMMI and Agile methods, characterize the situations that are
more suitable for the implementation of Agile methods according to the level of trust, customer/end user availa-
bility, project scope, scale, expected lifespan of the product, cost of delay, value of early (partial) delivery, and
cost of failure present in the situation.
18 | CMU/SEI-2008-TN-003
At regular intervals, the team reflects on how to become more effective, then tunes
and adjusts its behavior accordingly.‖
Each word in the Agile Manifesto and the guiding principles was attained via consensus—a
process familiar to anyone having been on a SCAMPI appraisal. Each word carries meaning. Note
the use of priority, most, primary, sustainable, excellence, and continuous. These are conditional
and qualifying words, not absolutes. Anyone who interprets these words as absolutes are misusing
Agile ideas just as they would if they were to interpret of CMMI’s typical work products as abso-
lutes.
CMMI and Agile are compatible. At the project level, CMMI focuses at a high level of abstrac-
tion on what projects do, not on what development methodology is used, while Agile methods
focus on how projects develop products. Therefore, CMMI and Agile methods can co-exist23.
There can be much value gained from Agile and CMMI synergies. Today, many CMMI-adopting
organizations have Agile development teams. Conversely, CMMI can be effectively introduced in
an Agile setting where an iterative, time-boxed approach is used, which is perfectly compatible
with CMMI.
CMMI and Agile can complement each other by creating synergies that benefit the organization
using them. Agile methods provide software development how-to’s that are missing from CMMI
best practices that work well—especially with small, co-located project teams. CMMI provides
the systems engineering practices that help enable an Agile approach on large projects. CMMI
also provides the process management and support practices that help deploy, sustain, and conti-
nuously improve the deployment of an Agile approach in any organization.
23
The references at the end of this report include publications and presentations that also characterize CMMI and
Agile as complementary and synergistic [Anderson 2005, Boehm 2003, Canditt 2008, Santos 2007, and Suther-
land 2007].
24
Of course, this is a challenge common to all large, complex projects.
20 | CMU/SEI-2008-TN-003
defining and maintaining interfaces and constraints among teams (for both the product and
the process)
maintaining effective product integration, verification, and validation strategies for the over-
all product (or service)
coordinating risk management across the project
These alignment and coordination activities, necessary in larger, complex projects, are described
in the systems engineering practices found in the Engineering, Risk Management, and Integrated
Project Management process areas of CMMI. Thus, CMMI provides a “safety net” for large
projects that helps reduce the risk of something going very wrong.
Some Agile proponents acknowledge that many Agile methods have yet to be proven effective or
possible as the core product development process on large projects25. However, there has also
been increasing success scaling Agile approaches for use on large projects by introducing a top
layer of coordination (e.g., a Scrum of Scrums) and by providing explicit and early attention to
non-functional requirements and product architecture26. Alternatively, Agile methods are also in
use on features or components of larger systems in which the Agile team is, in effect, isolated
from the rest of the product development team. The software development community is increa-
singly learning how current Agile methods can be effectively extended to work on large-scale,
complex projects.
Agile methods generally lack practices and guidance for implementing and supporting an Agile
approach across the organization. While some larger companies (e.g., CapitalOne, BMC Soft-
ware, and Yahoo!) are pursuing large-scale enterprise adoption of Agile, the level of documenta-
tion and implementation guidance available to support such adoption is relatively modest27. Agile
implementations will not “stick” or improve without an organizational context that supports
process definition, measurement, feedback, training, and improvement—mechanisms that are de-
scribed in CMMI. CMMI practices also address institutionalizing and improving deployed
processes, be they Agile or not; therefore, CMMI supports a long-term view of process adaptation
and improvement across the enterprise as a whole.
Of course, many organizations have identified and implemented project management, software
development, and process improvement practices without the benefit of CMMI. The book Micro-
soft Secrets discusses Microsoft’s seven-year journey to improve its product quality [Cusumano
1995].
25
A lot depends on the definition of large and which Agile method is being used. The first FDD project (1997-
1999) was characterized by 50 people, 18 months, and 1.5 million lines of Java. Two years later, Jeff DeLuca
led a 250 person project in New Zealand. Hence, there is relatively early literature and evidence that Agile tech-
niques can scale up [Highsmith 2002].
26
A continuing challenge experienced in many Agile implementations is ensuring adequate and early attention to
non-functional requirements and product architecture [Cao 2008]. Practices that address this challenge are
found in the Engineering process areas of CMMI. Relative to its own Agile approach, the SEI is currently colla-
borating with NAVAIR on extending the Team Software Process SM (TSPSM) to address systems engineering and
is also experiencing promising results from doing so [Carleton 2006, SEI 2008d].
27
A notable exception is [Schwaber 2006], which provides guidance and case studies on how to introduce
SCRUM to an enterprise; but may have applicability to other Agile approaches and to large projects as well.
28
We use the word “dexterity” in this sentence because we are trying to use a term other than "agility."
22 | CMU/SEI-2008-TN-003
6.3 CURRENT PUBLISHED RESEARCH
There is a large and growing body of research on the adoption of CMMI [Elm 2007]. As was the
case in the early days of CMMI (e.g., [Goldenson 2003]), the nature of the published research on
the efficacy of Agile methods is largely anecdotal. Also similar to CMMI, there is no one way to
use Agile methods. As already mentioned, CMMI addresses the what. Therefore, the studies of
the costs and benefits experienced by organizations using CMMI actually report on how those
organizations implemented a set of processes to meet the requirements and expectations set forth
in selected CMMI process areas and not on the effectiveness of individual CMMI practices per se.
Likewise, there are multiple ways to implement Agile methods. Because the methods offer some-
what different how-to’s, some methods clearly work better in some situations than others. Well-
intentioned implementations of Agile methods can fail to deliver a good product and uphold the
people-centric values held dear by Agile and CMMI champions alike. In a case study written by
Khaled El Emam, the employee morale at one organization actually became worse following the
introduction of Agile methods until more explicit attention was given to addressing selected
CMMI process areas [Chrissis 2007].
Many are too quick to pass judgment, declare victory, or declare failure. They expect instant re-
sults and often assume that those results will persist ad infinitum. The first project using Agile or
CMMI has to be a success or the newly tried approach is labeled a failure; equally, one success is
assumed to represent an organization-level, institutionalized pattern. The reality is that neither is
generally the case. There are few case studies in which the organization still exhibits the same
success a few years later after the environment, projects, personnel, and management have
changed.
While formal studies of impact and benefits have been clearly solicited from and by the Agile
community, there has been less energy behind systematic attempts to examine impacts (both suc-
cesses and failures) that result from introducing Agile methods. It will take years to understand
the efficacy of individual methods and the contexts in which there is high return on investment.
The same understanding has taken years for CMMI and that journey continues.
The problem with some of the existing research for both CMMI and Agile methods (or of new
technologies in general) is that success stories are more likely to be reported at conferences than
are failures and that research or reports based on such samples of convenience are therefore likely
to be favorably biased.
Furthermore, it is easier to claim success than to attribute success to specific, discrete practices
separate from other environmental factors such as team composition, organizational culture, and
customer interfaces29. Much like the adage, “It is impossible to prove a negative,” project failure
can happen for many more reasons than those controllable by a project. Conversely, a project can
claim that it did nothing more than change some practices or introduce some methods and thereby
justify its claims that what it changed or introduced is the source of its success. In either case, the
proof is not robust; therefore, most such research should be considered anecdotal.
29
Elm 2007 may be a notable exception. By design this recent research study targeted a broader range of pro-
grams (including less successful programs) and tried to account for challenges in the program environment. An
important finding of this study was that while higher process capability (or maturity) results in markedly better
project performance, project challenge (i.e., technical, stakeholder and contract complexity; requirements,
scope, and funding volatility) lessens the benefits of higher capability.
30
Gary Wolf of Raytheon recounted, “When we first heard our organization had to get to maturity level 3, we were
filled with negative feelings. Change is painful unless you are stuck in a fire. But if we had to improve our
processes, we were resolved to do it the right way. After several months, somewhat to our surprise, life got bet-
ter in the projects: there was less rework, fewer late nights, and more time for the right kind of work.”
24 | CMU/SEI-2008-TN-003
What is needed when using CMMI are standard processes (or sets of standard processes) that rec-
ognize the broader spectrum of situations that may arise and that provide process solutions that
collectively address all relevant project situations31.
Were DeMarco and Lister in their 1999 book Peopleware: Productive Projects and Teams [De-
Marco 1999] correct in asserting that high maturity organizations (in the era of CMM use) be-
come conservative and risk averse? It requires a broadminded attitude in regards to the software
engineering process to enable Agile method adoption. In general, Agile values align with a culture
in which anyone can suggest a change (i.e., improvement) and there is less attachment to the sta-
tus quo or established way of doing things. For example, some organizations place tremendous
emphasis on level ratings and are loath to change anything perceived to challenge appraised
processes upon which their ratings were based.
Barry Boehm and Rich Turner describe the need for hybrid approaches that combine and balance
strengths from both plan-driven and Agile approaches based on a risk assessment of a particular
project’s characteristics (e.g., high risk of failure vs. an overwhelming need for speed to market)
[Boehm 2002, Boehm 2003].
In his foreword to Boehm 2003, Alistair Cockburn (founder of the Crystal family of methodolo-
gies [Cockburn 2004]) provides this summary of the book’s message, “If one has strong discipline
without agility, the result is bureaucracy and stagnation. Agility without discipline is the unen-
cumbered enthusiasm of a startup company before it has to turn a profit32.”
We largely agree with these messages, but pragmatically it is difficult to know how much plan-
ning and architecting (and related development activities) are needed to minimize project risk ex-
posure; the answer would seem to be situation dependent. Add subsequent product evolution (and
attendant product releases and associated stakeholder costs) and it would seem some significant
discipline (in the sense of self-control) and experimentation is needed to properly assess which
hybrid approaches work in which contexts and to generalize to software-related industries as a
whole.
We hope this report encourages both CMMI and Agile proponents (ideally, everyone in software-
related industries) to do the following:
1. Recognize the value of each paradigm.
2. Resist common misperceptions.
3. Continue experimenting, learning, and reporting on what works and in which contexts.
31
There is also a need for more explicit coverage of Agile approaches within CMMI itself and in the guidance
provided within CMMI training and for appraisal purposes. In particular, SCAMPI Lead Appraisers need to have
a more versatile understanding and appreciation for Agile approaches, what they are, and how they can benefit
the organization. This report can be considered a step in that direction.
32
Unfortunately, Balancing Agility and Discipline: A Guide for the Perplexed [Boehm 2003] is a misleading choice
for a book title. The choice is not Agile or discipline because how can you continuously produce tested, working
software in short time intervals without discipline? Perhaps a more accurate title might be Balancing Agile and
Plan-Driven Approaches. CMMI can be used to address the full spectrum, with the risk assessment of a
project’s characteristics described in [Boehm 2003] being the basis for creating the project’s defined process
through appropriate process tailoring.
26 | CMU/SEI-2008-TN-003
7 Problems Not Solved by CMMI nor Agile
Part One of each CMMI model describes three aspects of development projects as (1) processes,
(2) technology, and (3) people. CMMI makes no secret that it focuses on processes. Meanwhile,
Agile methods clearly focus on people and allow people to determine technology and processes.
Regardless of the focus of CMMI or Agile, neither can entirely prevent simple human error, de-
parture of key personnel, impact of incompetent personnel, active or passive insubordination, or
deliberate sabotage. Neither can prevent the effect of an employee’s personal life on his or her job
performance. Each body of knowledge can have mechanisms to catch and manage such matters33,
but neither can prevent them any more than either can prevent the local economy from creating a
scarcity of qualified employees.
Most organizations have experienced ill-fitting employees and the corresponding challenges in
placing them or keeping them employed or happy. Most organizations have had to deal with em-
ployee losses, loss of project funding, evaporation of technology resources or suppliers, supply
and demand in the marketplace, premature obsolescence of core architectural components, and
other issues beyond their immediate control.
While derived and adapted abilities can positively influence the non-development aspects of
product and service development, there are many aspects to development that neither CMMI nor
Agile, as a first tier implementation, are meant to affect. The conclusion here is that neither
CMMI nor Agile are panaceas to all that may hinder development.
To address the issue of how to most effectively recognize and credit Agile approaches within a
SCAMPI appraisal bears further research. Perhaps simply a special guidebook for appraising
Agile organizational units or projects or a set of Agile alternative practices associated with CMMI
goals accompanied by an overview of Agile values and practices would prove useful.
Fundamentally, misuse is a problem for both CMMI and Agile. One of the original signatories of
the Agile Manifesto recently wrote that he was hired to perform due diligence by a venture capital
firm that had decided to invest only in companies practicing Agile methods. He found that of the
companies he visited and examined, only three percent of those claiming to use Agile methods
were actually doing so. (Whether another signatory would judge a similar percent is of course a
different, though related issue.)
33
Such workforce-management problems may be better addressed by the People CMM [Curtis 2001], which con-
tains practices for improving the selection, retention, training, motivation, alignment, and skills of an organiza-
tion’s personnel.
34
For articles about these kinds of situations, see
www.Agilemanagement.net/Articles/Weblog/ThoughtsonEnterpriseAgile.html
28 | CMU/SEI-2008-TN-003
8 Conclusion
Agile methods provide software development how-to’s, purposely absent from CMMI, which
work well on small co-located projects. Meanwhile, CMMI provides the systems engineering
practices often required on large, high-risk projects. CMMI also provides the process management
and support practices (and principles) that help deploy and continuously improve the deployment
of Agile methods in an organization regardless of organization or project size.
A scaling limitation of several Agile methods has yet to be overcome with any consistency while
still adhering to Agile principles. Adhering to Agile principles is inherently challenging given the
context of large, long-term projects with geographically and organizationally dispersed project
teams (a situation whose prevalence may be increasing). The mode of communication on large
projects—in terms of spanning distance, time, and audiences—is necessarily a slower more in-
volved endeavor than is possible with face-to-face, real-time, kinetic presence among project team
members.
Scrum provides an Agile “wrapper” for many project entities that allows for “Scrums of Scrums.”
However, this approach still requires a strongly cohesive project team and can even wrap around
non-Agile projects, thus begging the question as to the true agility of any project work being per-
formed behind a “curtain” of an Agile-recognized approach.35
Although the complexities of large-scale projects require a more involved infrastructure, this fact
is not a license to create unnecessary bureaucracies and unbalanced production at the expense of
productivity. This creation of unnecessary bureaucracy occurs especially, but is not limited to,
when CMMI is misused and a level rating is the principal expected outcome of a CMMI-based
process improvement effort. As a result, over-engineering within process improvement activities
is a common issue.
Using process experts to create and deploy process improvement activities is not unusual, and
often has the advantage of allowing these experts (and the project teams) to focus on their respec-
tive tasks. But what makes this approach risky is that project personnel are frequently left out of
process design activities36 and are disinclined or openly skeptical toward the adoption of process
improvement activities. This situation is typical of some Six Sigma style approaches to process
improvement as well. Quality process teams are created and given the responsibility for quality.
As a result, developers abdicate their responsibility for improvement (or worse, for quality).
35
Some Agilistas question the inclusion of Scrum as an Agile development method as opposed to, perhaps, an
Agile project management method. However, we have included it here because of its widespread recognition.
36
Whether due to the design of process improvement activities or due to project personnel being too busy to pro-
vide meaningful inputs, each has the same negative effect.
30 | CMU/SEI-2008-TN-003
9 Epilogue: A Call to Action
As authors and contributors to this report, we represent both sides of the perceived dichotomy and
have deep experience in both camps, yet we universally agree that Agile methods and CMMI
cannot only co-exist, but successfully integrate to bring substantial benefits to both Agile and tra-
ditional software development organizations. In these closing paragraphs, we issue a “Call to Ac-
tion” to experts of each approach.
37
A change request has been submitted asking the CMMI Product Team to include coverage of Agile principles
and approaches, as appropriate, in CMMI models and in CMMI and SCAMPI training; and in its CMMI qualifica-
tion, certification, and Partner program selection processes. (CRs are submitted as explained at
http://www.sei.cmu.edu/cmmi/models/change-requests.html.)
38
Agile methods now in use include Scrum, XP, FDD, and the SEI’s TSP.
32 | CMU/SEI-2008-TN-003
However, much of the informative material is steeped in the language of traditional systems de-
velopment. As new informative material is added to the model in subsequent releases of CMMI,
the CMMI Product Team will improve the communication and guidance provided by ensuring
that the new informative material includes work products, elaborations, subpractices, and amplifi-
cations illustrative of and compatible with Agile values and principles.
34 | CMU/SEI-2008-TN-003
10 CMMI and Agile Paradigm Comparison
The following table compares and contrasts the CMMI and Agile paradigms along multiple di-
mensions. This table provides a nice summary of concepts in a way that makes it easier to under-
stand the viewpoints of both CMMI and Agile.
Table 1: CMMI and Agile Paradigm Comparison
Dimension CMMI Paradigm Agile Paradigm
Organizational focus of The focus is on the organization or enter- The focus is on the project and team. Agile
attention prise. Most benefit occurs when CMMI is methods can isolate (i.e., insulate) the
implemented at organizational level so that project/team from the organization and still
all functions and capabilities contributing to be effective.
the development of products and services
are addressed by the process improve-
ment effort.
Trust Some CMMI practices assume the need Agile methods originated from the recogni-
to compensate for a low-trust environment tion that teams work best when they are
(a key concern of the Agilistas). A low- composed of task-mature individuals oper-
trust environment is often characterized ating in high trust groups. An Agile envi-
by (1) safety and mission critical objec- ronment fosters high trust.
tives, (2) high risk of failure, and most of
all (3) multiple stakeholders who cannot
be totally transparent relative to their in-
tensions and commitments.
Planning CMMI promotes macro (project-level) In Agile methods, there are multiple levels
planning with an emphasis on establishing of planning, including high-level product
a suitable defined process enabling the planning (including release planning) and at
project to achieve its objectives. the beginning of each iteration, more de-
tailed planning around the features to be
Traditional planning approaches assume a
long time horizon. Detailed plans are not addressed in that iteration. There is a
required by CMMI but many of the exam- strong emphasis on flexibility and replan-
ples encourage such an interpretation. ning as conditions change.
Nevertheless, many who use CMMI also Use of Gantt charts (that map tasks to ca-
use “rolling plans” (detailed only to the next lendar time) and graphs of task networks is
iteration or quarter). There is emphasis on discouraged because the requirements on
replanning and conditional change. which the tasks are based change fre-
quently.
Design Presumptions CMMI presumes the product architecture is Projects are most successful when corpo-
selected or created in the early stages of a rate standard architectures are adopted
project and is revisited when it becomes with flexibility applied as the project
clear the selected architecture is no longer progresses. Some Agile methods downplay
valid or when using an iterative lifecycle. the importance of architectures on the gen-
eral principle that such are often prema-
turely specified.
Learning Learning happens in many ways, including: Learning happens at project/iteration levels,
(1) organizational training based on ana- typically bottom-up and just-in-time (i.e.,
lyses of process and skill needs and priori- comparable to Kaizen).
ties and the design of appropriate training
vehicles; (2) through the development
activities of the project itself (e.g., the eval-
uation of proposed product requirements
and solutions for feasibility and cost, sche-
dule, quality, and risk impact); (3) through
the planning and use of the processes on
projects, measurements, and lessons
learned are gathered and shared across
the organization; (4) as part of a causal
analysis process; and (5) through an anal-
ysis of how well the organization’s and
project’s quality and process performance
objectives are being met by the processes
in use.
Perspective CMMI takes, has, and assumes a longer- Agile takes, has, and assumes a short to
term view. medium-term view.
Appraisals The SCAMPI method compares the organ- The desire of Agile practitioners is that
ization’s processes against the practices of appraisals are made only by looking at
CMMI to evaluate whether the organization results (i.e., customer satisfaction and other
has implemented processes that achieve project outcomes).
CMMI goals.
Human Development CMMI has a limited people focus at the Agile has a team and individual focus (i.e.,
project level. There is an expanded people people over process).
focus at the organizational level. CMMI There has been a tendency among many in
does not advocate heroics, but instead the Agile community to advocate “just hire
creating an environment in which people
good people” with an implicit undercurrent
can excel without heroics (i.e., an effective of developing “hero developers” within a
process appropriately leverages people
work-life balanced culture.
and technology).
36 | CMU/SEI-2008-TN-003
Life-Cycle Emphasis CMMI has a strong “review-as-you- Agile methods employ concurrent devel-
develop” emphasis. There is also a ten- opment, test iterations, and informal peer
dency to read in CMMI the approach “veri- reviews of work products as necessary.
fy often and validate at the end,” which is There is a tendency to see in Agile a “vali-
NOT the correct way to understand what
date often and verify second approach”
CMMI is saying (e.g., see the introductory
which may be a more correct reading.
notes to the Validation process area).39
“Fail early, fail fast, and learn” are central to
CMMI is consistent with an environment in Agile methods. The trade-off is seen as
which there is a high cost of failure (see
favoring the development of a useable and
Trust above). The objective is to proactive- testable product vs. developing and analyz-
ly avoid the high costs associated with
ing requirements and product components.
product failure (or time-to-market failure).
The conclusion is that we cannot rely on A low cost of delay or low cost of failure is
testing alone. Therefore, CMMI encourag- assumed. There is an assumption of in-
es documentation, analyses, and reviews cremental delivery being viable.
before product components are integrated Burn out can arise from repeated time-
into a functional product. CMMI also en- boxed iterations, so special provisions
courages frequent (early and mid-course) should be made for this eventuality (e.g., by
validations to ensure the right product is revising the time-box duration based on
being built. The project determines the experience feedback and by providing
appropriate application and timing of these some slack around iterations).
review and testing steps.
Predictability Predictability is achieved for critical sub- Using time-boxed scope-limited iterations,
processes (those process steps that are evolving designs/solutions, driving out de-
leading contributors to or indicators of fects as early as possible, and failing quick-
quality and process performance) through ly leads toward a predictable development
statistical management (which involves, velocity.
among other things, use of control charts). There is also an expectation of predictabili-
Predictability is achieved at the project,
ty of iteration delivery and scope of deli-
iteration, or level by monitoring the perfor- very. The anecdotal evidence suggests that
mance of critical subprocesses and period- Agile teams often struggle with predictabili-
ically using the organization’s established
ty of iteration scope, often de-scoping itera-
process performance models, appropriate- tions (or sprints) in the final few days. This
ly calibrated, to evaluate whether the de-scoping is rooted in a lack of statistical
project is on track to achieving its objec-
convergence of the velocity data combined
tives. Finally, at the organizational level, with the analysis technique underlying the
analysis of subprocess performance
scope breakdown.
across projects provides an increased
understanding of the capability of the or-
ganization’s processes and thus of which
areas to target for innovation.
Cost of Failure Historically, CMMI was developed in a Agile methods have flourished in a domain
domain of high cost of failure. If a plane of low cost of failure or linear incremental
crashes, the cost of failure is extremely cost of failure. Examples within this domain
high. Examples within this domain include include Internet commerce, social network-
the development of aircraft, weaponry, ing, and games development.
spacecraft and safety-critical medical de-
vices.
39
Verification confirms that the product meets its specifications; validation ensures it meets the needs of the user
in the end-use environment.
[Anderson 2004]
David Anderson. Agile Management for Software Engineering: Applying the Theory of Con-
straints for Business Results. Upper Saddle River, NJ: Prentice Hall Professional Technical
Reference (ISBN: 0131424602).
[Anderson 2005a]
David Anderson. “Stretching Agile to Fit CMMI Level 3: The Story of Creating MSF for
CMMI Process Improvement at Microsoft Corporation.” Agile Conference. Denver, CO,
2005. http://ieeexplore.ieee.org/iel5/10705/33795/01609821.pdf
[Anderson 2005b]
David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug
DeCarlo, Donna Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent
McDonald, Pollyanna Pixton, Preston Smith, & Robert Wysocki. The Declaration of Interde-
pendence. 2005. http://www.pmdoi.org/
[Anderson 2008]
David Anderson. David Anderson’s Website and Blog, AgileManagement.net, 2008.
http://www.Agilemanagement.net
[Boehm 1976]
Barry Boehm. “Software Engineering.” IEEE Transactions on Computers, December 1976.
[Boehm 2002]
Barry Boehm. “Get Ready for Agile Methods, with Care.” IEEE Computer, January 2002.
[Boehm 2003]
Barry Boehm & Richard Turner. Balancing Agility and Discipline: A Guide for the Perplexed.
Boston, MA: Addison-Wesley (ISBN: 0321186125).
[Canditt 2008]
Sabine Canditt & Winfried Russwurm. The First CMMI-Based Appraisal in an Agile Envi-
ronment at Siemens AG. SEPG North America, 2008.
http://www.sei.cmu.edu/cmmi/adoption/pdf/Canditt08.pdf
[Cao 2008]
Cao, Lan and Ramesh, Balasubramaniam. "Agile Requirements Engineering Practices: An
Empirical Study." IEEE Software, January/February 2008.
[Carleton 2006]
Anita D. Carleton & Tim Chick. “Extending the Team Software Process for Systems Engi-
neering.” TSP Symposium. Long Beach, CA, 2006. http://www.sei.cmu.edu/tsp/sym2006-
presentations/extendtsp.pdf
38 | CMU/SEI-2008-TN-003
[Charette 2004]
Dr. Robert Charette, Laura M. Dwinnell, & John McGarry. “Understanding the Roots of
Process Performance Failure.” CrossTalk: The Journal of Defense Software Engineering, Au-
gust 2004.
[Chrissis 2007]
Mary Beth Chrissis, Mike Konrad, & Sandy Shrum. CMMI: Guidelines for Process Integra-
tion and Product Improvement, 2nd Edition. Boston, MA: Addison-Wesley (ISBN:
0321279670)
[Cockburn 2004]
Alistair Cockburn. Crystal Clear: A Human-Powered Methodology for Small Teams. Boston,
MA: Addison-Wesley (ISBN: 0201699478).
[Cusumano 1995]
Michael A. Cusumano & Richard W. Selby. Microsoft Secrets: How the World's Most Power-
ful Software Company Creates Technology, Shapes Markets, and Manages People. New York,
NY: Free Press (ISBN: 0028740483).
[Dalton 2008]
Dalton, Jeff. Jeff Dalton’s Blog: Ask The CMMI Appraiser, 2008.
http://askthecmmiappraiser.blogspot.com/
[DeMarco 1999]
Tom DeMarco & Timothy Lister. Peopleware: Productive Projects and Teams, 2nd Edition.
New York, NY: Dorset House Publishing Company, Inc. (ISBN: 0932633439).
[Elm 2007]
Joseph P. Elm, Dennis R. Goldenson, Khaled El Emam, Nicole Donatelli, & Angelica Neisa.
A Survey of Systems Engineering Effectiveness: Initial Results. (CMU/SEI-2007-SR-014).
Software Engineering Institute, Carnegie Mellon University, 2007.
http://www.sei.cmu.edu/publications/documents/07.reports/07sr014.html
[Fukuyama 1995]
Francis Fukuyama. Trust: The Social Virtues and the Creation of Prosperity. New York, NY:
Free Press (ISBN: 0684825252).
[Glazer 2001]
Hillel Glazer. “Dispelling the Process Myth: Having a Process Does Not Mean Sacrificing
Agility or Creativity.” CrossTalk: The Journal of Defense Software Engineering, November
2001.
[Glazer 2008]
Hillel Glazer. Hillel Glazer’s Blog, Agile CMMI Blog. 2008. http://www.agilecmmi.com/
[Goldenson 2003]
Dennis R. Goldenson & Diane L. Gibson. Demonstrating the Impact and Benefits of CMMI:
An Update and Preliminary Results. (CMU/SEI-2003-SR-009). Software Engineering Insti-
[Highsmith 2002]
James A. Highsmith. Agile Software Development Ecosystems. Boston, MA: Addison-Wesley
(ISBN: 0201760436).
[Immelman 2003]
Ray Immelman. Great Boss, Dead Boss. Gurnee, IL: Steward Philip International (ISBN:
0974036919).
[Konrad 2005]
Mike Konrad & James W. Over. “Agile CMMI No Oxymoron.” Dr. Dobb's Portal: The
World of Software Development, March 2005.
[Larman 2003]
Craig Larman & Victor R. Basili. “Iterative and Incremental Development: A Brief History.”
Computer, June 2003.
[Levine 2005]
Linda Levine. “Reflections on Software Agility and Agile Methods: Challenges, Dilemmas,
and the Way Ahead.” 2005. http://www.sei.cmu.edu/programs/acquisition-
support/presentations/reflections.pdf
[Mayer 1995]
R. C. Mayer, J. H. Davis, & F. D. Schoorman. “An Integrative Model of Organizational
Trust.” Academy of Management Review. July, 1995.
[Paulk 2001]
Mark Paulk. “Extreme Programming from a CMM Perspective.” IEEE Software, Novem-
ber/December 2001.
[Santos 2007]
Pablo Santos. “SCRUM Meets CMMi: Agility and Discipline Combined.” Dr. Dobb's Portal:
The World of Software Development, August 2007.
[Schwaber 2001]
Ken Schwaber & Mike Beedle. Agile Software Development with SCRUM. Upper Saddle
River, NJ: Prentice Hall (ISBN: 0130676349).
[Schwaber 2006]
Ken Schwaber. The Enterprise and SCRUM. Redmond, WA: Microsoft Press (ISBN:
0735623376).
[SEI 2008a]
Software Engineering Institute. SEI Website: CMMI, 2008. http://www.sei.cmu.edu/cmmi
[SEI 2008b]
Software Engineering Institute. SEI Website: CMMI Performance Results, 2008.
http://www.sei.cmu.edu/cmmi/results.html
40 | CMU/SEI-2008-TN-003
[SEI 2008c]
Software Engineering Institute. SEI Website: Improving Processes in Small Settings, 2008.
http://www.sei.cmu.edu/iprc/ipss.html
[SEI 2008d]
Software Engineering Institute. SEI Website: Team Software Process (TSP), 2008.
http://www.sei.cmu.edu/tsp
[SEI 2008e]
Software Engineering Institute. CMMI Website, 2008, http://www.sei.cmu.edu
[Sutherland 2007]
Jeff Sutherland, Carsten Ruseng, Jacobsen, & Kent Johnson. “Scrum and CMMI Level 5: A
Magic Potion for Code Warriors.” Agile Conference. Denver, CO, July, 2005.
http://jeffsutherland.com/2007/09/scrum-and-cmmi-level-5-magic-potion-for.html
[Swoyer 2005]
Stephen Swoyer. “Agile Programming and the CMMI: Irreconcilable Differences?” Applica-
tion Development Trends, February 2005.
Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, search-
ing existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regard-
ing this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington Headquarters
Services, Directorate for information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of
Final
6. AUTHOR(S)
Hillel Glazer, Jeff Dalton, David Anderson, Mike Konrad, & Sandy Shrum
17. SECURITY CLASSIFICATION OF 18. SECURITY CLASSIFICATION 19. SECURITY 20. LIMITATION OF
REPORT OF THIS PAGE CLASSIFICATION OF ABSTRACT