This is exactly what we have in Pete McBreen's Questioning Extreme Programming (Addison-Wesley, 2002). McBreen, author of the 2001 Software Development Productivity Award-winning Software Craftsmanship (Addison-Wesley, 2001), is not an XP developer, although he's an agile practitioner with many years of experience in developing systems. He approaches XP with an unconvinced, but open mind. This skepticism leads him to explore some very important issues, examining when and why XP works in practice.
Show Me the Proof
There is little proof that agile techniques such as XP work in practice: It's
too early in the lifecycle for solid research, and as a result, many people
are reluctant to adopt them. As with structured techniques in the 1970s and
1980s, would-be adopters have to take the plunge and accept the anecdotal evidence
that XP works. Interestingly, new research in pair programming, which Laurie
Williams and Robert Kessler describe in their new book, Pair Programming
Illuminated (Addison-Wesley, 2002), confirms the anecdotal evidence. And
it's worth noting that Larry Constantine wrote about this topic, at the time
called the "two-coder approach," in
Software Development almost 10 years ago.
The proof issue is such a hot button that McBreen explores it in his first chapter, examining the argument's logic, exactly as I did last February in SD's Agile Modeling newsletter. He goes further to question the validity of research used to justify existing techniques, arguing that studies performed 10 or more years ago lack validity, considering recent advances in hardware and software: What was true for Cobol may not be true for Java. He also points out that the validity of short-term studies is dubious because long-term consequences can take years to arise. Perhaps those who raise the proof question should first apply it to their current practices before they aim their sights at XP.
McBreen supports decision-making on anecdotal evidence, arguing that this method is more valid than extrapolating ideas from a single study. I noted this sort of problem on a data-oriented mailing list a few months back, when someone presented research results from the 1980s about the benefits of modeling. The results clearly showed that it's better to understand requirements and to think through design before coding, but this reader claimed that the study indicated that a serial, big-design up-front (BDUF) approach was superior to an iterative, incremental method. This issue wasn't addressed by the study at all, although the reader assumed that it offered all the proof necessary to justify his approach—and, very likely, his job.
A Little Goes a Long Way
XP's philosophy of traveling light without much documentation often comes under
fire, as it's the polar opposite of the practice of many organizations today.
McBreen reports an anecdote from Alistair Cockburn's Agile Software Development
(a 2001 Software Development Productivity Award-winner published by Addison-Wesley,
2001) that describes a project in which business analysts required significant
supporting documentation for each user story. Regardless of what XP's foes claim,
XP doesn't prevent you from writing documentation—it insists only that you justify
why you need it. Documentation should be treated like any other requirement—estimated,
prioritized and planned for accordingly. In other words, don't blindly create
documentation simply because it makes you feel comfortable; instead, do it because
it adds value. Visit www.agilemodeling.com/essays/agileDocumentation.htm
for more information about agile documentation practices.
Senior executives typically insist on extensive documentation to ensure that the maintenance team has all the necessary information. XP assumes that you'll never hand off the system to a different team to maintain it over time, and that the existing team (or portion thereof) will continue to work on it, therefore requiring less documentation. McBreen states that it's unrealistic to assume that comprehensive documentation enables you to simply hand off a system to another team. Current systems are so complex that some maintenance personnel must be actively involved with the development effort to ensure the hand-off's success. XP reflects current industry realities—and it seems to me that the real problem is that senior executives haven't kept up with the times.
Another sticking point is XP's claim that the design is the source code. McBreen states that this works only when the programmer is the designer, but that it doesn't work when you want to have one person or group work on the design and another person or group build it. This reflects the concept that your organizational structure and software process must complement each other. A company that wants to hand off artifacts between specialists probably won't succeed at XP—XP demands personnel with a wider range of skills.
Who Walks on Water?
One misunderstanding about XP and agile software development in general is that
they require highly skilled personnel. This issue is a serious problem, because
many organizations seem to think that they can succeed with teams of low-talent,
low-cost developers who follow a well-defined rigorous process. McBreen points
out that you will always want to balance the enthusiasm and talent of beginners
with the experience of seasoned veterans. Yes, having a team made up of highly
skilled people who work well together is definitely a good thing, but it's not
a requisite. Regardless of the process, if the developers don't have the skills,
they won't succeed.
Workable in the Real World?
An interesting question is whether or not XP's planning game can work. Following
this practice, developers estimate individual user stories (the requirements),
the customer prioritizes them, and then, based on the current velocity (the
proven ability to implement requirements), just enough of the most important
stories are assigned to the next iteration. The plan evolves as the project
progresses, allowing the schedule to change to reflect the changing situation,
resulting in an accurate and honest plan. Sounds good in theory, but it clearly
isn't something that senior management is interested in—McBreen argues that
imposed estimates are an endemic problem in software development and questions
if the planning game will ever work.
Collective code ownership—the idea that everyone can work on any piece of source code that they need to—is also new to many organizations. McBreen points out that this practice instills a sense of responsibility for the overall application, but that it diffuses individual accountability. This is why I insist that developers must be responsible and motivated: They must actually care about getting the job done in a quality manner. McBreen also claims that collective code ownership makes it difficult for outside observers to assess the capabilities of individual developers—a significant HR issue for many large organizations. If this is a problem, I strongly suggest fixing your HR problems instead of putting your software development processes at risk.
XP is real, and it's here to stay. If you've already adopted XP, McBreen's book will help you to gain a better understanding of why it works and how to make it work even better for you. If you're still sitting on the sidelines, this book will probably prove to be the balanced examination that you've been waiting for. I want to leave you with the following thought: If a similar book had been written about rigorous and/or serial software processes in their early years, I suspect the IT industry would be in significantly better shape today.
Scott Ambler is a senior consultant with Ronin International Inc. His latest books are The Elements of UML Style (Cambridge University Press, 2002) and Agile Modeling (Wiley, 2001).
