The XP 2000 Conference

Four War Stories

The first proper day of the conference opened with four invited talks, all of which talked about projects and teams that had used adaptive processes, although only one of them used XP to the full. That one, of course, was the oft-referenced Chrysler Payroll project, known as C3. Ron Jeffries stepped up to talk about that, and gave a pretty complete description not just of its successes, but also what led to its cancellation. To sum up, the project did very well in its first year or so, delivering a system that still pays around 10,000 salaried people at Chrysler every month. Later on, troubles gradually set in. Ron identified these as:

• mixed goals between the payroll department (who used the system) and the IS department (who were paying for it)
• break down in communication between the team and the management both in payroll and IS

Robert Martin talked next, and his theme as a project for the an educational testing company. The project was done over several years by Robert, Jim Newkirk, and various associates. The requirements were very vague and open to change, so they dealt with this problem by short (one week) iterations and frequent contact with the customer. Although they didn't use the full range of XP practices they found the key elements made a success out of what could be a tricky situation, and that these kind of tight iterations can work even in a C++ environment. This experience was the best example of the experiences which led their company, Object Mentor, to their enthusiastic embrace of XP last year.

Ralph Johnson's example development was of the Refactoring Browser, the famed Smalltalk tool which is a symbol of what is possible in refactoring tools. Developed as part of doctorate research at university, it again used some XP practices to develop the tool. Again tight iterations and an evolutionary approach to design were central, as was the active use of refactoring in the design.

The final example was that of Dave Thomas, the founder of Object Technology International (OTI). OTI were known for many demanding early object-oriented projects which used Smalltalk and virtual machine technology in embedded systems. His accent was on the people-orientation, automated testing, and again the tight iterations. Contrary to many at the conference, he stressed that you can use these techniques with fixed price projects.

The cumulative effect of the talks was that there were many ways to succeed with a lightweight methodology. Like other methodologies, the lightweight approaches are not a panacea, but they provide principles that can guide people towards success.

Will XP be Unified?

A recurring topic was the relationship between XP and the Rational Unified Process. Many people see a need for the two to draw closer together, for various reasons. Dave Thomas reported that Ivar Jacobson very much desires to see RUP embrace XP, effectively making XP an instance of RUP. Robert Martin took the other tack: how do you make XP look like RUP to satisfy bosses who may insist on you doing RUP? Robert has put together a pretty firm example of how you can do this in his collaboration with Grady Booch and Jim Newkirk on the third edition of Booch's classic OO design book. He also announced that he had been commissioned by Rational to include material in the official Rational Unified Process documentation that would make sure that XP could be an instance of RUP.

Here we see two questions: is it possible to fit XP and RUP together, and if so is it desirable? Robert's approach, together with Ivar's desires seem to make the fit a matter only of time. If RUP is present, then XP is certainly on the menu. The desirability is another matter. It seems that most XPers welcome the approach to make it easier for people to adopt XP in the industry. However the concern is that using RUP-XP will dilute XP leading people miss out on important practices.

In my view it makes little difference. Nothing will stop RUP including XP, and the problems of partial usage of XP are no different with RUP than without. In the end the biggest issue revolves around people. Adaptive processes are inherently people-oriented and they just won't work in an environment that treats people as abstract resources. Whether XP is adopted under the flag of RUP has no effect on this more vital issue.

Open Minds

Read many of the postings about XP on the Internet, and what you often get is a strong impression of a set of zealots that oppose any deviation from the one true XP way. One of the best things about this conference was that the zealotry was very much left at home. Instead I saw a conference that while focused around XP topics, did not try to overly push the particular XP mantra.

The theme was more that although XP provide a good basis for software process, variations were both allowed and accepted. Most people at the conference were very much partial adopters of XP at best, and the conference topics allowed for plenty of talks which focused on just particular aspects of XP: refactoring, testing, story gathering and like.

I, like Dave Thomas, was very relieved to see this openness. XP's attitude has helped it get people's attention, but also provokes resistance. I've found it's practices very valuable, but I'm not the kind of person to take the whole approach as a rigid set of rules to follow. Methodologies should be chosen and adapted to fit the people who use them, not the other way around.

A New Orientation

There was no surprise about the last panel of the conference: the inevitable topic of how XP can be adopted in the software industry. And the theme of the panel was that XP is just like any other new technology trying to grow in the business world. The issue for many people was how they could use XP, or some of XP, in their own organizations. Even if the attendees wanted to use it, could they persuade their bosses to let them?

I think this is somewhat missing the point. One of the strong themes of adaptive methods is the fact that they place technical responsibility of technical people, and that technical people should make technical decisions. The question is not whether a company will allow XP, so much as whether a company will allow technical decisions to be made by technical people. Without that the issue of XP is irrelevant. If your company isn't like that the question becomes one of whether you can effect a change in your company.

If that change isn't possible then you have to question why you should stay there. In a phrase I coined off the cuff on a panel: "If you can't change your organization, change your organization!" This is not purely a recruiting plug for Thoughtworks (although we're always delighted to take good people from bad companies), it's also a call to software professionals to remember that in the end nobody is more responsible for your career than yourself, and this market is no time to be unhappy with your job.

Jack's View

(contributed by Jack Bolles)

XP2000 has come and gone and was exceptional not for the topic but rather the quality of the discussion and attendees. As our colleague Foemmel can tell you (about XMLOne), a subject's first conference can be a lot of marketing and flag waving. Given the rather extreme nature of the topic, I expected a lot of the latter, and was pleasantly disappointed. And with the exception of Robert Martin's "Ark of the Covenant" speech, there was practically no marketing ;>

The crowd was thick with current and ex Smalltalkers, now working mostly in Java. There were also a fair number of telecom people, mostly working in C. Talking to these two groups, I could see what drew them to XP. The latter are used to a collaborative environment. When the working environment is also the system, you tend to test your work, collaborate and communicate with other team members using the same image. The telecom people have very tight schedules, hard to find bugs that need to be isolated and low footprints that require careful coding standards.

What ties these groups together, and what kept coming up in sessions and other conversations, was the absolute need for good communication among everyone involved in the development process. All of XP's 12 practices clearly facilitate communication. Some are between developers,some between development and the customer, some between customers. The real gain, according to those that have embraced XP, is when all the processes are running, communication facilitates improvements greater than the linear sum of the parts.

One thing that occurred to me was that XP's 12 practices can be divided into two groups. The first group consists of individual practices that (largely) don't rely on others for you to do. These include testing, refactoring, simple design, and to a lesser extent, pair programming, sane work week, and coding standards. The second group requires the team as a whole: small releases, continuous integration planning game, on-site customer, collective ownership. There is no reason why a developer can't personally use the individual practices. Setting a good example, whether it's testing your code or refactoring, tends to rub off on people. Anecdotal evidence reports silent infiltration of XP has been used successfully.

It is less effective when trying to change group practices. Especially practices that involve teams beyond the development team. Why is this? The individual practices, largely geared towards developers, are well-known best practices that we all should be doing anyway. The team-oriented ones require customers and managers to do things they are uncomfortable with, are not proven, and that require the perceived loss of control (even if they never truly had control. i.e. the project schedule).

Getting everyone involved in the process has been a real challenge. There was a fair amount of hand wringing about how to convince people to try it, especially management and customers. Martin Fowler made the double entendre several times that, if your organization is not doing what you think it should, you should "change your organization". Whether that meant change the way your organization works, or change the organization you work for, was left as an exercise for the student.

But that does not belie the glaring hole in the XP literature and lore is how to get customers and managers to "embrace change". Hopefully that will change before XP2001.