SOFTWARE MANAGEMENT

them is the only viable strategy. Rather

than eliminating rework, the new strategy is to reduce its cost.
However, in not just accommodating
change, but embracing it, we also must
be careful to retain quality. Expectations
have grown over the years. The market
demands and expects innovative, highquality software that meets its needs
and soon.

Agile Software
Development:
The Business of
Innovation

THE AGILE RESPONSE

Agile methods are a response to this
expectation. Their strategy is to reduce the
cost of change throughout a project.
Extreme Programming (XP), for example,
calls for the software development team to

Jim Highsmith, Cutter Consortium

Alistair Cockburn, Humans and Technology

he rise and fall of the dotcom-driven Internet economy

shouldnt distract us from seeing that the business environment continues to change at a
dramatically increasing pace. To thrive
in this turbulent environment, we must
confront the business need for relentless
innovation and forge the future workforce culture. Agile software development approaches such as Extreme Programming, Crystal methods, Lean
Development, Scrum, Adaptive Software
Development (ASD), and others view
change from a perspective that mirrors
todays turbulent business and technology environment.

THE PROBLEM
In a recent study of more than 200
software development projects, QSM
Associates Michael Mah reported that
the researchers couldnt find nearly half
of the projects original plans to measure
against. Why? Conforming to plan was
no longer the primary goal; instead, satisfying customersat the time of delivery, not at project initiationtook
precedence. In many projects we review,
major changes in the requirements,
scope, and technology that are outside
the development teams control often
occur within a projects life span.
Accepting that Barry Boehms life cycle
cost differentials theorythe cost of
120

Computer

change grows through the softwares

development life cycleremains valid,
the question today is not how to stop
change early in a project but how to better handle inevitable changes throughout
its life cycle.

produce the first delivery in weeks,

to achieve an early win and rapid
feedback;
invent simple solutions, so there is
less to change and making those
changes is easier;
improve design quality continually,
making the next story less costly to
implement; and

Agile development combines

creative teamwork with an
intense focus on effectiveness
and maneuverability.

Traditional approaches assumed that if

we just tried hard enough, we could anticipate the complete set of requirements
early and reduce cost by eliminating
change. Today, eliminating change early
means being unresponsive to business conditionsin other words, business failure.
Similarly, traditional process managementby continuous measurement,
error identification, and process refinementsstrove to drive variations out of
processes. This approach assumes that
variations are the result of errors. Today,
while process problems certainly cause
some errors, external environmental
changes cause critical variations. Because
we cannot eliminate these changes, driving down the cost of responding to

test constantly, for earlier, less

expensive, defect detection.
Agile software development stresses
quality in design. These methods are sometimes confused with ad hoc or cowboy
coding because the design is done on an
ongoing basis, in smaller chunks, as
opposed to all at once and up front. Each
agile method addresses quality in certain
ways. For example, Dynamic Systems
Development Methodology (DSDM) calls
for a series of prototypes to attack unstable or unknown areas: new technology,
new business rules, and user interface
design. Scrum uses intense 15-minute daily
meetings and comprehensive iteration
reviews at the end of each 30-day iteration.

Basic principles
Agile methods stress two concepts: the
unforgiving honesty of working code and
the effectiveness of people working
together with goodwill.
Working code tells the developers and
sponsors what they really have in front
of themas opposed to promises as to
what they will have in front of them. The
working code can be shipped, modified,
or scrapped, but it is always real.
Using people effectively achieves
maneuverability, speed, and cost savings.
People can transfer ideas faster by talking
face to face than by writing and reading
documents. A few designers sitting
together can produce a better design than
each could produce alone. When developers talk with customers and sponsors,
they can iron out difficulties, adjust priorities, and examine alternate paths forward in ways not possible when they are
not working together.

Agile Software Manifesto

In recognition of these ideas, in February 2001, we joined 15 other people representing XP, Scrum, DSDM, ASD,
Crystal, Feature-Driven Development,
pragmatic programming, and others
sympathetic to the need for alternative
software development methods in signing the Manifesto for Agile Software
Development. We wrote:
We are uncovering better ways of
developing software by doing it and
helping others do it. Through this
work we have come to value
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, we value the items on the
left more.

Processes, tools, documentation, contracts,

and plans are useful. But when push comes
to shoveand it usually doessomething

must give, and we need to be clear about

what stays and what gives.
Relying on interactions between individuals facilitates sharing information
and changing the process quickly when it
needs changing. Using working software
allows us to measure how fast we actually produce results and provides quick
feedback. Frequent interaction between
individuals compensates for minimizing
documentation.

In a complex adaptive
system, decentralized,
independent individuals
interact to create
innovative, emergent
results.

when a team of individuals practices

them.
Most methodologies provide inclusive
rulesall the things you could possibly
do under all situations. Agile methods
offer generative rulesa minimum set of
things you must do under all situations to
generate appropriate practices for special
situations. Teams that follow inclusive
rules depend on someone else to name in
advance the practices and conditions for
every situation. This obviously breaks
down quickly. A team that follows generative rules depends on individuals and
their creativity to find ways to solve problems as they arise. Creativity, not voluminous written rules, is the only way to
manage complex software development
problems and diverse situations.

AGILE PRACTICES
Customer collaboration means that
all playersthe sponsor, customer, user,
and developerare on the same team.
Merging their different experiences and
expertise with goodwill allows the combined group to change directions
quickly so they can produce more
appropriate results and less expensive
designs. Contracts or project charters
with the customers are necessary, but
without collaboration, they are insufficient.
Working through producing a plan
drives the team members to think
through their project and its contingencies. The plan itself usually goes out of
date within just a few days. Afterward,
rather than focusing on the outdated
plan, it is important to deal with the
changing realities.

GENERATIVE RULES
One aspect of agile development is
often missed or glossed over: a world
view that organizations are complex
adaptive systems. A complex adaptive
system is one in which decentralized,
independent individuals interact in selforganizing ways, guided by a set of simple, generative rules, to create innovative, emergent results. XPs 12 practices, for example, were never intended
to be all-inclusive rules; instead, they are
generative rules that interact in concert

A team isnt agile if the feedback loop

with customers and management is six
months. Agile approaches recommend
short iterations in the two- to six-week
range during which the team makes constant trade-off decisions and adjusts to
new information. XP and Scrum have
more directed cyclestwo to three weeks
for XP, 30 days for Scrum; other methods such as Crystal and ASD tolerate
more variation.

Feature planning and

dynamic prioritization
Agile approaches combine these short
iterative cycles with feature planning and
dynamic prioritization. XP uses story
cards; Scrum uses the term backlog;
ASD and Feature-Driven Development
refer to features. The key point is that
agile approaches plan features, not tasks,
as the first priority because features are
what customers understand.
Dynamic prioritization means that at
the end of an iteration, the customer can
reprioritize the features desired in the
next cycle, discarding originally planned
features and adding new ones. Scrum
explicitly states that priorities can only
change at the end of an iteration, not during one. DSDM uses MoSCoW rules
for featuresMust have, Should have,
Could have, Want to have sometime.
XPs priority scheme is binaryin this
cycle, or not.
September 2001

121

Software Management

Feedback and change

Nextgeneration
courses
for the
next
generation
of computer
professionals
Influence what our
students learn.

Review the latest draft of

Computing Curricula 2001.
http://computer.org/
education/curricula2001
Prepared by the
IEEE Computer Society/
ACM joint task force on
Computing Curricula 2001

Because they are most applicable to turbulent, high-change environments, agile

approaches recommend a variety of practices for constant feedback on technical
decisions, customer requirements, and
management constraints. XP advocates
pair programming for feedback, and
DSDM features short-cycle user prototyping. Crystal and ASD advocate end-ofiteration process and team reviews. ASD
and Scrum use end-of-iteration reviews
with customer focus groups.
Agile practices encourage change
rather than discourage it. In turbulent
business situations, a methodologys
change tolerance must be geared to the
change rate of a specific environment, not
some internal view of how much change
is acceptable. For example, changes to
feature priorities and requirements are
handled within the context of a team and
the customer partners unless the changes
violate the broad scope, schedule, and
cost constraints set by the purchasing
customer (or management).

Focus on teamwork
Team proximity and intense interaction between team members are hallmarks of all agile methods. XP is noted
for pair programming, although the practice has been around for years under
other names. Crystal, Scrum, and ASD
advocate close collaboration practices
including barrier-free collocated teams.
Lean Development stresses team interaction.
Using agile development methods
requires close customer partnerships. If
the customers, either internal department
representatives or marketing product
managers, dont have a good sense of
direction and wander around in strange
patterns, agile developers will follow
them (with occasional admonitions, of
course). Poor customers result in poor
systems.

n 1995, Steven L. Goldman, Roger N.

Nagel, and Kenneth Preiss, the
authors of Agile Competitors and
Virtual Organizations (Van Nostrand
Reinhold, New York), offered this definition of agility:

I
122

Computer

Agility is dynamic, context-specific,

aggressively change embracing, and
growth-oriented. It is not about improving efficiency, cutting costs, or battening down the business hatches to ride
out fearsome competitive storms. It is
about succeeding and about winning:
about succeeding in emerging competitive arenas, and about winning profits,
market share, and customers in the very
center of the competitive storms many
companies now fear.

This book was about manufacturing, but

the definition of agility applies equally to
todays software development environment.
Agility, ultimately, is about creating
and responding to change. What is new
about agile methods is not the practices
they use, but their recognition of people
as the primary drivers of project success,
coupled with an intense focus on effectiveness and maneuverability. This yields
a new combination of values and principles that define an agile world view.
Agile software development addresses
two pressures that characterize todays
business and technology world: the need
for dynamic, innovative approaches and
the desire to build workplaces that arent
described in Dilbert cartoons.

Jim Highsmith is director of Cutter Consortiums e-Project Management Practice. Contact him at jimh@adaptivesd.
com.

Alistair Cockburn is a Consulting Fellow

at Humans and Technology. Contact him
at arc@acm.org.

Editor: Barry Boehm, Computer Science

Department, University of Southern California, Los Angeles, CA 90089; boehm@
sunset.usc.edu

SOFTWARE MANAGEMENT

and skills of individuals and molds

process to specific people and teams, not
the other way around.

Agile Software
Development:
The People Factor

AGILE IS FOR PEOPLE

The most important implication to
managers working in the agile manner is
that it places more emphasis on people
factors in the project: amicability, talent,
skill, and communication.
These qualities become a primary concern for the would-be agile team. Skill
development is important, so that each
person can deliver more value with time.
The attention to the human issues
gives agile projects a particular feel. It is

Alistair Cockburn, Humans and Technology

Jim Highsmith, Cutter Consortium

n a previous article (Agile Software

Development: The Business of Innovation, Computer, Sept. 2001, pp.
120-122), we introduced agile software development through the problem it addresses and the way in which it
addresses the problem. Here, we describe
the effects of working in an agile style.

Agile development focuses

on the talents and skills of
individuals, molding the
process to specific people
and teams.

AGILE RECAPPED
Over recent decades, while market
forces, systems requirements, implementation technology, and project staff were
changing at a steadily increasing rate, a
different development style showed its
advantages over the traditional one. This
agile style of development directly addresses the problems of rapid change.
A dominant idea in agile development
is that the team can be more effective in
responding to change if it can
reduce the cost of moving information between people, and
reduce the elapsed time between
making a decision to seeing the consequences of that decision.
To reduce the cost of moving information between people, the agile team
works to
place people physically closer,
replace documents with talking in
person and at whiteboards, and
improve the teams amicabilityits
sense of community and morale
so that people are more inclined to
relay valuable information quickly.

To reduce the time from decision to

feedback, the agile team
makes user experts available to the
team or, even better, part of the team
and
works incrementally.
Making user experts available as part
of the team gives developers rapid feedback on the implications to the user of
their design choices. The user experts,
seeing the growing software in its earliest
stages, learn both what the developers
misunderstood and also which of their
requests do not work as well in practice
as they had thought.
The term agile, coined by a group of
people experienced in developing software
this way, has two distinct connotations.
The first is the idea that the business
and technology worlds have become turbulent, high speed, and uncertain, requiring a process to both create change and
respond rapidly to change.
The first connotation implies the second one: An agile process requires
responsive people and organizations.
Agile development focuses on the talents

not simply a matter of reducing paperwork and hoping that everything else will
fall into place. To paraphrase one developer, A small, rigorous methodology
may look the same as an agile methodology, but it wont feel the same.
The agile group concept grows to span
teams, organizations, and other working
relationships. It is very difficult for agile
people to function well in a rigid organizationand vice versa.

INDIVIDUAL COMPETENCE
Agile development teams focus on
individual competency as a critical factor in project success.
If the people on the project are good
enough, they can use almost any process
and accomplish their assignment. If they
are not good enough, no process will
repair their inadequacypeople trump
process is one way to say this.
However, lack of user and executive
support can kill a projectpolitics
trump people. Inadequate support can
keep even good people from accomplishing the job.
The CHAOS Chronicles Version II,
a recent update of the Chaos Report
November 2001

131

Software Management

from the Standish Group (http://www.

pm2go.com), outlines a recipe for success that includes 10 items. The first three
items are executive support, user involvement, and experienced project management.
These items are certainly key, and we
agree with having them in the top 10.
However, competent staff is buried
inside the tenth item: Other.
While it is true that politics trump people, it is equally true that the developers
wont succeed in producing a system if
they lack the basic competency for the job.
Interestingly, people working together
with good communication and interaction can operate at noticeably higher levels than when they use their individual
talents. We see this time and again in
brainstorming and joint problem-solving
sessions.
Therefore, agile project teams focus on
increasing both individual competencies
and collaboration levels.
In Now, Discover Your Strengths,
(Simon & Schuster, New York, 2001),
Marcus Buckingham and Curt Coffman
discuss the outcome of a long-running
research program by the Gallup organization, in which 80,000 managers in 400
companies were interviewed over a 25year period In this book, they highlight
the interplay between talent, skill, and
knowledge. Regarding high-performance
working environments, they write:
The larger, establishment camp is comprised of those organizations that legislate the process of performance.
They try to teach each employee to
walk the same path.
This [people-based] type of organization focuses not on the steps of the
journey but on the end of the journey.
The distinction between the two camps
is real. Step-by-step organizations are
designed to battle the inherent individuality of each employee. Strengthbased organizations are designed to
capitalize on it.

Extending their ideas, its not that organizations that employ rigorous processes
value people less than agile ones, its that
132

Computer

they view peopleand how to improve

their performancedifferently. Rigorous
processes are designed to standardize
people to the organization, while agile
processes are designed to capitalize on
each individual and each teams unique
strengths: One-size-fits-oneevery process must be selected, tailored, and
adapted to the individuals on a particular project team.

Agile processes are

designed to capitalize on
each individual and each
teams unique strengths.
Too often, software engineering and
rigorous process adherents confuse
process and competence. Process can
provide a useful framework for groups
of individuals to work together, but
process per se cannot overcome a lack of
competency, while competency can
surely overcome the vagaries of a
processagain, people trump process.
When you look under the cover of XP,
Scrum, Adaptive Software Development,
Crystal Methods, Feature-Driven Development (FDD), or Dynamic Systems
Development Methodology (DSDM), the
emphasis on people and their talent, skill,
and knowledge becomes evident.
This is a competency attitude, not an
elitist one. Whether its the practices of
pair programming and mentoring in XP
or chief programmers and inspections in
FDD, the goal remains consistent
working jointly to improve the knowledge and skill of individuals. A recent
book by Pete McBreen, an agile development practitioner, is therefore appropriately titled not software engineering
but Software Craftsmanship (AddisonWesley, Reading, Mass., 2001).

TEAM COMPETENCE
Agile teams are characterized by selforganization and intense collaboration,
within and across organizational boundaries.
Self-organizing teams are not leaderless
teams; they are teams that can organize
again and again, in various configurations, to meet challenges as they arise.

Agility requires that teams have a common focus, mutual trust, and respect; a
collaborative, but speedy, decision-making process; and the ability to deal with
ambiguity.
We distinguish collaboration from
communication. Communication is the
sending and receiving of information.
Collaboration is actively working together to deliver a work product or make
a decision.
The DSDM manual, for example,
identifies the differences between traditional and agile project managers, one of
which is: A traditional project manager
will normally focus on agreeing to a
detailed contract with customers about
the totality of the system to be delivered
along with the costs and timescales. In a
DSDM project, the project manager is
focused on setting up a collaborative
relationship with the customers.
Scrum projects are characterized by
intense 15 to 30 minute daily meetings in
which participants constantly adjust to
the realities of high-change projects.
All too often, project teams are given
the ultimate accountability for product
delivery, while staff groupsproject
offices, process management, data administratorsare given decision power. In
order to innovate and react to change,
agile teams reflect a better alignment of
accountability and responsibility. It is
again an emphasis, at the team level, on
competency rather than process.

AGILE ORGANIZATIONS
An agile team working within a rigid
organization has as difficult a time as
agile individuals working within a rigid
team. Many project teams we have interviewed report that when they responded
to customers requests and to technology
platform changes to deliver usable value
to the customer, their management
admonished them for lack of conformance to the original plan.
Agile organizations and agile managers understand that demanding certainty in the face of uncertainty is
dysfunctional. Agile companies practice
leadership-collaboration rather than
command-control management. They set
goals and constraints, providing boundaries within which innovation can flour-

How to Reach
Computer
Writers
ish. They are macromanagers rather than
micromanagers. They understand that
who makes decisions isnt as important
as collaboration on information to make
informed decisions. They understand
that agility depends on trusting individuals to apply their competency in effective ways.
Doug DeCarlo has labeled traditional
project management Newtonian neurosis. In this context, neurosis means
attacking complex, nonlinear problems
with simplistic, linear processes.

AGILE ECOSYSTEMS
A project is built from people having
differing personalities and differing skills,
working in a physical environment
within an organizational culture. The
people, environment, and organizational
culture all influence one another. When
a strong person leaves, the organization
rearranges itself to compensate; when the
team spreads itself across multiple floors,
communications change; and so on. The
project is an ecosystem.
Using the term ecosystem to convey
the totality of the project at hand brings
us to the discussion of processes and
ecosystems and fitting the two together.
Installing a process within an ecosystem offers two choices: Fit the ecosystem
to the process or fit the process to the
ecosystem. In reality, both the process
and ecosystem change, but the agile
approach honors the ecosystem and recognizes that not every process will work
in every ecosystem.

AGILE EFFECTIVENESS
Nearly 200 people from a wide range
of organizations in North America,
Europe, Australia, India, and other locations responded to a survey of agile and
rigorous methodologies conducted by
the Cutter Consortium in 2001. This survey showed three interesting results.
First, compared to a similar study conducted late in 2000, many more organizations said they were using at least one
agile methodology.
Second, agile methodologies showed
slightly better delivery performance than
rigorous methodologies in terms of business performance, customer satisfaction,
and quality.

Third, agile methodologies scored better than rigorous methodologies in terms

of employee morale. This is particularly
surprising in that 54 percent of the respondents were IT and executive managers and
only 12 percent were developers.
One study is, of course, only one study,
and we should view the conclusions
accordingly. However, these preliminary
results reflect the effectiveness and contribution of agile approaches to morale.

We welcome submissions. For

detailed information, write for a
Contributors Guide (computer@
computer.org) or visit our Web site:
http://computer.org/computer/.

AGILE DOMAINS

Send product announcements to

products@computer.org. Contact
Stephanie Kawada at skawada@
computer.org with book announcements.

Agile development is not for everyone.

Imposing agile principles on process-centric, noncollaborative, optimizing organizations is likely to fail. Imposing a changeembracing process on sedate project
teams may not be reasonable. Attempting
to get close user collaboration with organizations that have little time to spend
with developers wont work.
Agile development is more difficult
with larger teams. The average project
has only nine people, well within the
reach of the most basic agile processes.
Nevertheless, it is interesting to occasionally find successful agile projects with
120 or even 250 people.

gile development excels in exploratory problem domains

extreme, complex, high-change
projectsand operates best in a peoplecentered, collaborative, organizational
culture. This approach has proved to be
effective at solving many problems and at
forging attractive work environments in
many organizations. While it is not suited
for everyone, it is suited for many.

Alistair Cockburn is Consulting Fellow

at Humans and Technology. Contact him
at arc@acm.org.
Jim Highsmith is director of the Cutter
Consortiums e-Project Management
Practice. Contact him at jimh@
adaptivesd.com.
Editor: Barry Boehm, Computer Science
Department, University of Southern
California, Los Angeles, CA 90089;
boehm@sunset.usc.edu

News Ideas
Contact Lee Garber at lgarber@
computer.org with ideas for news
features or news briefs.

Products and Books

Letters to the Editor

Please provide an e-mail address or
daytime phone number with your
letter. Send letters to Letters,
Computer, 10662 Los Vaqueros
Cir., PO Box 3014, Los Alamitos,
CA 90720-1314; fax +1 714 821
4010; computer@computer.org.

On the Web
Visit http://computer.org for information about joining and getting
involved with the Society and
Computer.

Magazine Change of Address

Send change-of-address requests
for magazine subscriptions to
address.change@ieee.org. Make
sure to specify Computer.

Missing or Damaged Copies

If you are missing an issue or
received a damaged copy, contact
membership@computer.org.

Reprint Permission
To obtain permission to reprint
an article, contact William Hagen,
IEEE Copyrights and Trademarks
Manager, at whagen@ieee.org.
To buy a reprint, send a query to
computer@computer.org or a fax
to +1 714 821 4010.

Innovative technology for computer professionals

November 2001

133