Rod Hilton's rants about software development, technology, and sometimes Star Wars

The Art of Agile Development” by James Shore and Shane Warden is a book that is primarily focused on explaining Agile to people who want to adopt Agile software development practices for their team. The bulk of book is divided into sections based on a categorization on agile practices. There is a chapter on practices that help with thinking, one for collaborating, one for releasing, one for planning, and one for developing. In each of these chapters, there are sections devoted to a specific practice, such as “pair programming”. The sections describe how to do the specific practice, what benefits it offers, what challenges you might face when adopting the practice, and so on. Usually it also has some frequently asked questions about the practice (with answers, of course) and some suggestions for alternatives if you have a reason to not adopt the practice.

First and foremost, I need to mention my biggest criticism of the book. It has one of the most misleading titles I have ever seen. This is NOT a book on Agile. It is a book on XP, one of a few different flavors of Agile. The correct title for this book is “The Art of Agile Development using XP.” This is worth mentioning for a few reasons. First of all, XP’s practices are pretty hardcore. XP’s engineering practices are all extremely useful, but most of the time when a company or team resists Agile, it’s because they are resisting a typically XP practice, such as Test-Driven Development or Pair Programming. Personally, I’m a big fan of XP’s practices, but the fact of the matter is that any team that wishes to become Agile will likely find the most resistance if they try to adopt XP, so it seems misleading to sell the book as an introduction to Agile when it is, in fact, an introduction to XP.

That said, this is an excellent book on XP. All of XP’s practices are covered in just the right amount of detail - giving you enough information that you can adopt the practice, but requiring that you do additional research about the ones that interest or challenge you the most. This allows the book to be a pretty quick read in general, which is beneficial for a team wishing to adopt XP practices soon. This level of detail does have one disadvantage, though: by staying largely in the realm of hypotheticals and ideals, I often found myself thinking that the authors were being naive and idealistic about how easy some practices were to adopt. This made me somewhat more skeptical of the book than I would have been if more detail had been offered, but ultimately I felt the level of detail was right; I did my own research online about some of the things that challenged me.

One of the most annoying aspects of the book are the “examples” that are sometimes provided. Usually these examples provide a sample conversation between stakeholders as they illustrate the effectiveness of an XP practice. These little micro-plays are so exaggerated that it often felt like reading the script to a bad company training video. After a few, I found myself skipping them.

I learned an awful lot about XP practices, particularly Pair Programming, estimation techniques, and incremental design. I felt that a number of these topics were better covered in other books, but “The Art of Agile Development” seems like it is meant to be an introduction to XP. In fact, every section generally provided a list of books that covered the section topic in more detail, so I think the book is meant to tease you by design.

I recommend this book for a team that wishes to adopt XP as quickly as possible, but I cannot reiterate enough that this should be the first, not the last, XP book you buy if you wish to become an effective XP team.

comments powered by Disqus