The essays range from straightforward discussions, such as striking a balance between XP and existing methodologies--patterns for example--to the practical experiences of teams retrofitting testing methodologies during a project. Many of the papers address issues arising when trying to incorporate XP features alongside existing programming practices. This is likely to be the reality in most programming environments where managers are reluctant to abandon existing methods without proof of concept.
Perhaps more importantly for the target audience--those running software projects--there are detailed studies of costs and benefits in here. Among the findings discussed are that the number of man hours needed to produce the same code is similar for pairs and single coders--but pairs introduce 15 per cent less errors; and errors are far more costly to eradicate than introduce.
No one should expect a single approach to suit all projects though the essays in Extreme Programming Examined successfully argue for wider acceptance of the XP approach. This makes sense. When well-implemented XP appears to enable programmers to produce better, cheaper code to a deadline. You can't afford not to understand how your competitors are becoming more competitive. --Steve Patient