I certainly belive that
you should choose your process to fit your people and your problem, and that there are room for many processes. XP is just one to consider, and it has definite boundaries: small (up to a dozen) teams, co-located teams, and volatile requirements.
It's also important to grow your own process. Even when you use it, XP is only a starting point - a seed. I've got an article in the works on how variability and self-adaptivity work with XP. I should get it onto my site shortly.
Martin
author of:<br /><a href="http://www.amazon.com/exec/obidos/ASIN/0201485672/electricporkchop" target="_blank" rel="nofollow">Refactoring : Improving the Design of Existing Code</a><br /><a href="http://www.amazon.com/exec/obidos/ASIN/020165783X/electricporkchop" target="_blank" rel="nofollow">UML Distilled, Second Edition: A Brief Guide to the Standard Object Modeling Language</a><br /><a href="http://www.amazon.com/exec/obidos/ASIN/0201895420/electricporkchop" target="_blank" rel="nofollow">Analysis Patterns : Reusable Object Models</a><br /><a href="http://www.amazon.com/exec/obidos/ASIN/0201710919/electricporkchop" target="_blank" rel="nofollow">Planning Extreme Programming</a>