Agile development is not a specific practice or process in itself, but more of an idea for how software development should proceed. Its seed is the The Agile Manifesto, signed by many of the giants of modern software development way back in 2001, and many processes and practices fall under its umbrella. The company I recently worked for practiced Scrum. In this book, the focus is on Extreme Programming. So the title is a little misleading, but then again, I likely would have passed over it had it been called The Art of Extreme Programming. Like many, I’m sure, I have been instantly turned off by the idea of pair programming, and in my head XP == Pair Programming, and that was the end of the story.
So I’ll chalk it up to good fortune that I did pick up the book, and somehow managed to find the time to read it from cover to cover.
The Art of Agile Development is essentially a textbook for successfully implementing Extreme Programming for your software project. It steps through each element of the system, provides alternatives, and emphasizes in no uncertain terms that you may not pick and choose practices to create some Frankenstein monster of Agile Development and expect it to work. Each practice supports and reinforces the others. The meat of the book is in Part 2: Practicing XP, whose chapters are Thinking, Collaborating, Releasing, Planning and Developing. These chapters are specific and detailed, and even offer Mini-Etudes to get you and your team into the mood.
I have to admit that by the end of the book, I’ve become a convert to Extreme Programming. In the pages of this book, I saw some answers to many of the issues that have frustrated me in my team-work. I have a new perspective on pair programming, and I think I could get over my “don’t look over my shoulder” issues long enough to give it a fair shake. Now, as a solo-developer, it’s impossible for me to implement most of the practices (dual-personality pair programming?), but I now feel I have a solid understanding of the process and would be perfectly willing to sign on to a team that followed this branch of Agile Development. Notwithstanding the warning about picking and choosing elements, I also plan to implement as many of these ideas as I reasonably can in my own work.
Unless you’ve actually practiced Extreme Programming, or you’ve already read enough about it to have a firm grasp on the concepts, I recommend reading The Art of Agile Development before you make any judgements or succumb to prejudiced preconceptions of thorny issues like pair programming or open “bullpen” workspaces and dismiss XP as a hokey religion.
P.S. It looks like most of the book’s text is now available online at the book’s web site: http://jamesshore.com/Agile-Book/