Alistair Cockburn
Addison-Wesley, 2006
Alistair Cockburn
Addison-Wesley, 2006
(1st Edition 2002)
ISBN 0201699699 (paper)
Buy it from Amazon.com (commission paid)
Buy it from Amazon.co.uk (commission paid)
" It is interesting to see how much of an author's methodology philosophy is used in his personal life. Does Watts Humphrey use a form of the Personal Software Process when he balances his checkbook? Does Kent Beck do the simplest thing that will work, getting incremental results and feedback as soon as he can? Do I travel light, and am I tolerant of other people's habits?
...
I balance the checkbook only when I absolutely have to, doing it in the fastest way possible, just be make sure checks don't bounce. I don't care about absolute accuracy. Once, when I built bookshelves, I worked out the fewest places where I had to be accurate in my cutting (and the most places where I could be sloppy) to get level and sturdy bookshelves." (Page 148)
This attractive and much-liked book puts Cockburn into the elite ranks of authors who have produced more than one successful and clearly useful book (as opposed, say, to publishing the one idea in many forms). (See review of Writing Effective Use Cases.) Cockburn writes in a fluent and no-nonsense conversational style. He is often witty, as in the paragraphs quoted above; he is always honest and to the point.
The main emphasis of the book is in a way not really agility at all -- that could almost be taken as read -- but people. Cockburn praises Weinberg for his early focus on people as the key component of software development. But, he argues, that still isn't universally accepted in the industry: there are still plenty of methodologies out there that claim to solve all problems. Instead, suggests Cockburn, we need to pay attention to personalities and psychology, and tailor methodologies to suit people rather than the other way around.
Some themes do recur: Cockburn's characteristic "working with [differing numbers of bits of] Precision" is familiar from his Use Cases. But there is more than enough that is new in this book to make it an essential read. Why focus on people in a book on software engineering? Because rigid methods are a straitjacket: they help get the work done less well, more slowly, and at greater cost. But it's no good just running around bleating "agile": light methods force people to take more care (hence Cockburn's comments about carpentry above). Kent Beck's Extreme Programming may be based around activities rather than deliverables (page 143), but that means it demands more discipline than traditional methodologies (such as the Waterfall approach or the Rational Unified Process (RUP)), not less. Because there isn't a pile of traditional artefacts (Software Requirements Specifications, etc etc) to check for consistency with the software, the designer/programmers have to make sure that what they're doing makes sense.
The book is full of simple and good advice:
how to evaluate a methodology
applying the principle of expendable efficiency yields different methodologies in different situations
relying on heroes to fight fires is a mistake
...
You'll have noticed that principles like these mean that projects must think for themselves. If every project is different, and needs its own environment and process, then intelligence and reflection are critical for success. There is no room in an agile world for a jobsworth attitude, or for management by cutting and pasting last year's Quality Assurance Plan. Doing just enough means being aware how much is needed, and working out a way to do that much. It also means being willing to go beyond the company Procedures manual, which certainly won't say how much is enough on your project. It would be sad to conclude that this means that only projects which have Cockburn or Beck in the team can possibly succeed: and fortunately false. But there can be no doubt that the approach demands skill, energy, and teamwork.
The emphasis on tailoring goes a long way towards answering one of the main criticisms of the Agile movement: that in some circumstances, like nuclear power or aviation, safety demands very careful development. I guess Cockburn would reply "yes of course it does". That reply is starting to be heard loud and clear, eg from Al Davis who similarly advocates a light touch. The point is that agility is relative, and just enough depends on the situation. The amount of requirements and specification work you should do is like insurance: enough to ensure you sleep at night (Davis quips), but not so much that you bankrupt yourself, bringing everything else to a halt.
Agile Software Development is principally aimed at programmers and engineers working in the software industry. It will obviously be of immediate interest also to students of software engineering. However its emphasis on teamwork, tolerance, and attention to tailoring the development life-cycle to suit the situation (compare Just Enough Requirements Management) make it relevant far more widely. Here's an example that shows why:
"Everyone on a project is in a position to detect a mistake, regardless of the type of system being designed." (Page 72)
The humanity and wisdom of this call to mind Enid Mumford. Cockburn goes from strength to strength.
© Ian Alexander 2006
You may also like:
