Extreme Programming Goes to the Beach

In late June, about 160 people gathered on Sardinia for XP2000, a conference devoted to Extreme Programming and other adaptive methodologies. The setting was unconventional — the island is not easy to reach, and conference-goers rarely saw the beaches — but the hospitality was warm and the technical program was strong. Organizers had expected only about sixty attendees.

The expected XP figures were present, including Kent Beck, Ron Jeffries, Robert Martin, and Don Wells. Also on hand were those less directly tied to the movement, such as Erich Gamma, Dave Thomas, Ralph Johnson, and Alistair Cockburn. The first day was devoted to tutorials, followed by two days of papers, panels, and invited talks.

Lessons from Four Projects

The first full day opened with four invited talks on projects that had used adaptive processes. Only one — the often-referenced Chrysler Payroll project, C3 — used XP fully. Ron Jeffries gave a detailed account of both its successes and the factors that led to its cancellation. In its first year the project delivered a system that still pays about 10,000 salaried employees each month. Later difficulties were traced to mixed goals between the payroll department and the IS department funding the work, and to a breakdown in communication between the team and management in both groups.

Robert Martin spoke about an educational testing company project done over several years with Jim Newkirk and others. Requirements were vague and open to change, so the team worked in one-week iterations with frequent customer contact. Though they did not adopt all XP practices, the key elements made the project work even in a C++ environment. This experience helped lead Martin's company, Object Mentor, to embrace XP.

Ralph Johnson discussed the Refactoring Browser, the Smalltalk tool developed in university research. That project also used a subset of XP practices: tight iterations, evolutionary design, and active refactoring were central. Dave Thomas of Object Technology International described demanding early object-oriented projects in embedded systems using Smalltalk and virtual machine technology. He stressed people-orientation, automated testing, and tight iterations, and argued — contrary to many at the conference — that these techniques can work with fixed-price contracts.

The talks together suggested that there are many ways to succeed with a lightweight methodology. These approaches are not a panacea, but they offer principles that can guide people toward success.

The Push Toward RUP

A recurring theme was the relationship between XP and the Rational Unified Process. Many attendees saw reasons for the two to move closer. Dave Thomas reported that Ivar Jacobson very much wants RUP to embrace XP, effectively making XP an instance of RUP. Robert Martin took the opposite angle: how to make XP look like RUP to satisfy bosses who insist on RUP. Martin described work with Grady Booch and Jim Newkirk on the third edition of Booch's classic OO design book, and announced he had been commissioned by Rational to include material in the official RUP documentation ensuring XP could be an instance of RUP.

Two questions arise: whether XP and RUP can be fitted together, and whether doing so is desirable. Given Martin's work and Jacobson's wishes, the fit seems only a matter of time. Most XPers seem to welcome this as a way to ease industrial adoption. The concern is that a blended RUP-XP could dilute XP, causing people to miss important practices. But this concern is not new — problems of partial XP usage exist with or without RUP. The most important issue remains people. Adaptive processes are inherently people-oriented and will not work where people are treated as interchangeable resources.

Good Communication Above All

At the conference, one topic kept surfacing in sessions and conversation: the absolute need for good communication among everyone in the development process. All 12 XP practices clearly facilitate communication — some between developers, some between development and customer, some among customers. Those who have embraced XP report the real gain comes when all the practices are running, because communication then improves the process by more than the linear sum of its parts.

The crowd included many current and former Smalltalkers, now mostly working in Java, plus a fair number of telecom people writing C. The two groups had different paths into XP. The telecom engineers were used to a collaborative environment where the system itself is the working environment, encouraging testing, collaboration, and careful coding standards for hard-to-find bugs and tight constraints. The Smalltalkers had long experience with iterative development and refactoring tools.

Individual and Team Practices

The 12 XP practices can be divided into two groups. Individual practices — testing, refactoring, simple design, and to a lesser extent pair programming, a sane work week, and coding standards — can largely be done without waiting for the team. A developer can adopt these alone, and anecdotal evidence suggests such silent infiltration can succeed; a good example tends to rub off on others.

Team-oriented practices — small releases, continuous integration, the planning game, an on-site customer, and collective ownership — are harder to change unilaterally. These require customers and managers to do things that make them uncomfortable, that are not fully proven, and that demand a perceived loss of control, even if that control never really existed.

Getting everyone involved remains a real challenge. There was considerable discussion about how to persuade management and customers to try XP. A notable gap in XP literature and lore is how to get customers and managers to "embrace change."

An Open Atmosphere

Despite online perceptions of XP zealotry that opposes any deviation, the conference was notably open. The theme was that XP provides a good basis for process, but variations are allowed and accepted. Most attendees were partial adopters at best, and many talks focused on single aspects of XP: refactoring, testing, story gathering, and so on. This openness was a relief to several participants. XP's confident attitude helped attract attention, but it also provokes resistance. Methodologies should be chosen and adapted to fit the people who use them, not the other way around.

The Adoption Question

The closing panel addressed how XP could be adopted in the software industry, treating XP as any new technology growing into the business world. The question for many attendees was whether they could use XP, even partially, and whether they could persuade their bosses to allow it.

This may miss the point. A strong theme of adaptive methods is that technical responsibility belongs with technical people, who should make technical decisions. The real question is not whether a company will allow XP, but whether it will allow technical decisions to be made by technical people. If not, XP is irrelevant. The question then becomes whether you can change your company.

If that change is not possible, you may have to question why you stay. One phrase coined at the conference put it succinctly: "If you can't change your organization, change your organization!" This is not purely a recruiting slogan — it is a reminder that software professionals are ultimately responsible for their own careers.