This session was led by Steve Freeman and Keith Braithwaite and was focused on what has gone wrong on projects that have done XP.  See James Robertson's post for a blow-by-blow description of the session.  I enjoyed the opportunity to hear the experiences of others who had applied XP.  It also highlighted some of the issues I have with XP.

The difficulty of the Customer role in XP
As I've said before, I think one of the weakest aspects of XP is the way it abstracts away the complex and difficult problem of understanding and designing software for customers behind a simplistic notion of an 'onsite customer'.   The danger from my point of view is that XP projects may ignore the benefits that good business analysts and interaction designers can bring, in lieu of developers just working directly with a customer. 

Even with these reservations, I really do like the way XP focuses on the customer.  One of the problems bought up in the group discussion I was involved with was that often developers are forbidden from talking to customers.  I think developers should definitely have access to customers, or at least 'personas' if the real customers are difficult to get to, and that good projects will also employ other people who have experience dealing with customers (such as BA's, integration designers and even usability experts).

Other points raised included that proxy customers must know their place.  Knowing the problem domain does not mean that someone knows how the solution should work.

Another point was the importance of standing up to the customer and challenging them rather than taking everything they say as correct (they are not always right or always able to say what they want).

The danger of XP sounding like a religion
One of the points was that 'dissenters should be tolerated as long as possible but no longer'.  The point was that one 'professional skeptic' can bring everything to a halt.  Another comment in the session was the need to understand the 'rigour of the disciplines'.  While I understand these points, the language concerns me as it sounds too much like XP is a religion.  This problem was acknowledged later in the session when it was highlighted that it was important not to frighten the customer by being a 'religious fanatic'.

Although XP isn't XP without all of the practices, these still aren't enough
Even though there are a lot of points about XP isn't XP without all the processes, it was also mentioned that the core practices aren't enough on their own.  Mistakes are sometimes made on projects where people have 'read the XP books' but not talked to anyone experience (there were a lot of XP coaches in the session). 

Keith said that mentioned that things like version control are 'assumed' in the core practices but need to be done on professional projects.  Other practices included doing some small design up front but avoiding big design up front (BGUF).  UML diagrams were OK, provided they were just on a whiteboard and not written down.  Also the test/code/refactor cycle wasn't enough to guarantee success, you also required knowledge, skill and experience (to know when to stop for example).

One of the comments I heard at the conference was that a lot of the successful XP projects have very talented people working on them and that this was one of the reasons for success. Any project with successful people is likely to do well, irrespective of the process.  To me this doesn't mean XP isn't useful, just that it may not be a processes that can be applied to all teams.