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:

Shu is the beginner's state. Lost, confused, looking for basic rules.

Ha is more experienced. Procedures are automatic; direction certain.

Ri goes meta. Higher order functionality. The questioning guru.

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.