I expect that our decision to focus The Art of Agile Development on learning XP, then modifying it, will be a source of criticism. Most books on agile development try to be agnostic and inclusive, giving equal time to practices from all of the major agile methods. In contrast, we're specific and exclusive.
This may seem rather antisocial, but I think it's one of our biggest strengths. As Shane and I were writing the book, we kept telling ourselves, "this is an opinionated book." We decided that when there were multiple ways of meeting some agile need, we would pick just one way of approaching the situation. We figured there was more value in being simple and straightforward.
I'd like to say that there were times when we really struggled to choose a practice. It'd be the politically correct thing to say. But, actually, it wasn't hard at all. In my consulting work, I see teams face the same struggles over and over again. Picking practices was more of a brain dump than a research project.
That's not to say that our approach is perfect. "Best practices" are a myth. The reality is, "practices that work well under a specific set of circumstances." The practices that work well for colocated teams don't necessarily work for distributed teams, and the practices required for distributed teams are often wasteful for colocated teams. One thing I really like about our book is that we face this reality: we spend a lot of time talking about the context of our approach, and when our "one way" isn't appropriate or needs to be changed.
Ultimately, the right method for your team is customized to the needs of your team. The question is, how do you get there? While assembling a method from a menu of practices has a natural appeal, I think it's easy to get wrong. The practices have interdependencies and make hidden assumptions. That's why we suggest starting with an existing method and customizing it.
Being opinionated and antisocial is just a bonus.