Summary

This book provides an excellent field manual for implementing agile software techniques. It includes practical advice with extensive cross referencing to theory and principles that are core to agile methodologies. I would recommend it to individuals in the agile team lead/coach role, or senior developers in general interested in agile in practice. Its primary focus is on Extreme Programming (XP), with some references to Scrum and other techniques not associated with a particular agile methodology.

Review

The Art of Agile Development is broken up into three parts: Getting Started, Practicing XP, and Mastering Agility. The first part is the smallest, and provides a brief (70 pages) introduction to what has come to be known as Agile. One technique the authors use throughout the book that I found useful was the use of parables – stories of developers in particular situations. For instance, Chapter 3 on Understanding XP begins with a recent graduate arriving for his first day of work at an organization using XP. These keep the text from being too dry, while providing an excellent way to convey information about how things really should work in a real environment.

Also in Chapter 3 (pages 25-28), the authors provide a breakdown of agile practices they cover in the book compared to those described in other XP books, as well as in Scrum. This provides an excellent reference for anyone new to the many terminologies involved in agile software development, or a Rosetta stone for a Scrum Master looking to learn the terms used by XP and other agile teams for some of the Scrum terms.

In the course of reading the book, I made a number of notes of particularly insightful (IMO) quotes and ideas. I’ll list some these here, in an effort to convey as succinctly as possible some of the value of the book:

• “The best developers don’t just find something that works and use it; they also question why it works, try to understand it, and then improve it.” – Chapter 5
• Ping-Pong Pairing: “…one person write a test. The other person makes it pass and writes a new test. Then the first person makes it pass and repeats the process by writing another test.” – Chapter 5. This is an excellent technique that we use in our agile consulting company in Ohio.
• How to Achieve Nearly Zero Bugs (chapter 7 – too long to do justice here)
• Bug/Defect Definition: “A bug or defect is any behavior of your software that will unpleasantly surprise important stakeholders.” – Chapter 7
• Root Cause Analysis (chapter 7 – a great lean practice)
• Version Control Tips and Continuous Integration (chapter 7)
• The Planning Game with great examples (chapter 8)
• How to Improve your Velocity (chapter 8)
• Iteration Planning and Planning Board (kanban-esque) (chapter 8)
• How to deal with being in constant “fire fighting” mode (chapter 8)
• Automated Testing, TDD, and Fit (Chapter 9)
• End-to-End Tests: “In some cases, limitations in your design may prevent unit and integration tests from testing your code sufficiently. This often happens when you have legacy code. In that case, end-to-end tests are a necessary evil. Think of them as technical debt: strive to make them unnecessary, and replace them with unit and integration tests whenever you have the opportunity.” – Chapter 9, emphasis mine.
• Optimization Tips: “It’s easy to guess wrong when it comes to performance.” – Chapter 9
• Exploratory Testing and Heuristics-based exploration – Chapter 9
• “Want to deliver real value? Take advantage of what you’ve learned [so far on the project] and change your direction appropriately. Adapting your point of view to welcome changing requirements gives you great opportunities. Delivering value to your customer is your most important job.” – Chapter 14

Beyond a wealth of practical tips and advice, the book is also valuable as a starting-point for further research and reading on the subject of agile software development. It includes nearly 6 full pages of references to other books and articles on the wide array of topics covered. Any topic which the reader feels needs more depth is almost always accompanied with a reference to a book on the subject. I don’t know whether this book has found its way into any college classrooms, but this feature alone would make it a prime candidate for such use.

After reading and digesting the material in this book, a software team should be fully prepared to adopt XP and begin delivering better software faster using this agile approach. XP is not a panacea, nor is it easy for those who are new to it, but Shore and Warden point out many of the usual hang-ups and pain points associated with learning to practice XP, ensuring that such obstacles should be known and surmountable by their readers.

About the Book

Originally published on ASPAlliance.com