Search in Book Reviews

If you have read my Desert Island Books you won't be surprised to learn that this book, one of my selections, comes highly recommended. It speaks to me because it emphasises the very human characteristics that make psychology every bit as crucial to software development as technology. Actually, I'd contend that the issues affecting projects are at least 95% psychological, but if you haven't read the book yet you might feel that this overstates it. Let's just agree that human behaviour is an important factor; reading Cockburn helps to underline why I feel so strongly about it.

The need for communication is a very human issue that affects any software beyond that which you write on your own for fun; there's no problem to solve when it's just you and a beer (or mug of coffee, or other programming beverage of your choice). Code is pretty unambiguous; the computer will do what you told it, however much it may sometimes seem otherwise. Expressing your ideas using natural language, to another unpredictable human rather than a machine, is a different and difficult matter which Cockburn devotes his first four chapters to exploring. After describing this problem of "managing the incompleteness of communications", he develops it further by comparing the nature of software development to a team co-operative game requiring invention and communication. The characteristics of individuals and those of teams are both significant factors in such a game, so each of these has its own chapter. The issues addressed in this first half of the book apply beyond the domain of software development, but being generalisable doesn't mean there is a lack of specific and practical advice to tackle them. My personal favourite is the 'information radiator' (a display of information positioned where passers-by will see it); an idea as simple as it is effective, of value regardless of whether what your project is Agile and even regardless of whether it's Software Development.

I strongly believe that it is essential to know what problem you are trying to solve before applying any measures to address it. The first four chapters are an excellent way of answering this question for anyone thinking of applying a methodology measure, and so provide the ideal context for the following chapter on analysing, designing and refining methodologies. However, the book is designed to cater for a wide range of readers. I don't think any reader engaged in the world of software development (or indeed other collaborative enterprises) could fail to benefit from reading these quite general early chapters, whether or not the later chapters interest them, but readers who have already understood these problems can easily pick up the book from chapter 4 to review the specific principles they need to keep in mind when choosing a methodology. Equally, they can go straight to chapters 5 or 6 if they are looking for information about agile methodologies in general or the Crystal family of methodologies in particular.

This book is now in its second edition. Like me, many of you will have read it in its first edition; Cockburn has spared us the frustration of trying to find out what's new by leaving all the original chapters intact except for corrections. The evolution of his ideas since the first edition is instead laid out in a chapter n.1 for every chapter, and these are kindly marked with grey tabs on the page edge so that flicking through the book to find them is made very easy. Like so many of the ideas in this book, this is a simple yet effective solution to a common frustration.

The 'evolution' chapters do not contradict the content of the originals - if they did, there wouldn't be an advantage to this approach! Rather, they bring things up to date with the current state of the craft in light of the events over the intervening years. Thus by far the largest update is for the chapter on agile principles. It answers many persistent questions about practical aspects of the agile model and how it fits with others. It also has to dedicate nearly 20 pages to debunking pervasive myths that have developed about agile over the years - a sad sign, perhaps, that 'agile' has achieved greater penetration as marketable rhetoric than as a genuine implementations of the core principles that make it work.

This excellent book provides guidance rather than dogma, explaining what you might choose to do and why you would choose to do it and positively encouraging teams to ask themselves these questions. It describes agile as "an attitude, not a formula" and not only fosters that attitude, but provides some pragmatic tools for putting it into practice.