In an ideal world almost any methology will work and I can't help but feel but that this methodology is also suited to such a world. Extreme Programming concerns itself with the minutae of code development and appears largely to reject the notion of having an overall design. This approach dangerously weakens the concept of a there being a 'Big Picture' into which a system fits and overemphasises the idea that everything can be broken down into small independent units. Unfortunately it does't follow that if the parts work then so will the whole. Whilst the methodology is at its best in dealing with these small units it is weak on how best these units should be assembled and the combined constructs tested. Unfortuately it is rare that coding level problems affect a project as much as system level ones. Another problem with this methodology is that it generally ejects the customer from the development cycle. It's all very well going to the customer initially but, if you then pull the shutters down and only seek feedback whenever there is a new version, customer confidence will rapidly drain away. Frequently asking a customer "How does this version look?" doesn't garner confidence. There are good ideas put forward in the book too. The princple one is that of 'pair programming'. This can be useful when new ideas are being tackled, less so when dealing with the 'mundane' coding. Overall, the best ideas advocated in this book (forward planning, frequent testing, better communication, etc) are actually independent of the methodology itself and when applied as intended with any methodology would produce improvements.