Ha ha! That's a very nice cartoon. I really like it :-)

Picking practices is very hard because it is highly dependent upon the people. Personally, I prefer to use a mostly unmodified set of XP practices. As there are many confusing descriptions of these practices I encourage you to look at this one: http://c2.com/cgi/wiki?ExtremeProgrammingCorePractices

As I said, I don't really modify these practices except for the coding standard. That is to say, I have one, but I actually prefer to appoint an arbiter for coding standards rather than maintain a document. It reduces a potential point of politics where people try to game the coding standards to get their way (yes, unfortunately it happens... sigh).

One of the problems with this is that programming practices are very subtle and are surprisingly interdependent. Kent Beck has talked about trying to create the minimal set of "generative" practices: practices, which when followed, generate the behaviour you want without needing to state it. I think this is a good idea, but it requires that you truly understand how the practices work together.

A good example is testing. Unit testing has gotten reasonably popular. Some people focussed on the word "unit" and decided that they should mock all of the collaborators in their tests. Then they found that their tests were brittle when they refactored. Quite a few people were happy with this and just decided not to refactor very much because, hey, they thought about the design up front a lot and probably got it right. Right at that point, you have broken your XP practices because XP practices require constant incremental design.

Other people will think, "I'll replace these unit tests with integration tests" because they aren't as brittle. But integration tests require a lot of set up with lots of things in motion. So you end up with slow tests. It's fine because, hey, 0.1 seconds is still pretty damn fast for a test, isn't it? But then because you need to find all the corner cases, you write lots and lots of tests and your test suite takes an hour to run. Right there you have destroyed your XP processes because you can't do TDD any more.

Of course, the answer is that "unit testing" was always just a word and you shouldn't "test" units like you would a black box. It goes on and on and on. It's super subtle and really easy to get wrong. However, because the practices are generative, you can actually test that you are doing the right things in the manner I described above. Breaking one of the 12 XP practices will break at least one of the others. It's a matter of keeping you eyes open to the things you are breaking.

Which all reads like an advertisement for XP. Rest assured that my biases are simply formed because this is what I have experience with. I'm sure that other successful shapes exist. Indeed I often work with teams that are not equipped to handle all of XP. In those cases I try to find alternative approaches. I meet with varying degrees of success, but have never even come close to "hyper productive" without full on XP.

You next question is a good one. How do I consistently apply the practices? Personally, I practice a lot (I try to put in at least an hour a day outside of working hours). I do katas and work on side projects. The group I work with is also keen on practice and we have "hack time" and organized katas during work hours. But just like in sports, training is fine but there is no substitute for the real thing.

Usually there is a lot of pressure when you are working. At the end of the day, though, the programmer is programming and has a lot of power to decide how the practices work. The question always come down to: are you willing to do it?

I've worked as an "agile coach" quite a bit (although I always do a lot of programming). One day one of my younger colleagues came up to me and said, "I could fix this quickly or I could fix this right. Which one should I pick?" I answered, "Are you expecting me to suggest you choose the wrong solution?" He happily went back to his task. Of course, my head is now on the block if we get it wrong. :-)

Are you able/willing to make the same kinds of decisions? It is not possible in many situations. This can be fine, but my experience is that one will not be able to build an amazing team if you can not.

One last thing, which may sound patronizing. When I was about 15 years in, it was the time when I first started realizing how everything fit together. It is very encouraging for me to hear that your are on that same search. I think you will find what you are looking for very soon.