Get Ready for Agile Methods – With Care
Barry Boehm, USC
Draft for January 2001 IEEE Computer column
In the last two Software Management columns (September and November, 2001
[1,2]), Jim Highsmith and Alistair Cockburn have been discussing “Agile Software
Development.” This is a term summarizing the shared-value propositions of a number of
emerging software development methods, such as Adaptive Software Development
(ASD), Agile Modeling, Crystal Methods, Dynamic System Development Methodology
(DSDM), eXtreme Programming (XP), Feature Driven Development, Lean Development,
and Scrum. The two columns summarize and rationalize these shared value propositions,
which are available as “The Agile Manifesto” at http://www.agileAlliance.org
The core of the Agile Manifesto is that each of the agile methods emphasizes:
 Individuals and interactions over processes and tools,
 Working software over comprehensive documentation,
 Customer collaboration over contract negotiation,
 Responding to change over following a plan.
That is, while there is value in the items on the right, the agile methods value the items on
the left more.
Each of the agile methods has been used successfully in practice. But in his letter
to Computer in December 2001, Steven Rakitin indicates that in his experience, the items
on the right are essential, and that the items on the left are easy excuses for hackers to
keep on irresponsibly throwing code together with no regard for engineering discipline.
He provides “hacker interpretations” that can turn the agile value proportions into chaos
generators, for example:
“Responding to change over following a plan”
Translation: Following a plan implies we would have to spend time thinking
about the problem and how we might actually solve it. Why would we want to do
that when we could be coding?
How can we sort this out? Responding to change has been cited as the critical
technical success factor in the Internet browser battle between Microsoft and Netscape.
But over-responding to change has been cited as the source of many software disasters,
such as the $3 billion overrun of the FAA Advanced Automation System for national air
traffic control. In this column, I’ll try to show that:
 Both agile and plan-driven approaches have a responsible center and
overinterpreting radical fringes (by “plan,” I’m including documented process
plans: tasks and milestones; and product plans: designs, architectures, and
requirements).
 Each approach has a “home ground” of project characteristics within which it
performs very well, and much better than the other.



Outside each approach’s home ground, combined approaches are feasible and
preferable.
Good combined approaches can be determined by using risk analysis to
determine how much planning and agility is enough for your situation.
Marketplace trends are making agility increasingly important.
The Planning Spectrum
Figure 1 places various agile and plan-driven development approaches along a spectrum
of increasing emphasis on plans.
Figure 1. The Planning Spectrum
Hackers
XP
Milestone
Adaptive Risk- Driven
SW Devel. Models
…
…
Milestone
Plan-Driven
Models
Inch- Pebble
Ironbound
Contract
Agile Methods
Software CMM
CMMI
Compared to unplanned and undisciplined hacking, the agile methods do a fair amount of
planning. Their general view, though, is that the planning process is more valuable than
the resulting documentation [1], so they often appear less planned than they are. It is true
that hard-core hackers can use Rakitin’s interpretations of the agile principles to say that
they are agile. But in general the agile methods have criteria, such as XP’s twelve
practices, which help people determine whether someone is using an agile method or not.
Another encouraging trend is that the buzz of agile methods such as XP is drawing many
young programmers away from the cowboy role model toward the more responsible agile
methods. The price that XP pays for this, though, is a reluctance of more conservative
managers to sanction something called “extreme” [3].
Plan-driven methods also have a responsible center focused on major milestones
and their overall content, rather than on micro-milestones (inch-pebbles) locked into an
ironbound contract. Excessively prespecified plans overconstrain the development team
even at minor levels of change in personnel, technology, or COTS upgrades; and are a
source of major contention, rework, and delay at high levels of change. On the other
hand, I found on reviewing many projects using the risk-driven spiral model, that projects
(particularly larger ones) frequently lost their way without at least three major anchor
point milestones to serve as project progress indicators and stakeholder commitment
points [4].
Figure 1 also shows the location of the current Software Capability Maturity
Model (CMM) and its successor, the CMM-Integrated (CMMI). The Software CMM has
often been used in an overly restrictive and bureaucratic way, but can be interpreted to
include some forms of milestone risk-driven models. The CMMI, which adds process
areas for Risk Management, Integrated Teaming, and Organizational Environment for
Integration, can be interpreted to include the agile methods as well.
The “Home Grounds” of Agile and Plan-Driven Development
Table 1 is my attempt to characterize the “home grounds” (where they perform
best) of agile and plan-driven methods, in terms of developers, customers, requirements,
architecture, refactoring, size, and primary objective. Let’s discuss each of these
discriminators in turn.
Table 1. Agile and Plan-Driven Home Grounds
Agile Home Ground

Plan-Driven Home Ground


Agile, knowledgeable, collocated,
collaborative developers
Dedicated, knowledgeable,
collocated, collaborative,
representative, empowered
customers
Largely emergent requirements,
rapid change
Architected for current requirements



Refactoring inexpensive
Smaller teams, products
Premium on rapid value








Plan-oriented developers; mix of
skills
Mix of customer capability levels
Requirements knowable early;
largely stable
Architected for current and
foreseeable requirements
Refactoring expensive
Larger teams, products
Premium on high-assurance
Developers. Cockburn and Highsmith emphasize critical people factors for agile
methods: amicability, talent, skill, and communication [2]. Larry Constantine’s
independent assessment identifies this as a potential problem for agile methods: “There
are only so many Kent Becks in the world to lead the team. All of the agile methods put a
premium on having premium people…” [5]. When you have such people, statements
such as Highsmith and Cockburn’s, “A few designers sitting together can produce a
better design then each could produce alone” [1]. If not, you’re more likely to get
“design by committee,” with the opposite effect. The plan-driven methods of course do
better with great people, but are generally more able to plan the project and architect the
software so that less-talented people can contribute with low risk. A significant
consideration here is the unavoidable statistic that 49.9999% of the world’s software
developers are below average.
Customers. In our rapid-development electronic services projects at USC, we
have found that unless customer participants are committed, knowledgeable,
collaborative, representative, and empowered, the developed products are generally not
successfully transitioned into use, even though they may satisfy the customer. Similar
conclusions were reached in the XP 2001 “Customer Involvement in XP” workshop [6].
Again, the plan-driven methods also do better with great customers, but have more
backup capabilities such as Architecture Review Boards and Independent Expert Project
Reviews to compensate for on-site customer shortfalls.
Requirements. Highsmith and Cockburn emphasize that agile approaches “are
most applicable to turbulent, high-change environments, “ and have a world view that
organizations are complex adaptive systems, in which requirements are emergent rather
than prespecifiable [1]. However, as discussed above, Agile Manifesto tenets such as
Principle 2: “Welcome changing requirements, even late in development,” can be very
successful, but can also be misapplied with disastrous results.
Plan-driven methods work best when the requirements are largely determinable in
advance (including via prototyping) and remain relatively stable, at change rates on the
order of 1% per month. In the increasingly frequent situations in which the rate of
requirements change is much higher than this, the traditional emphasis on having
complete, consistent, precise, testable, and traceable requirements (very important for
stable, safety-critical embedded software), will have difficult to insurmountable problems
in keeping up.
Architecture. The Agile Manifesto values working software over comprehensive
documentation, and emphasizes simplicity: the act of maximizing the amount of work not
done. This can be interpreted in many ways. Most of them are quite good, but some can
cause problems. For example, XP advocates doing extra work to get rid of architectural
features that are not supporting the current version of the system, based on the precept,
“You Aren’t Going to Need It (YAGNI).” This works fine when future requirements are
largely unpredictable. However, in situations where future requirements are predictable,
this practice not only throws away valuable architectural support for them, but also
creates problems with customers who want developers to believe that their priorities and
evolution requirements are worth accommodating.
As with requirements, plan-driven methods emphasizing heavyweight architecture
and design documentation will have difficult to insurmountable problems in keeping up
with rapidly changing requirements. On the other hand, if the directions of requirements
change are well anticipated and accommodated in the architecture, plan-driven methods
can keep even million-line applications within budget and schedule. A good example is
the CCPDS-R project described by Walker Royce in [7].
Refactoring. With great developers and small systems, the assumption that
refactoring is essentially free is valid. If so, the YAGNI approach above is low-risk.
However, there is some empirical evidence that with less-than-great developers,
refactoring effort increases with the number of requirements or stories. And for very
large systems, our Pareto analysis of rework costs at TRW indicated that the 20% of the
problems causing 80% of the rework came largely from “architecture-breakers” (e.g.,
architecture discontinuities to accommodate performance, fault-tolerance, or security
problems), in which no amount of refactoring could put Humpty Dumpty back together
again.
Size. Cockburn and Highsmith conclude that “Agile development is more
difficult for larger teams,” but cite occasional successful larger agile projects with up to
250 people [2]. Constantine's assessment finds agile methods highly attractive for small
projects, but concludes that “The tightly coordinated teamwork needed for these methods
to succeed becomes increasingly difficult beyond 15 or 20 developers” [5].
Plan-driven methods scale better to large projects: the million-line CCPDS-R
project cited above is an example. However, a bureaucratic plan-driven organization
which requires an average of a person-month just to get a project authorized and started is
not going to be very efficient on small projects.
Primary Objective. Principle #1 of the Agile Manifesto states, “Our highest
priority is to satisfy the customer through early and continuous delivery of valuable
software.” “Early and continuous” are reasonably compatible for small systems
developed by great people. But as discussed under Refactoring, overfocus on early
results in large systems can lead to major architecture-breaker rework when the earlyvalue architecture doesn’t scale up. In such cases, a good deal of planning will be
necessary (Principle #8 of Lean Programming says, “Ban Local Optimization” [8].)
The rigorous plans of plan-driven methods are most needed in high-assurance
software. Scott Ambler, the originator of Agile Modeling, says, “I would be leery of
applying agile modeling to life-critical systems” [9]. Another major set of objectives for
the more traditional plan-driven methods, and of the Software CMM, has been
predictability, repeatability, and optimization. But in a world involving frequent, radical
changes, having processes that are as repeatable and optimized as a dinosaur’s may not
be a good objective. Fortunately, the CMMI and associated risk-driven methods provide
a way to migrate toward more adaptability.
Using Risk Considerations to Balance Agility and Discipline
Particularly in the e-services sector, companies with a large installed base of
customers don’t need just one or the other of rapid value or high assurance. They need
both. But pure agility or pure plan-driven discipline can’t do both by themselves. A mix
of each is needed.
Martin Fowler in “Is Design Dead?” [10] and Jim Highsmith in Adaptive
Software Development [11] provide ways in which agile methods can be combined with
plan-driven methods. Another approach that can help you balance agility and discipline
is risk management, which is good for answering, “how much is enough?” questions [4].
Here we will apply it to address the question, “How much planning is enough?”
A central concept in risk management is the Risk Exposure (RE) involved in a
given course of action. It is determined by accessing the probability of loss P(L)
involved in a course of action and the corresponding size of loss S(L), and computing the
risk exposure as the expected loss: RE=P(L)*S(L). “Loss” can include profits,
reputation, quality of life, or other value-related attributes.
Figure 2 shows risk exposure profiles for an example e-services company with a
sizable installed base and desire for high assurance; a rapidly changing marketplace and
desire for agility and rapid value; and an internationally distributed development team
with mix of skill levels and a need for some level of documented plans.
RE = P(L) * S(L)
Figure 2. Risk Exposure (RE) Profile: Planning Detail
- RE due to inadequate plans
- RE due to market share erosion
- Sum of risk exposures
high P(L): inadequate plans
high S(L): major problems
(oversights, delays, rework)
high P(L): plan
breakage, delay
high S(L): value
capture delays
Sweet Spot
low P(L): few plan delays
low S(L): early value capture
low P(L): thorough plans
low S(L): minor problems
Time and Effort Invested in Plans
The black curve in Figure 2 shows the variation in risk exposure (RE) due to
inadequate plans, as a function of the level of investment the company puts into its
projects’ process and product plans. At the left, a minimal investment corresponds to a
high probability P(L) that the plans will have loss-causing gaps, ambiguities, and
inconsistencies. It also corresponds to a high S(L) that these deficiencies will cause
major project oversights, delays, and rework costs. At the right, the more thorough the
plans, the less P(L) that plan inadequacies will cause problems, and the smaller the size
S(L) of the associated losses.
The red curve in Figure 2 shows the variation in RE due to market share erosion
through delays in product introduction. Spending little time in planning will get at least a
demo product into the marketplace early, enabling early value capture. Spending too
much time in planning will have a high P(L) due both to the planning time spent, and to
rapid changes causing delays via plan breakage. It will also cause a high S(L), as the
delays will enable others to capture most of the market share.
The blue curve in Figure 2 shows the sum of the risk exposures due to inadequate
plans and market share erosion. It shows that very low and very high investments in
plans have high overall risk exposures, and that there is a “Sweet Spot” in the middle
where overall risk exposure is minimized, indicating “how much planning is enough?”
for this company’s operating profile.
With the example company situation as a reference point, we can run comparative
risk exposure profiles of companies occupying the home grounds of agile methods and
plan-driven methods as summarized in Table 1. For example, Figure 3 shows the
comparative RE profile for an e-services company with a small installed base and less
need for high assurance, a rapidly changing marketplace, and a collocated team of highly
capable and collaborative developers and customers. With this profile, as shown in
Figure 3, the major change in risk exposure from Figure 2 is that the size of rework loss
from minimal plans is much smaller due to the ability of the team to rapidly replan and
refactor, and thus the company’s Sweet Spot moves to the left toward agile methods.
Mainstream Sweet
Spot
Agile Sweet
Spot
Lower S(L):
easy rework
Figure 4. Comparative RE Profile: Plan-Driven
Home Ground
Higher S(L):
large system rework
Plan-Driven
Sweet Spot
RE = P(L) * S(L)
RE =P(L) * S(L)
Figure 3. Comparative RE Profile: Agile Home
Ground
Mainstream
Sweet
Spot
Time and Effort Invested in Plans
Time and Effort Invested in Plans
Figure 4 shows the corresponding RE profile for a company in the plan-driven
home ground, with a more stable product line of larger, more safety-critical systems.
Here, the major difference from Figure 2 is a much higher size of rework loss from
minimal plans, and a resulting shift of the company’s Sweet Spot toward higher
investments in plans.
Using Home-Ground Attributes to Assess Risk Exposure
In practice, it is hard to quantify estimates of P(L) and S(L). But if you’re trying
to balance your use of agile and plan-driven methods, you can use each method’s “home
ground” attributes to determine relative risks. So, for example, if your company or
project fits an agile home-ground profile except for having a mix of equally-important
customers with less-than-ideal development representatives, you can reduce your risk
exposure by conducting stakeholder requirements negotiations among the developers and
customers, and documenting the results to minimize the risk of future customer
misunderstandings.
Or, if your project fits a plan-driven home-ground profile except for highly
volatile user-interface requirements, you can use the concept of risk-driven specifications
[4] to document those requirements for which it is a high risk not to specify them, and
avoid documenting user-interface requirements whose specification would be high-risk.
Risk-driven spiral methods and frameworks such as the Rational Unified Process [7],
MBASE [12], and the CMMI provide guidelines for finding a good balance of discipline
and flexibility, although the current CMMI approach needs more explicit support for
agility.
Conclusions
Agile methods and milestone plan-driven methods are part of a “how much
planning is enough?” spectrum. Despite certain extreme terminology, they are part of the
responsible center rather than of the radical fringes. Actually, agile methods are
performing a valuable service by drawing erstwhile cowboy programmers toward a more
responsible center.
Both agile and plan-driven methods have home grounds of project characteristics
where they clearly work best, and where the other will have difficulties.
Hybrid agile/plan-driven approaches are feasible, and necessary for projects
having a mix of agile and plan-driven home ground characteristics. Risk analysis of your
projects’ characteristics vs. the home-ground characteristics can help determine your
projects’ best balance of agility and plan-driven discipline. Risk-driven spiral methods
such as RUP, MBASE, and CMMI provide guidelines for finding the best balance.
Information technology trends are going more toward the agile methods’ home
ground characteristics of emergent requirements and rapid change, although there is a
concurrent increase in concern with dependability. Therefore, “get ready for agile
methods—with care.”
References
1. J. Highsmith and A. Cockburn, “Agile Software Development: The Business of
Innovation,” Computer, September 2001, pp. 120-122.
2. A. Cockburn and J. Highsmith, “Agile Software Development: The People Factor,
“Computer, November 2001, pp. 131-133.
3. L. Copeland, “Developers Approach Extreme Programming With Caution,”
Computerworld, October 22, 2001, p. 7.
4. B. Boehm and W. Hansen, “The Spiral Model as a Tool for Evolutionary
Acquisition,” Cross Talk, May 2001, pp. 2-11;
http://www.stsc.hill.af.mil/Crosstalk/crostalk.html
5. L. Constantine, “Methodological Agility,” Software Development, June 2001, pp.
67-69.
6. A. van Deursen, “Customer Involvement in Extreme Programming: XP2001
Workshop Report,” ACM Software Engineering Notes, November 2001, pp. 7073.
7. W.E. Royce, Software Project Management: A Unified Framework, Addison
Wesley, 1998.
8. M. Poppendieck, “Lean Programming: Part 2,” Software Development, June
2001, pp. 71-75.
9. S. Ambler, “When Does(n’t) Agile Modeling Make Sense?”
http://www.agilemodeling.com/essays/whenDoesAMWork.htm
10. M. Fowler, “Is Design Dead?” in G.Succi and M. Marchesi (ed.), Extreme
Programming Explained, Addison Wesley, 2001.
11. J. Highsmith, Adaptive Software Development, Dorset House, 2000.
12. B. Boehm and D. Port, “Balancing Discipline and Flexibility With the Spiral
Model and MBASE,” Cross Talk, December 2001, pp. 23-28;
http://www.stsc.hill.af.mil/Crosstalk/crostalk.html