« And the winner is… | Main | Art and code – obscure or beautiful code? »
Retrospectives in retrospect
By Aino Vonge Corry | November 18, 2008
Performing retrospectives for many years, it was not until Linda Rising gave a talk about them at JAOO that I came to know the label to put on them. Linda gave me the seminal book on retrospectives: “Project Retrospectives – A Handbook for Team Reviews” by Norman Kerth, which provided me with a lot of insight in how to make people feel more comfortable about these special forms of meetings and how to act in difficult situations.
Norman Kerths 1st rule is:
“Regardless of what we discover, we must understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.”
This is a very important mantra to have in a world where blame is so easily placed on others. Often, on visiting a company and opening discussions about problems, you will hear who is to blame for the problems, and it is almost always someone else, than the person in front of you. The filosophy behind retrospectives is that this is not a very constructive way of handling inefficiences. Instead of placing blame, open the discussion of the causes of the problem an find out what happened, and why and most important, how to change the way of doing things so that it does not happen again. Norman Kerths book described retrospectives performed after a project has been terminated (successfully or unsuccessfully) and takes up to three days with the entire project team.
The latest book on the market about retrospectives is the : “Agile retrospectives – Making Good Teams Great” written by Diana Larsen and Esther Derby. This book has basically the same content as Normans book, but it is set in the context of agile process development. This means, that the exercises performed are meant to be performed in smaller groups and in much shorter time. They are meant to be used after every sprint and last between 1 and 3 hours, roughly. They are written in a very straightforward manner, including which materials to have ready for doing them and it works! It IS, following this book, possible to perform a constructive retospective in two hours.
The thing I like most about performing a retrospective is when they realise that something that does not seem to work can be improved. The sense of hope this brings to people is essential. It is like teaching math, they get the same light in their eyes, and it is worth a lot of initial nagging and distrust. The reason for the nagging and distrust is that often the developers, project managers, designers, testers or what they are that show up for their first retrospective are reluctant to believe that something useful will come out of them. Their first impression of sitting in a circle almost makes them leave the room, but once we get to the juicy stuff with causes for mishaps, and they realise, that everybody actually did their best with the possibilities at hand at that moment, and that constructive plans can be put forward, then they realise that this is useful.
An agile retrospective recipe:
Set the stage (what will be done and what is the expected result)
Gather Data (get data items like events and views on these)
Generate insights (ask “why?” and what items to focus on)
Decide what to do (pick items of relevance and decide what actions are needed)
Close the retrospective (decide how to document the experience and plan for follow-up)
I know of a lot of companies, that perform retrospectives, where people from one project facilitates one for another project. I also know that some companies choose to get a facilitator from outside of the company. What do you do in your company?
