---

Keywords: Software methodologies, development processes, Agile, XP Title: Agile Software Development, 2e Author: Alistair Cockburn Publisher: Addison Wesley ISBN: 0321482751 Media: Book Verdict: No matter where you stand in the methodology wars, this is an important and thought-provoking book.

Buy US Buy UK

Alistair Cockburn is one of the most prominent and influential of the Agile development gurus. As well as being one of the original authors of the Agile Manifesto, he is also the developer of the Crystal family of agile methodologies and a pivotal figure in the evolution of the Use Case. He is also an articulate and passionate advocate for Agile as a philosophy over and above a set of prescriptive development practices.

At the heart of this philosophy, as outlined in this new edition of Agile Software Development, is the idea that software development can be understood using a number of different metaphors. Why are these metaphors important? Because they help shed light on what it is we do, how we do it and why. The most obvious example, and one that Cockburn investigates in some detail, is the idea of software development as an engineering activity. The concept of software engineering has had an enormous practical consequence, from the proliferation of heavy-weight methodologies and processes to the development of both notation and supporting tools.

Agile techniques are a reaction to these heavy-weight processes, both in the rejection the command and control structures of these processes and also in the return to the craft metaphor for software development. However, Cockburn does a double-take on this and points out that there is a fundamental misunderstanding at work here. Those who have opted for the software engineering metaphor have really been focused on the results of doing engineering (predictable, controllable and stable things like bridges, manufacturing processes etc). In contrast, he points out, doing engineering is an activity steeped in uncertainty, changing requirements, unpredictable delivery and massive cost over-runs (sound familiar?). In this sense at least, Cockburn is willing to reclaim 'software engineering' as a valid description of what we do.

There are a number of key ideas that emerge from this book. The first is that software development is a 'co-operative game'. Game play requires high levels of communication, motivation, skill and a set of strategies that can evolve and adapt to change. Much of this derives from the field of complex adaptive systems, which Cockburn acknowledges. Secondly he points out that there is no 'one size fits all' methodology. Adaptation and evolution of methodology is another key idea, and he argues that self-reflection is an important part of any project team working.

Those looking for more on specific techniques - test-driven development, continuous integration, refactoring - will find some coverage, but it's not the core part of the book. The emphasis is less on the mechanics and more on the motivation behind the techniques. This isn't by any means an 'agile by numbers' cookbook of techniques (Practices Of An Agile Developer or our own Agile In 30 Seconds are better for that kind of thing).

Cockburn himself is at pains to reflect on the experiences of the last five or so years since the Agile movement has taken off. As with Kent Beck of extreme programming (XP) fame, Cockburn takes on board some of the criticisms levelled at Agile. He admits that in some cases some of the virtues of Agile have been taken to ridiculous extremes, and that sometimes the Agile banner is simply an excuse for no methodology or cowboy programming (as he puts it).

There are no magic bullets in software development, but having developers reflect on their experiences so that they can adapt and evolve how they work is important - this book is encouragement to do so.