Search in Book Reviews

Over the last few years, an increasing number of software development methods have claimed to be "Agile". Probably the best known of these is Kent Beck's "Extreme Programming" [XP] which is like all such methods: focussed on ensuring that all participants in a project (including the "customer") get good feedback quickly and are able to respond to it. This is clearly easier when all participants know each other, and a lot of such methods prescribe putting everyone into the same room. Such approaches do not scale and most methods state that the maximum teamsize for which they are proven is in the range of 10-20 project members.

There are larger projects, and when projects get larger, the approach to communication and feedback needs to change. To give an example: with several hundred participants finding room for a "daily stand-up meeting" (as prescribed by SCRUM, XP, etc.) is problematic, and the time needed for everyone to give a 30 seconds summary of their activities prohibitive. Consequently, some authors (such as Alistair Cockburn in "Agile Software Development") have speculated that as the size of the project grows then it will start looking more like "traditional" processes whose descriptions focus more on their intermediate work products (e.g. design documents) than on the feedback they support. (IMO it is this focus on solution/work product and not problem/providing feedback that leads to misinterpretation of these methods.)

All this raises the question: what does happen when the Agile priorities are applied to large projects? I, and no doubt others, would like to know! Jutta Eckstein is someone that has been there, done that and has now written a book. So I was delighted when she asked me to review the book and sent me a signed copy.

This book attempts to cover a lot of ground. It includes a summary of the Agile movement and justifications for many of the practices common to Agile (and other) methods. It discusses the differences the organisation will see from "linear" development processes and how to "sell" the approach to different parts of the organisation. In addition, as the title suggests, it covers the problems presented by "large," offers some possible solutions, and gives a report on one large project.

One of the problems of covering a lot of ground is that some of it is not covered very well. For example, while there is much that is valid said about testing, on the different types of testing and who should write each, there is the following statement (about automated testing): "A common and reasonable fear is that testing will slow development down. While this is definitely true at the very start of a project having tests available will accelerate the development later on, when the system requires some changes."

My experience is that having automated tests in place during development always increases the speed of delivering working software. It is only later that there may be a cost to maintaining both production code and tests (this can be significant if the tests are poorly designed). If this topic were to be covered in more detail, then I would know how to reconcile the above with my experience: does "the very start of the project" refers to a period when there is no working software?

This is typical of much of the earlier part of the book, much that I agree interspersed with occasional statements that make me want to interrupt the author and ask for clarification, rationale and/or evidence. To be fair, some of this evidence is probably not available - much of the material derives from one large project and extrapolation based on experience of a range of organisations on other projects of varying sizes.

As with many books the value of this one depends upon your starting point and objectives. If you run large projects and are wondering what Agile methods could offer you then this is a great introduction and provides both examples of the differences it might make and pointers to the literature. You could steal the ideas that best suit your situation.

If you are not new to the Agile movement then it is not clear how important some of the material on existing Agile practices is. While I do understand the desire to make the book self-contained, and appreciate that having this material to hand could be useful to the reader I doubt that anyone contemplating applying Agile methods to large projects would be ignorant of this background. In view of this, placing it as the first section of the book gives it undue prominence. (On the other hand, I keepmeeting people that think XP is the only Agile process, so maybe this is for them.)

If you are looking for the definitive survey of applying Agile methods to large projects, then it does not exist (yet) and this is not it. It does, however, provide a valuable data point towards such a survey. Every project is different, and every organisation too - we need more examples to map out the territory or even to be sure which are the fixed landmarks. In this book you will find pointers to some of the problems to look for, and some solutions then this will be of help.

Finally, if you are looking for proof that "Agile" can be done for large projects: this is for you.