Hmm... Perhaps the best way to put it is maybe the opposite. There are lots of ways to fail, and less ways to succeed :-) Of all of the practices in XP, I think the one that gives you the most bang for buck is actually the planning game. However, there are a couple of things that are super important (as far as I can tell). First, trying to plan all your stories and then working until you hit the functionality you want almost always fails. And in fact, it almost always fails
hard. It's much better to set a deadline and then say, "We'll release the best thing we can manage in that time frame". It's really counter-intuitive, but my impression is that this kicks the organisation out of the mindset of "plan once and then stick your head in the sand". One of the most important parts of XP is the exploratory nature of it. One of my colleagues put it best (and may have got it from somewhere else): the time you know the
least about the project is at the beginning.
So one of the things I do straight off the bat is to take a list of stories to the stake holder. Usually they say something like, "When will this be released" and I say, "Never. We aren't going to release this. We're going to release something better than this. I don't know what it will be yet. It's related to this, but the actual details will be different". The extent that the stakeholders can grasp this concept will pretty much determine whether or not you can use XP (or, in fact, any iterative approach).
This is actually pretty fundamental, because there are advantages and disadvantages to XP's famous "No Big Design Up Front". It's valuing the ability to change the design frequently and easily over straight throughput. So if your stakeholders are not OK with the requirements changing frequently, then you are probably actually better off doing the big design up front -- you'll get the wrong system, but at least you'll do it quickly ;-)
You may think that it's a hard sell to say that the requirements must change, but in my experience probably about half of the organisations embrace that idea and half reject it. Ironically, I've found that sales focussed organisations actually have an easier time understanding this than internal tools organisations. Stakeholders that need to do frequent demos to clients often want to change things frequently. Stakeholders that are trying to checkmark "we did the thing on the strategic list" often don't want the extra complexity.
Within that same framework, I've found that 1 week sprints are literally the holy grail of XP. That is, you really, really want it, but it's actually impossible. I'm sure that there are some situations where it is possible, but the activities surrounding planning are numerous and complex and those organisations which insist on faster sprints often skip the important activities, leading to failure. So it's pretty important that the stakeholders understand the rhythm of planning: you have an idea for a change, you explore that idea in a meeting, someone breaks down that idea into realistic work pieces, the team estimates the pieces (I like one-size-fits-all these days... so all stories have to be the same size and you send back any stories that are too big... it's just a little easier for everyone to comprehend), pieces that are small enough go into the backlog, pieces that are not small enough are broken down again, then another meeting to prioritise all of the stories, then another meeting to build a sprint. It's a lot of work and sometimes it's hard to get the commitment to doing it (BTW, developers only go to the estimation meeting... this is incredibly important for reasons I won't get into).
One of the signals that you're going to run into trouble is that there is nobody with good XP knowledge at a high enough level to get the stakeholders to actually show up to the meetings. Once you get a good rhythm going, I find it's pretty easy to sustain, but breaking that barrier is a bit difficult and you need that champion in management. The way it's worked best for me was when I was working as an XP coach and I reported directly to the director, rather than through the management chain. Even though I don't do management consultancy and don't need to hobnob with the guys in the stratosphere, at the beginning I often do need a stick.
Just putting those two things in place will go a long way towards making you successful. It's the first thing I do on a team and if I can't manage it relatively quickly, then I know it's not going to work out. There may be other ways of being successful, but I don't know what they are. I'm always very candid about that when I join a team.
Apart from that stuff, from a more technical perspective I'll tell you one surprising thing. I've never been successful doing continuous deployment using XP. Never. I just don't think it mixes very well. This is probably one of the most innocuous ways to shoot yourself in the foot. Partly it's due to the above: it breaks the rhythm of development because now you have stakeholders who are not content to wait for the end of the sprint to get what they want. So if you must have continuous deployment, then I think XP is not for you (caveat: as always, perhaps there is a way to make it work, but I haven't found it).
Further to that (and I've thought about it a lot), I think one of the big advantages of XP is that once you have your rhythm in place, you have at least 3 weeks from proposing some work to delivering it. This will seem awfully slow to a lot of groups these days, but in the context of the 90's this was pretty darn quick. But that 3 weeks allows a lot of dust to settle. Stories, despite how they sometimes look, are never in isolation. The thing you are building needs to have an internal logic. If you rush the work into the build, you don't have enough time to see it properly within the context of what you are building. It took me a long time to really understand what problems really fast development brings and I always felt like we were missing analysis, even though we would work hard at analysis. I now know that it's simply time and context.
Another thing that's kind of crucial on an XP team (IMHO) is the concept of ownership. It's kind of strange because one of the values is no code ownership (and I really believe in that). However, for requirements and other things, you need a single source of truth. I call the person playing the customer role the "Customer Proxy". It's actually really important that this person owns the requirements. If there is a question about requirements, then that person answers it. This is an incredibly difficult job and it's a full time job. So one of the things I insist on an XP team is that you have a full time customer proxy and that they only service the single team of 6-8 developers. Of all the crucial roles on a team, this is the one that is hardest to sell to management in my experience. Management has a very difficult time understanding why they have to spend a full time salary for someone who doesn't produce any code, or do any selling, or go to any trade shows, or whatever.... But you need that person who knows everything there is to know about the thing you are building and who can tease out the logical connections. It's also critical (critical) that they can answer questions from developers immediately. Oh how much time is wasted because developers don't know what they are building? Interestingly, on my most successful XP team, the PGMs all declined to take that role and foisted an intern on me (who was studying to be an architect). He was amazing. Subsequently, I've stolen people from documentation and other areas to fulfill this role. It's important to understand that this is a creative role, not a managerial role, so I've found it best to look outside of the normal stakeholders for this work (and TBH, I've rarely had a PGM who could do it and never had a manager who could do it -- so grab that intern and thank your lucky stars ;-) ).
I haven't really gotten into the technical side of XP at all and I've been typing for a while, so I think I won't go there. If you are interested, I'd be happy to type some more another day :-), but I'll leave you with one last management issue that I think is really important to resolve very early on: reporting.
XP never had standup meetings. If you have co-located team members working during core hours (required IMHO, and also a divisive issue, but I can talk about it another time), there is absolutely no need to have a standup. However, sometimes some of the developers want to have it (hard to believe, but it happens!) I do not allow any PGMs, the customer proxy or any manager to attend a standup meeting! That breaks every dynamic of the meeting. You can imagine I get a lot of push back for this, but I never cave. Management of any sort breaks stand up meetings. If you have a coach (and I recommend it), then they can facilitate the meeting, but other than that you want the developers to be able to talk about whatever they want to talk about. You explicitly want to avoid any discussion about status. Status discussions cause your developers (either consciously or unconsciously) to change their behaviour as developers -- virtually always for the worst.
All status must be visible through artefacts produced by the normal working of the team. I'm really super serious about this and I will even go and chastise managers who wander over and say, "How is X going?" If you can't see how X is going by looking at the sprint chart, then we need to fix the sprint chart.
I had more to say, but bumped into the "That message is too long error". Sorry!