Thoughts On ...

XP Ain't out There

The subject is part of a statement of mine that Ron Jeffries often quotes. It comes from a posting I made to the CHAD mailing list a couple years ago.

Recently, Ron asked that I reconcile that statement with the ones I made recently here on my blog.

That discussion has been taking place on the Transitioning to XP mailing list. This list is supposed to be for discussing Mike Hill's upcoming book (which looks very good), so the subject is somewhat off-topic.

The two comments seem consistent to me, so for easy reference I have reposted the original posting here.

The subject line was:
Why can't you use XP with multiple customers?

Andy Cirillo asked:

Has anyone else heard this argument?
What is the motivation behind it?

And I responded:

Ignorance? Fear? Perhaps most importantly a mindset that XP or any
methodology is what solves your problems. I recently had some conversations
that illuminate this last point:

1) I once made the comment that one of my goals was to help people think
about process in a positive way (too often process is a dirty word). One of
the client's architects said, "That would be great -- all we need is a
process." To which I replied, "You *do* have a process process is not
something you decide to do, it *is* what you do -- you may not have a
defined process, or your defined process may not match your actual process,
but the day-to-day activities that move your software from concept to
solution -- however painful -- are your true process."

2) I recently gave a presentation at a user's group meeting. During the
presentation, someone described a situation where they have multiple
customers -- in another city -- but they have been doing XP. After several
months, they are nearing release and finding out that what they are
building does not meet the customer's expectations. His assertion (he
really didn't ask a question) was that they needed a better requirements
gathering approach because XP stories were inadequate. My question (I
didn't really have an assertion) was why did it take several months to get
feedback from the customer as to whether they were building the right
thing? During the following discussion we learned that there were no
acceptance tests, they didn't do small releases, and they didn't have a
Customer on-site, just some analysts who interpreted and often wrote the
stories for them. He then asked if any of the other Agile methods had
better requirements processes...

3) During a friendly debate about "correct practice" discussing some
painful issues that we were working through, a fellow teammate, used the
following argument: "Well, in the book (meaning XP Explained) it says the
following...", to which I replied, "One can take a book and dogmatically
apply what it says.
Also, one can simply follow a written process because 'that's what it
says,' but if our Process can't handle the difficult issues of the project
-- if it breaks down precisely when the things get difficult -- it isn't
worth the paper its printed on. Descriptions of process are guides not
prescriptions, you have to continually adjust what you do to meet the
demands of the situation. We had a very productive discussion afterward...

Anytime someone says to me "we can't use XP because" I hear a warning
buzzer go off that says this person has abdicated his personal
responsibility for the outcome and is looking for a solution "out there."

For me, XP ain't out there, its in here.

Best,
Bill

William E. Caputo
ThoughtWorks, Inc.