Extreme programming for a rainy day
- By Matt Stephens
- May 1, 2005
When extreme programming (XP) catapulted onto the software development scene,
it appeared to answer many project failure modes—such as documentation overkill,
lack of clear customer requirements, design decay, programmers failing to communicate
with each other and so on. And all this was wrapped up in a neat package of 12
supposedly easy-to-follow practices.
It turns out that XP isn’t suited to everyone. It’s a highly social
collection of values and practices, well suited to extroverted, noisy types
who like to talk (and listen) throughout the day, then clock off at 5 p.m. However,
a large proportion of programmers are introverted and don’t respond well
to XP’s high dependency on so-called oral documentation.
Teams have also discovered that the XP practices are hard to follow. A day
in the life of an XP project is tiring, and it’s still uncertain whether
XP really makes teams any more productive. It’s difficult to base XP’s
productivity on reliable metrics because the product you create in XP will evolve
and meander throughout the project, and the baseline shifts constantly.
XP’s biggest failing, however, is that it encourages software development
without sufficient exploring the customer’s business requirements before
teams begin coding. As a result, in their efforts to create working software
in the first week or two of the project (and then evolve the design as new requirements
are uncovered), teams tend not to explore the all-important rainy-day scenarios.
Many of the hidden requirements that are discovered later were waiting to be
found all along. The myth that customers don’t know what they want and
therefore need working software in front of them to elicit their true requirements
can be addressed by working closely with customers, clearing up the language
used in the written requirements and eliminating ambiguity.
However, in looking for a replacement for XP, we shouldn’t throw the
baby out with the bathwater. Many of the practices in XP are predicated on sound,
Top of the list of good, salvageable practices are: unit testing (especially
the practice of writing tests before the code); encouraging teams to communicate
and collaborate throughout the project (not just in a big requirements and design
workshop held at the start of the project); agile planning (that is, making
the project planning-based rather than plan-based); and releasing working software
in small increments.
Out with the bathwater can go the clocking off at 5 p.m. culture, the constant
mandated pair programming, the insistence on having an on-site customer team
equal to or larger than the team of programmers, and the overly programmer-centric
view of the world (XP is a very programmer-oriented methodology, where even
the customer is encouraged to write the requirements in executable script form).
So, what are we left with? If we focus on addressing the same failure modes
that XP originally set out to address, but armed with the painful lessons learned
from XP, we should end up with an agile process with a focus on disambiguating
the requirements early in the project and creating project documentation that
is minimal, yet sufficient.
There are several agile processes which could feasibly pick up where XP has
fallen: Crystal Clear, Feature Driven Development, Agile Modeling (layered on
top of XP or RUP) and the ICONIX Process, to name the main contenders. These
processes all place the emphasis on analysis and design modeling and don’t
have the same allergy to written documentation that XP seems to have.
I’d recommend Agile ICONIX because it’s designed to address the
sort of project failure modes that XP hasn't done so well on. Agile ICONIX is,
at heart, all about avoiding analysis paralysis whilst still doing sufficient
up-front work to create a design which is closely tied in with the requirements.