Adopting and then tailoring a
software process to meet your team's needs is an
important and difficult decision, one that is critical
to your project's success.
There is a myriad of choices, ranging from
prescriptive processes such as the
Process (RUP) and the OPEN process to agile software
processes such as
eXtreme Programming (XP),
Agile Unified Process (AUP), and
Dynamic System Development Methodology (DSDM).
There is a vast wealth of material written about
these methodologies, but how can you tell whether a
methodology will work for you?
In particular, how do you determine whether an
agile development methodology works within your
If you spend anytime online reading
process-oriented resources, such as the XP mailing list
hosted by Yahoo! groups or the comp.object newsgroup,
you have likely noticed that a common refrain of the
detractors of agile methodologies is "where is the
the surface, this seems to be a reasonable question
because many developers want assurances that these new
approaches do in fact work.
However, I feel that these people are barking up
the wrong tree for several reasons:
1. Agile software development
methodologies are new.
and DSDM are
among the oldest agile methods, being defined in the
mid-1990s. XP, arguably the most popular of the
agile processes, was first described in the late 1990s
as a collection of process/organizational patterns and
in 2000 published as a book. The
Alliance was loosely formed in the Spring of
2001. Agile Modeling (AM) was first defined in the
Autumn of 2000 and was published in March of 2002 as a
The good news is that people are in
fact researching the various agile methods, and that
more and more evidence is being published at various
Agile and academic conferences worldwide. I
suspect that we'll soon be at the point where there is
more evidence in favor of Agile than what we ever saw
with traditional approaches. Of course, this isn't
hard to accomplish seeing as many of the fundamental
assumptions behind traditional development were never
questioned, let alone examined.
Some research results do exist.
For example the
effectiveness of pair programming has been examined
a fair bit, and the issues surrounding iterative and
incremental approaches are reasonably well known.
The bottom line is that metrics concerning agile
software development methods are slowly being gathered,
Also, we're starting to see more and more
results being published.
If you don't give people the answers they'll fill in the blanks themselves, and often get it wrong.
2. I believe that the
expectations of people requiring proof aren't
Moore, in the book Crossing
the Chasm describes five types of profiles of
technology adopters: Innovators who pursue new concepts
aggressively; early adopters who pursue new concepts
very early in their lifecycle; the early majority wait
and see before buying into a new concept; the late
majority who are concerned about their ability to handle
a new concept should they adopt it; and laggards who
simply don't want anything to do with new approaches.
Figure 1 depicts Moore's chasm
with respect to agility.
Crossing the Agile Chasm.
People who fit the innovator or
early adopter profile are comfortable with reading a web
page or book describing agile techniques, they'll
think about the described concept for a bit and then
tailor it for their environment.
This is the spot in the lifecycle that most agile
techniques are currently at, and it is these types of
organizations that are readily adopting these new
early majority will wait for sufficient anecdotal
evidence to exist before making the jump to agile
software development, and we're starting to see adoption
by some of these organizations now.
Unfortunately, the question "where is the
proof" is typically asked by organizations that fit
the late majority or even laggard profiles, as Figure 1
agile techniques clearly aren't at that stage in their
lifecycle yet I believe that this question simply
isn't a fair one at this time.
Note that there's nothing wrong if your
organization fits into either one of these profiles,
many organizations are very successful following these
business models, the important thing is that you
recognize this and act accordingly.
3. We're spoiled.
previous work within the software metrics field may have
set the "proof bar" too high. In the book Software
Assessments, Benchmarks, and Best Practices Caper Jones of Software Productivity
Research presents a wealth of information gathered over
decades pertaining to software development techniques
and technologies. In
Table 5.4 of that book Jones presents the effectiveness
of various development techniques, the most effective
one is the reuse of high-quality deliverables with a
350% adjustment factor whereas quality estimating tools
provides a 19% adjustment factor and use of formal
inspections a 15% adjustment factor.
Table 5.5 goes on to list negative adjustment
example, crowded office space gives a –27% adjustment
factor, no client participation –13% adjustment
factor, and geographic separation a –24% adjustment
point is that current
"best" and worst practices have been
examined in detail, but newly proposed techniques such
as refactoring and co-location with your customers have
not been well studied.
To compound this problem the vast majority of
agile methodologists are practitioners who are actively
working on software projects and whom presumably have
little time to invest in theoretical study of their
techniques. In other words, it may be a long while until we see studies
comparable to those of Capers Jones performed regarding
4. It may not be clear what
actually needs to be proved regarding agile software
development. In Chapter 3 of Agile
Software Development Ecosystems Jim Highsmith observes: "Agile approaches excel
in volatile environments in which conformance to plans
made months in advance is a poor measure of success. If
agility is important, then one of the characteristics we
should be measuring is that agility. Traditional
measures of success emphasize conformance to predictions
(plans). Agility emphasizes responsiveness to change. So
there is a conflict because managers and executives say
that they want flexibility, but then they still measure
success based on conformance to plans. Wider adoption of
Agile approaches will be deterred if we try to
"prove" Agile approaches are better using
"only" traditional measures of success."
5. Perhaps the motivations of
the people asking for proof aren't appropriate.
Are they really interested in finding an
effective process or are merely looking for a reason to
disparage an approach that they aren't comfortable
they realistic enough to recognize that no software
process is perfect, that there is no silver bullet to be
they really interested in proof that something works, or
simply an assurance of perceived safety?
Which is strange, because if something worked for
someone else it doesn't mean that it will work for
|"First they ignore you, then they laugh at you, then they fight you, then you win."
- Mahatma Gandhi
Another interesting observation is that that many of the
people who tell you that Agile doesn't work confuse "code and fix" approaches
with Agile approaches. This is likely because there isn't accepted
determining whether a project is agile, so it's very difficult for them to
distinguish accurately because they don't know what they're looking at.
6. There is growing evidence from the research
community. Recently books such as Pair
Programming Illuminated (Addison Wesley, 2002) and Extreme
Programming Perspectives (Addison Wesley, 2002) have
published some proof that agile techniques work.
The first book explores pair programming, an XP
practice, and confirms the anecdotal evidence that pair
programming is in fact an incredibly good idea.
The second book is a collection of papers presented at
two agile conferences held in 2002, many of which
describe initial research into agile techniques as well
as describe case studies. This book is a very good
start at answering the proof question, and I eagerly
await similar efforts in the near future (so keep your
eye out for them).
7. The anecdotal evidence looks
pretty good. There is currently significant
anecdotal evidence that agile software development
techniques work, you merely need to spend some time on
newsgroups and mailing lists to discover this for
yourself. If anecdotal evidence isn't sufficient then agile software
development processes aren't for you... yet!
8. There is significant evidence
that iterative and incremental development works.
Craig Larman, in Chapter 6 of his book
Iterative Development: A Manager's Guide
summarizes a vast array of writings pertaining to both
iterative and incremental (I&I) development. He cites
noted software thought leaders such as Harlan Mills, Barry
Boehm, Tom Gilb, Tom Demarco, Ed Yourdon, Fred Brooks,
and James Martin regarding their experiences with I&I
development. More importantly he discusses extensive studies into
the success factors of software development. He makes a
very good argument that proof exists that shows that
many of the common practices within agile software
development do in fact work, practices such as
incremental delivery and iterative approaches which
embrace change. He also cites evidence which shows
that serial approaches to development, larger
projects, and longer
release cycles lead to greater incidences project
failure. I highly recommend this book for anyone
interested in building a case for agile software
development within their organization.
Software Development Context Framework (SDFC),
shown) to the cost curve.
Agile techniques, such as
Test Driven Design (TDD),
Agile Model Driven Development (AMDD) all have very short feedback cycles,
often on the order of minutes or hours. Traditional techniques, such as
up front (BRUF) have feedback cycles on the order of weeks or months, making
them riskier and on average more expensive.
Figure 7. Mapping common techniques to the cost of change curve.