This is my review of “Practices of an Agile Developer: Working in the Real World” by Venkat Subramaniam and Andy Hunt.
Content
Aside from introductory and closing chapters, each chapter of the book describes one of 45 practices that are important in achieving an Agile development environment (one reviewer suggested it be renamed, “45 Habits of Highly Effective Developers”).
Each practices includes:
- A practice number and title, for easy reference.
- An explicit statement of the reasons why we might resist the practice described (the Devil’s temptation)
- A discussion that explains the rational behind the practice and how to apply it practically, typically backed up by real-world examples
- A summary of the key message of the chapter (the Angel’s advice)
- The emotional outcomes of following the practice (What it Feels Like). This encourages emotional buy-in.
- Notes on how to maintain perspective (“Keeping Your Balance”)
Strengths
The language, typography and layout make it an easy read.
The division of the book into 45 practices means that:
- You can read it in digestible chunks
- You can dip-in to interesting chapters
- It is a good reference book
The thing I like most about the book is the emotional awareness of the authors. They recognise that development is as much an emotional experience as it is a technical one, and that communicating good practice needs to discuss the readers’ emotional needs as well as their practical ones. This applies to both the presentation and content of each chapter. As a result, I felt good about reading this book, and I feel good about trying out the ideas presented.
Weaknesses
One thing I disliked is that some of the “practices” described in the book are much more abstract than others. For example, practice #7 (“Know When to Unlearn”) is quite abstract in that it deals with a general attitude that you should adopt towards your existing practices. In contrast, practice #6 (“Invest in Your Team”) is much more concrete, in that it deals with the specifics of how to set up”Brown Bag Sessions” with your colleges. Now, there are both advantages and disadvantages of this variation in tone. On the positive side, the variety makes for a more interesting read, and if you’re taking a pick-and-mix approach to Agile it means that you are more likely to find a practice that you can experiment with at a level appropriate to your current team. On the other hand, it makes the practices a little more difficult to introduce in a systematic way.
The biggest failing of this book is that it does little to integrate the various Agile practices. Now, these practices can adopted independently, and this book does a lot to help you explore them individually. Clearly, then, suggesting that they are reliant upon each other would have been a mistake. On the other hand, getting everything working together isn’t always easy: a little more guidance in that direction would have been very welcome.
Conclusion
I wouldn’t want this to be my only book on Agile Development: you’ll need something else to help you integrate these practices into a system. It is well written, however, and would be a good reference for someone new to Agile Development. Experienced Agile developers will find many of the practices rather basic, but might still be inspired by this book to try new things. In my view this is a 4-star book.
