home

Agile Software Development, Cockburn

Teaser for Slashdot's "above the fold": The second edition of Alistair Cockburn's "Agile Software Development" was released earlier this year. Does it add significantly to the first edition? Who should read it? And is it clear yet what "Agile" means? The answers: Maybe; Everyone; Ri. Amplification and justification below...

This excellent, but imperfect, book might make more sense read backwards - you would start (at the end) with useful, concrete ideas about how to improve the way you make software, progress to a more general discussion, and end with the unifying principles of Shu, Ha and Ri.

Instead, Cockburn starts by explaining those terms. He says that they are from Aikido. Someone who understand them in their original context may find the following (my own summary) to be crude (or plain wrong), but they are central to this book and to Agile as a whole:

One reason (of many) these distinctions are important is that communication changes at each level (I think you can see this in programming languages - Python is designed for learners at the Shu level, while Perl is more concerned with letting Ri level programmers express themselves as they choose).

Although he never comes out and flatly states it, Cockburn clearly implies that Agile development is all about the Ri. I think he's right: that makes this book worth buying, reading, and passing on to others.

But this is all rather vague (another reason to read the book backwards is that it's much easier to tolerate this kind of hand-waving when you've seen some concrete facts; start at the beginning and you face not just this "wisdom", but some of Cockburn's own poetry - Paul Neil Milne Johnstone has a posse). Back to earth. What does this mean, in practical terms? And what does this say about "Agile"?

First rule of Agile: there are no rules. There are too many variables for any one process to be always right. Instead, you do what works in a particular context. Results matter. It's not who uses the latest catchphrase. It's not winning boardroom bingo. It is about getting results out of the door.

How do you get there? Is "Agile" more than the empty tautology "it's best to do the right thing"? After all, while we want to be Ri, we start at Shu. Cockburn provides two answers.

First, reflect. Learn from your own group's experiences. Look at what you do well. Build on it. If reflection fails, reflect on that. Cockburn repeatedly emphasises the need for personal safety - that people need to feel safe to express what they think.

Second, steal. Learn from other groups' experiences. The second half of the book, roughly, discusses possible ideas. These tend to be the "traditional" Agile themes: communication; lightweight documentation; information radiators; pair programming; etc. Useful information when you're at the Shu level.

So this book is targeted at people responsible for process. People that influence a company's culture. People who aim to create an environment in which "The Cooperative Game" - Cockburn's term - can be played well.

Pick up a copy at your local bookstore and you'll see that there are grey "tab marks" printed on some page edges. These indicate new content (the unmarked pages are the original text which has been kept, more or less verbatim). In general the updates are not that substantial, but chapter 5.1 - a retrospective (with notes on various practical cases) - is the exception.

This new section includes reports from others responsible for improving agility. They are in broad consensus: the Cooperative Game cannot be dictated. It must be cultivated; grown from the roots.

Which is why this is also a book for developers. It recognises that everyone can make a difference. At various points in the book Cockburn addresses the question "what do I do about this?" and he's talking to everyone.

I am a programmer working in a distributed, open-source project. There are times when I take a walk round the block to shrug off the less-than-helpful comments of a co-worker, or some anti-pattern in the code, or [any programmer can insert their own examples here - my co/workers are a great bunch, these problems occur everywhere]. Reading a book like this helps keep me sane: it helps me understand how I miscommunicate, and how to communicate better; it lets me understand the (valuable!) role each person plays in our process (before that, it helped me see what our process is); it reassures me that communication in a distributed team is hard and it gives me ideas to help solve these issues. Although, having written that, I think Cockburn could profit from a study of successful global teams.

Your problems will be different, but the best way to solve them will be the same - through careful thought and reflection. And at heart, that is what this book is about. Cognitive Behavioural Therapy for software development.

So this is a good book. It recognises that things go wrong; it admits there is no one size fits all patented wonder potion magical cure; it reaches the logical conclusion, you have to think; it goes on to discuss possible solutions.

But it's not perfect. One of the more amusing sections describes Cockburn's experience producing the previous version - he tried an Agile approach to publishing which met the (very tight) deadline, but alienated his copy-editor. Now I don't know what a copy-editor does, but if he was relying on her to remove duplications, rewrite cliches, or improve metaphors, well, he might not have found the optimal process. And it is a pity that the original text was not more completely revised for this edition.

Two final conclusions. One is that the waterfall model is "Agile" if it's the best approach for the circumstances. The other is that you should be suspicious of anyone trying to sell a single, perfect, recipe.

Disclaimer - I obtained a free copy of this book on condition that I review it.