Strengths versus "Other"
Practical, high-impact development techniques, many of which are easily and sustainably adopted by developers (e.g., continuous integration, test-driven development).
Emphasizes customer participation and steering.
Evolutionary and incremental requirements and development, and adaptive behavior.
Programmers estimate the tasks they have chosen, and the schedule follows this, not vice versa (i.e., scheduling is rational).
Emphasizes communication between all stakeholders.
Emphasizes quality through many practices. Test-first development, continuous integration, and team code ownership are examples.
Clarifies what is an acceptable system by requiring the customer to define the acceptance tests.
Daily measurement, and developers are involved in measuring and defining what to measure.
Every iteration, developers get practice (during the Planning Game) identifying tasks and estimating them, leading to improvement in these vital skills.
Frequent, detailed reviews and inspections, as all significant work is done in pairs. Inspection is strongly correlated with reduced defect levels.
 Could be viewed as a weakness, strength, or deliberate desirable exclusion, depending on point of view.
Requires the presence of onsite customers (or proxies). This is often not possible, and their absence makes difficult or impossible the practice of "oral requirements" and using short story cards. XP has no standard solution for written requirements. That takes us back to other methods, such as the UP, which have a mechanism for iteratively recording detailed requirements.
Relies on oral history for knowing the design and requirements details. This has limitations related to quickly helping new members, or scaling to larger projects.
The XP practices are interdependent and mutually supporting. It isn't really a pick-and-choose process; most need to be done. Yet, people avoid some in the urge to avoid "unnecessary" steps, and thus failure ensues. Then, XP is unfairly criticized.
No standard way to describe or document the software design as a learning aid.
Some developers do not want to do pair programming.
Many projects will need a set of documents other than code. XP does not define what these may be, and thus each project may create ones with similar intent, but varying names and content. In other words, no common, standard workproducts that are shareable with common names across projects. This impedes reuse of workproducts and impedes a common workproduct vocabulary in larger organizations.
Lack of architecture-oriented emphasis in the early iterations. Lack of architectural design methods. XP advocates claim simple design and refactoring lead to the same goal.