Retrospectives seem to mean many different things to different people. At least, that’s the way it happens in practice. People approach retrospectives in different ways, with different motivations, and that naturally leads to very different experiences and outcomes.

Venkatesh Krishnamurthy wrote about Retrospective Smells in which he quoted some cautions I’d posted on the Lean Software Development yahoogroup. This was in response to Allan Kelly’s mention of his blog post, The Trouble With Retrospectives, which was, in turn, mentioned in response to Robin Dymond’s announcement of his new Retrospectives Wiki.

Robin’s project is an interesting one, but his ideas about retrospectives seem to differ somewhat from mine. I find his ideas to be too tightly focused on teaching, and he finds mine too loose. Mine may be found in these pages from my own wiki:

• http://idiacomputing.com/moin/IntrospectionAndRetrospectives
• http://idiacomputing.com/moin/RetrospectiveTechniques

These are notes I’ve created for my own use, but you might find them useful also. They consist of some links to various articles I’ve found helpful and notes on techniques that I like to review when planning a retrospective.

Norm Kerth documented retrospective techniques in his book, Project Retrospectives: A Handbook for Team Reviews. In this book, Norm does not explicitly define a retrospective, but describes it as a ritual to look back and contemplate the past. Norm states in the preface that a project retrospective “is the single most important step toward improving the software process!” [emphasis and exclamation are Norm’s]

Norm describes retrospectives held at the end of the project. Since a typical project might last six months to several years, this is a long time to wait before looking back and taking stock. While such a retrospective might help the organization in future projects, it does nothing for the project holding the retrospective.

Esther Derby and Diana Larsen, in their book, Agile Retrospectives: Making Good Teams Great, specifically “focus [on] short retrospectives–retrospectives that occur after one week to one month of work.” Esther and Diana define what they mean, within the context of their book, by the term retrospective.

When we say retrospective, here’s what we have in mind: a special meeting where the team gathers after completing an increment of work to inspect and adapt their methods and teamwork. Retrospectives enable whole-team learning, act as catalysts for change, and generate action. Retrospectives go beyond checklist project audits or perfunctory project closeouts. And, in contrast to traditional postmortems or project reviews, retrospectives focus not only on the development process, but on the team and team issues.

I highly recommend both of these excellent books to anyone who conducts, or would like to conduct, retrospectives. Not only do they give you some suggestions for specific exercises, they give some more general guidelines and advice. As good as these books are, though, they are only a beginning for learning to conduct successful retrospectives. Like improving, itself, there’s no end to improving the way you improve.