The Art of Agile Development

James Shore, Shane Warden (2007)
Review date: April, 2009

First a word of warning. This 400 pages long book is very information-dense. Its pages are packed with two professionals' view on XP, and an incredible amount of useful information and experience gathered in the field.

Regardless of its title, this is a book on XP. However, it pretty much sums up everything that could be related to agile software development.

On a coarse-grained level it's divided into three sections called "Getting started", "Practicing XP", and "Mastering agility". These contain roughly five chapters each. Every chapter, in turn, discusses 3-9 topics. All topics start with a discussion followed by questions, results, contradictions, alternatives, and references to other reading material.

Chapter 9, for example, treats incremental requirements, customer tests, test-driven development, refactoring, simple and incremental design, spikes, optimization and exploratory testing, and is about "Development". That's one chapter.

This kind of entropy pretty much makes writing a sensible summary meaningless.


Given my current experience, this is the best book on software development I've read so far. Including those not reviewed on this site! Regardless of how one feels about XP and agile practices in general, this book is overflooding with experience and treats all aspects of software development that you might ever need.

The list of shortcomings is so short that I'm gonna do away with it immediately: This book's kind of information-density makes it hard to read. Hard as difficult to absorb. Also, when the authors encounter difficult situations they say "Ask your XP mentor about it". They don't need to do this, since the book contains advice on pretty much every situation you're likely to encounter. That's it for the minuses!

Talking about this book as a whole is difficult, as it contains numerous sections and subsections packed with information. The approach I'm going to use here is focusing on topics that were close to my heart at the time of reviewing.

Without making any claims on presenting an interesting result, the book starts with a table where XP and Scrum practices are aligned against each other. The way the table is organized makes the reader draw the conclusion that Scrum is a subset of XP. This fact isn't really highlighted in the book, however it very much corresponds to my own experience. Just slicing user stories into small pieces and expecting them to be magically solved by the team isn't enough. You need many of XP's practices to make it work (though this isn't discussed either really).

A recurring theme is technical debt. The authors repeat that technical debt should be avoided at all cost, since it makes you non-agile in the sense that it has a negative impact on your velocity and confidence. Technical debt in legacy code should be paid of as soon as possible. Finally, reducing technical debt is described as the single best activity needed to achieve good quality.

Another topic, which seems to be recurring, probably because I want it to, is the definition of done. The authors demonstrate extensive experience of the traps and pitfalls of actually releasing a piece of software, and emphasize the difference between "done" and "shipped". A good list of done criteria is included, of course, while readers are also warned about inflating team velocity by including not "done done" stories. Couldn't agree more.

A third, unfortunately not recurring topic, is the essence of having an active on site customer. Such customers help in clarifying requirements and are an absolute requirement for informal requirement gathering. In the absence of such customers user stories do not replace proper requirements. They must be extracted and formalized in some other way!

These three topics were most interesting to me. There are many more. Here are some samples in no particular order.

  1. Don't keep a bug database! In XP bugs should be an anomaly. Having a bug database legitimizes their existnce.
  2. Branching is in fact code duplication!
  3. Daily iterations. If your organization's that messed up that you can only act in response to alerts and constant interruptions, have daily iterations.
  4. Research time. Developers should have some time to learn new things during the iterations slack. Right! What slack?
  5. Mock objects are not always good. Proper abuse makes you write tests that test the wrong thing. Implementation above behavior.
  6. Planning horizons are discussed, and a risk multiplier table is included. These things are not controversial... in a book on project management. They seldom make it to books on software.
  7. Every project has a fixed amount of disappointment. Iterative planning portions it out evenly, instead of piling it up at the end of the project.

Finally, the authors claim that good design is often achieved by "being really anal about getting rid of duplication", and end the book with:

A good software design minimizes the time required to create, modify, and maintain the software while achieving acceptable runtime performance.

One can dig in the contents of this book forever. The points above are my preferences. Just read the book and decide what you like. Reading it is extremely well-spent time. As opposed to Kent Beck's rather vague and theoretical book on XP, this book is as down-to-earth as it gets.

Who should read this book

This book contains so many good practices that it should be read by everyone with the slightest interest in agile methodologies. In fact, non-agile practitioners will find many convincing arguments in favor of agile and XP here. Also, this is the book on XP.


  • 2015-09-29

    It's been almost one and a half year since I reviwed a book! I've been too absorbed by Writing my own. Anyway, I'm back with Jeff Patton's relatively...
  • 2014-01-04

    New category! Performance! Reviewed The Every Computer Performance Book. Check it out!
  • 2013-09-10

    Reviewed a book that' slightly less technical, but much more fun to read. It's I.T. Confidential.
  • 2013-08-13

    Reviewed yet another book on Visual Studio 2012 and TFS. I also created a "Microsoft" category and moved the other TFS book there from the "Tools"...
  • 2013-08-05

    Updated the FAQ. Included information about getting a book reviewed.