Columns

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, established practices.

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.