Behind the scenes of The Art of Agile Development's Preface.

The Art of Agile Development started out as an update to the Extreme Programming Pocket Guide. I wanted to get my feet wet in the world of book publishing, Kent Beck's Extreme Programming Explained, 2nd edition had recently come out, and creating a second edition of the pocket guide seemed like a good way to test the waters. Shane was open to the idea (he's been a good friend of mine for years), so off we went.

O'Reilly wasn't that enthusiastic. Pocket guides are small and thin; they get lost on the shelf. They don't cost much, so they don't make much money even when they are sold. Overall, they're a hard book to make money on. O'Reilly suggested a larger, standalone book instead; I happily agreed. (Shane also agreed, but I'm not sure how happy he was; he had just finished a book and I suspect he wanted a break.) It turned out to be a good idea, though: it allowed us to make a much better book... and we needed the space.

Somebody--I believe it was Mary Treseler, our editor--suggested that we call the book The Art of Agile Development. I resisted at first, since our focus was on XP, and I suggested that we call it The Art of Agile Development: With Extreme Programming instead. (You can still see the subtitle in some online catalogs.) It was a clunky alternative, so we tested the waters by leaving the subtitle off of our online discussions.

We got a huge amount of flak about the title. The focus was on XP, so why call it the art of "agile?" We kept having to defend our decision, and Shane and I talked about just keeping the subtitle. But with each email and conversation, our understanding of what we were trying to accomplish--and why the book really was an "agile" book, not just an "XP" book--became more clear.

At some point--November 26th, 2006, according to Subversion--after seeing yet another of these criticisms in an email thread, I whipped out a preface explaining how our book was really about mastering agile development even though it focused on XP. It was one of those great writing moments: everything came together in one smooth flow. That preface is nearly unchanged in the final book.

The preface crystalized what we had been thinking for a while: that in order to do agile development your way, you have to do it some way first. Any way, really, as long as it's complete, clearly defined, and truly embodies the spirit of agile development. That the road to mastery is Shu, Ha, Ri... and our book was primarily a Shu book, with a strong emphasis on getting to Ha.

This realization ended up shaping the entire book, which now follows a clear Shu-Ha-Ri progression. Part I sets the stage by providing a clear definition of when our version of XP will work for readers and when it won't. (As Alistair Cockburn reportedly says, "One Shu doesn't fit all.") Part II is an in-depth cookbook of practices for the Shu-level reader. Part III discusses agile principles and breaking rules for the Ha-level reader. Then, in very last paragraph of the book, we talk about achieving mastery, or Ri, and throwing the book away.

People ask me what it was like to post the entire book online for open review. It could be frustrating at times, especially when so much attention was paid to seemingly small things like the wording of the title, but it really made us think through our decisions. In this case, in particular, I think the frequent discussions helped us to clarify an area where our thinking was particularly muddy. It forced us to give up the ghosts of our original intentions and finish the transition from Extreme Programming Pocket Guide, 2nd edition to The Art of Agile Development.