XP2000 has come and gone and was exceptional not for the topic but rather the quality of the discussion and attendees. 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 UncleBob'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. -- JackBolles
----
Really more ThingsHeardAtXpTwoThousand...

A key point of XP is keeping smart people from making systems that are more complicated than they need to be --RalphJohnson (paraphrased)