Don't be deceived by the fact that there is more text in this appendix dedicated to the weaknesses of XP than to its strengths. The strengths more than balance out the weaknesses, and as with any software development method, it is easy to poke holes in the implementation. The practices of XP are an excellent place to start, but XP should not be viewed as a complete methodology.
The most critical element that is missing with XP is the notion of continual learning and improvement in the methods used by the team. Every team is different because it's made up of different people and faces a different ecosystem. Hence, teams need to place an emphasis on continual improvement of their methods through regular retrospectives and methodology changes that are consistent with the principles (mindset) of sustainable development. This gives them a more healthy balance between software and non-software and should encourage them to continually look for new ideas. If your team is using XP, I highly recommend that you try out new practices as required while staying true to the values. XP unfortunately gets too much attention in the software community. This is both good and bad: good in the sense that XP has caused a large number of developers to question the traditional methods of software development, and bad in the sense that there is more to agile development than XP. There are quite a few other agile methods, and each offers different agile practices or viewpoints that should be consulted and incorporated as a team continually looks for new sources of ideas and inspiration.