This is another book that has been on my reading list for some time, especially because part of my current job involves helping a large team make the transition from traditional development to a more agile approach.

The book focusses on the Extreme Programming (XP) agile practices, outlining each one in detail, and stating why it is included, which other practices it supports, and what, if any, are the alternatives. The parts that describe which other techniques are supported is incredibly useful, as often I have found that people are very willing to accept and implement some of the XP practices, but hesitant for some of the other ones. Being able to say “well this technique supports that other one you like in this way” can be helpful.

As a developer I have often found myself focusing on the technical aspects of agile, and whilst XP champions those it was good to get a deeper understanding of some of the planning and management techniques, and how they can help.

The book starts with descriptions of what Agile is, how it can help, and an overview of how to adopt the XP practices, it then goes on to explain each of the XP practices, splitting them up in to 5 sections: Thinking, Collaborating, Releasing, Planning, and Developing. Finally it wraps up with sections describing how to ‘master agile’, how to take the principals of XP and use it to continually improve your processes, so that you can deliver even better value to your customers.

The book also contains a series of what is referred to as mini-études, small exercises that teams can go through to develop skills in various aspects of XP and whilst I didn’t practice them myself, they seemed like they would be useful for introducing the practices to teams that are unwilling to commit to changing their development approach entirely.

I’d say this book is pretty essential reading for any manager or senior developer who wants to help lead an agile team, but it’s also really useful for developers that want to be part of an agile team. Much of agile is about improving communication and I find that a deeper understanding of other peoples roles helps improve communication greatly.

There are some places where talk of agile is met with sneering derision, generally I find that this has come from being exposed to one too many process-laden ‘not really agile’ frameworks that don’t work. Often this seems to stem from taking only some of the XP practices (usually not the technical ones) and half applying them without understanding that they are all part of a whole that works together. I would love to buy a copy of this book for every developer that has had the misfortune to work with a half-baked agile approach so they can understand what it’s meant to look like, and just how great working in that sort of environment can be.