Software

This article is more than 1 year old

Practices of an Agile Developer

A practical Agile book

Tue 10 Oct 2006 // 01:26 UTC

Book review If nothing else, the Agile development movement has hit on a good brand. Agile has so many positive connotations – fast, graceful, dynamic. Come on, who doesn’t want to be Agile? Besides, the alternatives don’t have a handy label to grab on to. Formal methodologies? The Unified Process? Arthritic programming… Nope, Agile wins that battle hands down.

So, if you want to go with the flow and inject some Agility into your life as a developer, what do you actually have to do? The first thing to realise is that there is no one true way. There are lots of methodologies and processes in the Agile camp: Scrum, extreme programming, Crystal, Adaptive Software Development and plenty more… However, while there might be differences in emphasis or inspiration, there are a core set of practices that are pretty much shared by all of these schools of Agile development. And it's these practices that Venkat Subramaniam and Andy Hunt set out to document in their Practices of an Agile Developer

In fact, they set out 45 different practices organised into eight chapters that broadly cover the development life-cycle, from design to coding to debugging and so on. In terms of range, there’s not much that’s been left out, so this book does represent a fairly full Agile development toolkit.

Every practice is introduced with a demonic statement that whispers some bad advice to the reader – this is the temptation that the Agile practice will help you resist. There follows an explanation of the issues at hand and the implications of giving in to that demonic temptation. The Agile practice is then placed into context and the benefits of the practice are clearly explained – often helped along by a handy anecdote or war story. And, as a quick reminder for later, there’s usually a single Angelic statement of the practice at the end (the good cop versus the bad cop).

Aside from the explanations and the stories, there are also pointers to ‘Keeping Your Balance’ so that you don’t go overboard when adopting a new practice. Each practice also has a ‘What It Feels Like’ section to help you recognise whether you’re doing it right. The latter smacks of a being a bit of a gimmick. Surely, the real test of a practice is whether it improves the development process rather than some vague and subjective description of ‘what it feels like’?

All the core Agile techniques are covered – including the benefits of automated builds, unit testing, continuous builds, iterative and incremental development, regular releases to customers, code reviews etc. Additionally, there are process-related practices as well as purely technical ones. These include things like mandating that pretty much everyone writes code (this last directed particularly at architects too grand to humble themselves with mere programming), the benefits of high-levels of customer involvement in the development process and so on.

As well as the practices, the book also offers advice on how best to move to Agile development. This is often where the best of intentions crash head-long into existing corporate cultures. The advice is to take it slowly and to introduce Agile incrementally [this applies to just about any innovation involving cultural change – ed] because big-bang transitions are hard to pull off - often because they don’t get adequate buy-in.