author : Alistair Cockburn

This great little book gives good, clear, pragmatic advice about exactly what it says on the cover. Loads of real examples help to anchor the points being made. Both the content of the use cases, and the process of developing them, is covered, along with discussions of how to choose the right level of formality for your own project.

The acerbic little side-comments on "The Great Drawing Hoax" -- how UML's stick figures and ellipses are no substitute for well crafted prose -- make a refreshing change from the usual hype. Cockburn discusses various tools that can be used when constructing use cases -- from the derided diagramming tools to a word processor with hyperlinks. None is ideal, but a word processor is possibly the best. (For those who want to build a better tool, he provides a suggested meta-model for use case structure.)

Get everyone on your team involved in writing, reviewing, or reading use cases to read this book, and learn how it should be done.

There are many books on particular "Agile Methodologies", such as XP, RAD, and even Cockburn's own Crystal series. What we have here is a discussion of these -- what it is about them that makes them agile, and how they can be tailored for your own unique project.

Cockburn is full of concrete, useful advice on running agile projects. For example, one interesting recommendation he makes is to provide a library of work examples (tangible examples of items like project plans, class diagrams, use cases, code samples, etc) rather than templates with abstract guidelines. People tend to find it easier to modify something concrete, even if the final artifact has nothing at all left of the original example. Another recommendation is the "process miniature experience" -- running through the entire development process very quickly (say, in 90 minutes!) on a necessarily very small example, to establish and reinforce the process conventions in the minds of all the participants.

All the way through, the focus is on the team, and he starts from the idea that software production is a cooperative game, played by the team members, who may also be involved in other games. The emphasis is on doing just enough to achieve your goals, and no more, to reduce methodology bulk. The major goal is delivering software, and the minor goal is setting up for the next project. It's this minor goal that gets around the main criticisms of approaches like XP -- no documentation. (And this "setting up for the next" is reminiscent of Stewart and Cohen's 'snooker break' analogy of cultural continuance.)

Cockburn shows how the cooperative game idea gives insight into how teams work, how the agile methodologies should work, and how and why to tailor a given approach to a given project. The tailoring is a critical part of the methodology itself, occurring at the start, and then during Reflection workshops, where the project team is allowed to modify any part of the process, except the requirement to have the Reflection workshops (shades of Nomic here!)

Cockburn stresses there is no "one size fits all" project methodology -- except maybe at the meta-level. And this is all written in his clear and pleasant style. So, if you want to be more agile, but are worried the existing approaches might not work for you, start here to see ways of applying them in your case. (And for the pedants, such as myself, there's even a small footnote on why the word "methodology" is the correct one to use here, at least according to US dictionaries.)