After reading the recently released XP book and reviewing many of the Wiki Extreme Programming pages here are our comments:
What we agree with
Many of the primary tenets of the Rational Unified Process are part of XP. We've been using the Unified Process for many years and see the value in most of their recommended practices. We view some the new ideas in XP to be the strong emphasis on pair programming, unit tests, and refactoring.
Synthesizes viewpoints of business and development.
Helps improve design/cross train/mentor and results in constant code reviewing.
Uncovers many more defects earlier and improves confidence in system quality.
Keeps system small and clean and extends its life.
Exploration/Productionizing
Gets system out early and then maintenance releases evolve product.
What we are unsure about
How is a User Story different from a Use Case - anything new here?
How to capture non-functional requirements like performance criteria?
Pair Programming (For discussion, see Thoughtful Reactions Pair Programming)
How to engage "lone wolves?"
There have to be more guidelines for this. Sometimes a module is too small for two people and one person can better handle it. Also, using a fairly thorough design/code review regimen, you can make sure no one gets away with shoddy work. Finally, if you're working on a time-critical piece, sometimes an inexperienced partner slows you down. The concept of pair programming is not universally applicable.
During interviews, we are keenly interested in what candidates have personally accomplished. Weak teammates can require lots of hand-holding and their lack of contributions can be hidden by pairing.
Aren't private offices more productive? (see Peopleware On Shared Spaces)
Must be controlled otherwise you're constantly refactoring and never adding. No code or design is ever perfect - you have to draw the line somewhere if you have a product to deliver!
There is always some overhead for releasing. There is a point (maybe three weeks) beyond which it makes no sense to shorten iterations.
Not very common in our industry!
And just because something is uncommon, we're willing to live without it, give up on ever having it and downplay the importance of getting it back? I have never worked for a company or organization that routinely required me to work overtime and I see no reason to start now. Neither does my family.
Overall
We are unconvinced that XP works well for large teams or projects (Large Extreme Programming) or even small projects that do not have enough experienced, knowledgeable, and disciplined developers. No methodology will work without the right people
Role of metrics is not well-defined - which ones to use and how to gather them?
What we disagree with
Minimal Up Front Design (UFD)
Not the most efficient way to write non-trivial software - system will take longer to build without UFD! (See Evolutionary Design Is Wasteful)
Doesn't encourage experience or intuition to play a significant role in design. Design Patterns are all about leveraging others' experience.
Precludes synergistic participation of team members in design. (see Thoughtful Reactions To Minimal Design Up Front)
How to prevent a closed architecture that is not flexible to change when you do minimal UFD? Constantly refactoring the architecture can be very costly.
Design documents are very helpful for conceiving and explaining complex pieces.
Visual models (UML) are a superior way of communicating non-trivial designs.
Are non-coders (managers, analysts, testers) supposed to understand the system by reading code?
Thrashing can occur by conflicting refactoring efforts. People can get upset with the changes.
Without a concept of code ownership, we foresee less motivation for pride in one's work. (Perhaps a complete loss of pride.)
May be very difficult and time consuming for large, distributed systems.
Unit Tests (For discussion, see Thoughtful Reactions Unit Tests)
How to write/automate them for large, distributed, GUI-based systems? (See Gui Testing)
We're not convinced that building unit test cases before coding is a good idea. XP discourages design documentation but suggests building executable test cases before coding! Talk about a heavy artifact that needs to be constantly maintained. In most cases, test programs that are written prior to design/code would be obviated by the time the classes are implemented.
Oral Communications (For discussion, see Thoughtful Reactions Oral Communications)
Does not scale well (either increased number of people or distributed offices).
There is much imprecision in pure verbal communication - misunderstandings occur regularly. Imagine relying only on oral communications for architecting bridges, buildings, or airplanes!
-- Suvajit Gupta & Ali Pashaei
with Sagavista R&D team, SAGA Software Inc.: www.sagasoftware.com 
Fabulous! Thank you so much for the thoughtful response. There is so much here I can't think of how to begin responding, if a response is expected. Let's try starting a page when we discuss one of the "disagree with"s. -- Kent Beck
Yes we would like a response. Actually we would like to start a dialog. We are trying to implement some XP practices, but have concerns. -- Suvajit Gupta & Ali Pashaei
Response Links: Travel Light, Thoughtful Reactions Pair Programming, Thoughtful Reactions Unit Tests, Thoughtful Response Collective Code Ownership
See original on c2.com