Review By: Tim Dugan
06/23/2010The Art of Agile Development by James Shore and Shane Warden is the most definitive description of Agile development that I have seen. It is ultimately very readable and very detailed. It's quite obvious that the authors put a lot of experience and research into developing this practical guide to agile development.

The book is organized into three major sections, "Getting Started," "Practicing XP," and "Mastering Agility." Each section builds successively on the previous to give the reader deeper understanding. The first two sections are useful to those just wishing to adopt some agile practices. The final sections is oriented toward fine tuning an organization that has lept fully onto the agile bandwagon.

For those familiar with previous publications on XP [Extreme Programming Explained, Beck] and Scrum [Agile Software Development with SCRUM, Schwaber & Beedle], the authors provide an interesting table mapping between the ideas and practices in those books and this one. This is a particularly good mechanism for demonstrating the completeness of this treatise.

And quite complete it is.

You will find information about XP practices, such as pair programming, informative workspace, stand-up meetings (i.e., Scrum meetings), "done-done," and so on. For the more seasoned team, there are descriptions on how to eliminate waste, deliver more value, and improve your processes.

For those not familiar with agile, it is worthwhile to start with the Agile Manifesto, extracted from the text in the form of these four value statements:

1. Value individuals and interactions over processes and tools.

2. Value working software over comprehensive documentation.

3. Value customer collaboration over contract negotiation.

4. Value responding to change over following a plan.

In conjunction with these values is a set of agile principles, too long to list here, but the first is "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." (I'll leave it to the reader to learn the remaining nine in the text.) Most every practice described in the text derives in some degree from these values and principles. As such, the text is principle-centered and focused to a particular end: good software development through agile development.

I liked a lot of the things I read in this book, and, as such, it's hard to pick a particularly good example. But one section that I just re-read is the one on "Trust". It suggests various strategies for building team trust. One example, "A good way to improve team cohesiveness is to eat together"—if employers are willing to foot the bill once a week to feed their team, they are likely to reap some benefits by developing a team with a higher level of trust.

Given all this praise, I have to admit, I am not whole-heartedly convinced of every aspect of agile as described in this text. Case in point: how to conduct retrospectives. This may be a little nit-picky, but activities like "mute mapping" tend to be dominated by certain personality types and, as such, not very democratic. And the practice of letting people have five votes to choose from the topics derived from the mute mapping seems to go against any fair scheme of voting I've seen…better would be to ask people to rank the catories or at least a top five.

Even though I see a lot of value in pair programming, I also have doubts about doing it all the time—as some coding tasks are so mundane and ghastly dull that to occupy two peoples' time with this code seems more like punishment than anything else. There has to be some acceptance that different personality types can handle differing levels of paired activities, and that certain types people probably cannot pair well with other types.

All in all, though, I have to say that this is an exceptional book and I recommend it to anyone who wants to be a modern developer of quality software.