Agile Software Development

Keywords: RUP, UML, software methodologies, XP, Agile, SCRUM

Title: Agile Software Development

Author: Alistair Cockburn

Publisher: Addison Wesley

ISBN: 0201699699

Media: Book

Verdict: Essential reading for anyone interested in development methods

Buy US
Buy UK

Like it or not, we all need software methodologies. Writing good software is hard to do at the best of times, and when that development is a group effort and has to be of production standard then things get more difficult very quickly. One response to this has been to move to what are called "heavy weight" methodologies — with RUP being the prime example. Here methodology is everything, with strictly defined standards for modelling, documentation, notation, process and god only knows what else. What this does aside from anything else is impose a certain level of discipline. It also weighs developers down, slows down the process of writing code and explodes the number of documents (also called "design artefacts") that have to be produced.

While RUP has many fans, it has just as many detractors. If you work in an environment with fast-changing requirements, and let's face it, we all do, then you have a problem. Keeping the UML and the model in step with requirements can slow down the process considerably. And let's be honest, it's not a task that developers enjoy, is it?

The Agile software methodologies are a reaction to heavy-weight processes. They are a recognition that for many projects, a Rapid Application Development (RAD) process is more appropriate that RUP. These Agile processes are designed for working in smaller teams and/or in situations where requirements are very fluid. More importantly, they recognise that it is people - not processes - that create software.

Alistair Cockburn presents an eloquent and convincing argument for Agile. He covers the underlying principles in some detail, pointing out that communication and group working is at the core of development. This means that Agile is more of a set of principles rather than a strict set of guidelines, and that tuning of the development process is an essential task.

This focus on communications and feedback is a key point. If it reminds you of the kinds of things that people into complex adaptive systems talk about than you're right. Agile is about an organic way of working that is an emergent property of the way that people in development teams work together. This is a fancy way of saying that Agile is about learning how to work together and how to get better at producing software. If something doesn't work then change it.

Of course, this could all be viewed as just common sense. However putting this common sense into practice is no easy thing. Many enterprises have bought into RUP or other heavy methodologies in a big way and getting them to change is hard work. With RUP you have a stack of folders documenting the project at any one stage, what do you have with Agile? No documentation is certainly not an answer that makes sense, and one of the most important lessons described in this book is that deciding on the right level of documentation for a project is extremely important. Not enough and you risk chaos, too much and you risk getting bogged down.

This is a great book, and there really is a lot to learn from it. Reading this I was reminded just how much successful projects depend on the right mix of personnel, and that's something that you cannot fix by throwing notation, design artefacts or tools at.

Hit the 'back' key in your browser to return to subject index page

Return to home page