Daniel Irvine on building software
Book Review: Agile Exposed
13 March 2013
Agile is a tricky thing to get right. There are many teams who claim to do agile, but of those only a minority are doing it well.
My own experience has led me to believe that it’s very hard to get the message through to people--even skilled programmers, who sometimes just don’t seem to get it.
I wish I’d known sooner about Agile Exposed by Barry Evans. It states the case for agile more eloquently than many of us ever will. At 134 pages it’s a slim volume and can be read in a few hours. Digesting it, however, will take longer and the avid enthusiast will certainly want to muse upon it for a while longer. I have kept it on my desk for the past month and dip in and out a few times each week.
If your team uses a methodology like scrum or lean, or if you’re considering moving to an agile methodology, you should buy this book. If you’re feeling generous then buy a copy for every member of your team--the price is low enough to warrant that.
It’s an easy read and could be read cover-to-cover in one sitting. As I see it, the author’s intention is for you to become “enlightened” with an understanding that being agile is not about management process but about programming practices such as test-first development, pair programming and refactoring.
The book sets out with a history of agile ideas and then picks apart the various facets of those ideas, discussing why each makes sense. For example, the author offers an excellent theory of “scope” and how it is traditionally thought of versus how an agile practitioner might think of it. This advice in particular was an “aha!” moment for me; it succinctly described an issue I’d seen in the past with a team but could never manage to resolve.
At the end of the book is a dissection of various methodologies and techniques such as user stories, scrum, kanban and XP. The scathing review of scrum will resonate with anyone ever involved on a team that’s been “agilized” by a consultant drafted in to improve the team’s under-performance. The point is that scrum can be imposed but the team is still left decidedly un-agile.
The author helpfully mentions numerous websites and books that you can explore as you progress on your journey towards enlightenment; that’s important because this book tells you the why, but not the how. It won’t give you strategies for pair programming, for example. But it will set you in the right direction--or correct your direction if you’ve started off on the wrong path.