Search in Book Reviews

All the other books on XP that I have read, or browsed as they crossed my desk on the way to other reviewers have been seeking to convert the reader to the joys of XP in some way or other. This book is different in that it seeks to question all aspects of XP. In a way this shows the degree to which XP has taken root. Pete McBreen seeks to challenge XP whilst respecting its objectives. Kent Beck (the creator of XP) says this in the foreword he provided:

Pete claims that the more he looks at XP, the smaller he sees its scope. I see just the opposite. I won't refute his argument point by point- this is a foreword and I'm supposed to be polite. I will suggest that as you read this, you keep in mind one mistake of early XP thinking for which I am entirely responsible - "the customer" doesn't meanone person. It means a team, as big as or bigger than the development

Part I of the book consist of a single short chapter in which the author takes an overview of the claims of XP, the evidence for its success and reasons why you might adopt it.

Part II consists of five chapters that are largely aimed at reminding the reader of the alternatives as well as the aims of having a methodology at all. He spends a fair amount of time reminding the reader that XP is only one of a group of methodologies that have come together as 'the Agile Alliance.' Those that have not previously come across this should take time out to read a book such as the excellentAgile Software Developmentby Alistair Cockburn (0 201 699 69 9).

The author then moves on to the main parts of the book (III& IV) in which he examines XP in detail. Here he suggests things that other methodologies could learn form XP as well as how XP has itself changed and learnt from experience. As I was reading these sections it crossed my mind that there is a degree of irony in the XP adherent who considers XP to be the one true way; one important point of agile methodologies is to be able to adapt to the needs of the moment and that means you should recognise when an XP doctrine is inappropriate. This book will help those who do not have entirely closed minds to understand that. If you cannot recognise that having your beliefs challenged makes you beyond salvation then this book will do nothing for you whether you are attracted to or repulsed by XP.

Part V of the book concerns understanding the XP community. Note that this is relevant to both the outsider looking in and the insider. Perhaps it is more important for the latter because it reminds them that there is a world outside the closed development team in which they work. One very interesting chapter in this section is chapter 21Transitioning Away From Extreme Programming. Here the author tackles the problem of how to break XP devotees away from it. It is a short chapter but contains food for thought. Here is what the author writes early on:

This is an interesting question, because XP is very appealing to programmers but is not suitable for all kinds of projects. Yes, it may be feasible to restructure your organization and projects to make them more suitable and amenable to Extreme Programming, but for some projects you may have to find an alternative process. In doing so, you are likely to face resistance from your XP teams because the sense of control over their work that Extreme Programming gives is very addictive. Very few people who have worked as part of a well-functioning XP team have expressed any interest in using a different process.

The book concludes with Part VI that consists of two short chapters giving guidance as to whether XP might suit your needs, and how to choose a project to start XP on.

I think this is a book that deserves to be widely read by those whose minds are open enough to make choices based on reason rather than emotion. Agile development is much liked by programmers because it makes the process closer to the way their instincts say it should be. XP in particular is a methodology that takes over the thinking processes of its adherents and too often blinds them to the essential purposes of a methodology. The outsider looks on and sees something akin to religious fanaticism, the insider cannot see how anyone could not appreciate how good XP is. For the devotee, failure must mean lack of sufficient devotion and for the antagonist success is just coincidental. This is a book from which programmers of goodwill can learn and in doing so apply the lessons to what they actually do. This book is an excellent read and food for much thought.