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.