Contents

Sardinia is not the obvious choice for an international software
conference. It is a bit awkward to get to and the delights of its
beaches are lost on conference attendees who spend all their time
indoors. The important thing was that the hosts were warm, the
food was excellent, and the conference was also pretty good.

The conference was a nice size. Program Chair Michele Marchesi and his
team had expected around 60 people to show, but got 160. So there
were enough people to give the whole thing a buzz, but not so many
that you couldn't easily talk to the people there. The expected XP
suspects were in attendance, including Ron Jeffries, Robert Martin,
Don Wells, and of course Kent Beck. There were also a few less
directly connected with XP, such as Erich Gamma, Dave Thomas, Ralph Johnson,
and Alistair Cockburn.

The conference had tutorials on the first day, followed by two
days of papers, panels, and invited talks.

Four War Stories

Kent Beck introduced Ron Jeffries by
saying that his wife told him that she had no objection to Kent being
a star if all his groupies looked like Ron.

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.

Robert Martin announced that he has been
commissioned by Rational to write material for the Rational Unified
Process that will allow XP to fit in with 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.

Alistair Cockburn is not one of the XP
leaders, but he is a leading advocate of light methodologies. His
approach stresses the importance of human interaction and teaming
in software development.

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.

Don Wells (left) has put together the sharpest
looking XP site
on the web.

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.

Dave Thomas attributed many of the successes of OTI to the kinds of techniques talked about in the conference, and was pleased that there was hardly any XP dogmatism.

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.