I believe that retrospectives can be incredibly valuable to any team. Taking the time every now and then to take a step back as a team and to reflect. How are you doing as a team? What have you learned from the things you did or released in the past period? Where and how can we improve? Actually starting to do team retrospectives on a regular basis is an important first step. Then you can start learning how to get the most out of your retrospective.

If you want to learn more about doing retrospectives, there are two resources which I’d highly recommend. Firstly, the Agile Retrospective Wiki created by my brilliant ex colleague Rob Bowley. This wiki provides a great wealth of tools and tips that one can use to plan and facilitate team retrospectives.

Secondly, the book Agile Retrospectives – Making Good Teams Great by Esther Derby and Diana Larsen is a great resource when it comes to learning more about retrospectives. These are the main things that I took away from reading this book:

1. Common retrospective stages – I like the retrospective structure which Derby and Larsen recommend in their book: Set the stage, Gather data, Generate insights, Decide what to do and Close the retrospective (see Fig. 1 below). This is a very useful structure to apply to your retrospective. Not only does the book outline the core purpose of each retrospective stage, it also provides concrete activities that one can do at each individual stage.
2. Planning a retrospective – Even if you stop reading “Agile Retrospectives” after its first two chapters, you’re likely to have learned a lot already about how to best plan and structure a retrospective. The book contains a lot of practical information on how to plan a retrospective, after which it offers some very useful dos and don’ts with respect to leading a retrospective.
3. Include a variety of activities – With the “Agile Retrospectives” book, the Agile Retrospective Wiki and the great retr-o-mat, you shouldn’t struggle to come up with activities appropriate for a retrospective. Too often I hear from people that they end up doing the same things in their retrospectives. In “Agile Retrospectives”, Derby and Larsen provide a great number of activities to choose from, depending on the goal(s) that you’re trying to achieve with the retrospective.

Main learning: For anyone who wishes to learn more about how to plan or run a retrospective, “Agile Retrospectives – Making Good Teams Great” is a must read. It contains a lot of practical tips on how to best facilitate retrospectives, making them action focused and creating an opportunity for the whole team to get involved.

Fig. 1 – Common retrospective stages – Taken from: “Agile Retrospectives” by Esther Derby and Diana Larsen, pp. 4-13

• Set the stage – Setting the stage helps people focus on the work at hand. It reiterates the goal for the time the team has together in the retrospective. It also contributes to creating an atmosphere where people feel comfortable discussing issues. For example, as a person facilitating the workshop you could start with a welcome and an explanation of the retrospective purpose. You can then ask people in the room to speak and you can outline your approach for the session.
• Gather data – Gathering data is an important part of the retrospective as it will help to create a shared picture of what happened. Start with the hard data: events, metrics, features or stories released, etc. You can then focus on feelings, which will tell what’s important to people about both the hard facts and about the team.
• Generate insights – This part of the retrospective is about asking “why” and thinking about what could be done differently. Lead the team to examine the conditions, interactions, and patterns that contributed to their success. Investigate breakdowns and deficiencies. Look for risks and unexpected events or outcomes.
• Decide what to do – At this point in the retrospective, the team will have a list of potential experiments and improvements. The team will pick the top items, decide on what to do and will action them. You can take action during the retrospective. For example, as a team you can decide in the actual retrospective to change the “working agreements” (e.g. “Everyone will pair at least four hours a day”). Equally, you can create a number of story cards or backlog items to follow up on after the retrospective (e.g. “Change the font on the homepage” or “Simplify deploy procedures”).
• Close the retrospective – End the retrospective decisively. Decide how to document the retrospective, its outcomes and actions, and how to follow up. Close the retrospective with an appreciation for the hard work everyone did both during the iteration and during the retrospective. Finally, before you end, take a few minutes to perform a retrospective on the retrospective. Look at what went well and what you could do differently in the next retrospective.

Fig. 2 – A retrospective custom-fit to your team – Taken from: “Agile Retrospectives” by Esther Derby and Diana Larsen, pp. 15-26

1. Learning about the history and environment of the team – Especially if you’re working with a team other than your own, study their context. When you talk to people on the team, try to find out about topics such as these: What did this iteration produce? What was the team aiming for? How did the result meet (or not) expectations? What kind of outcome will achieve value for the time invested – both for the retrospective sponsor and the team?
2. Shaping the goal for the retrospective – A useful goal provides a sense of why people are investing their time, without predetermining what actions or direction the team will take after the retrospective. Useful goals for retrospectives include the following: find ways to improve our practices, discover what we were doing well or understand reasons behind missed targets.
3. Determining duration – How long should your retrospective be? Fifteen minutes can be enough – or not. There’s no set formula for this. Base the length of the retrospective on four factors: (1) length of the iteration (2) complexity (of the technology, relationships with external departments, organisation of the team) (3) size of the team and (4) level of conflict or controversy.
4. Structuring a retrospective – The structure of the retrospective – Set the stage, Gather data, Generate insights, Decide what to do and Close the retrospective – helps to bring in perspectives from all team members, follows a natural order of processing information, and moves the group towards committed action. Look at the goal that you’re trying to achieve with the retrospective and allocate a set amount of time per activity. Also allow for some “shuffle time” for people to move from one activity to another.
5. Selecting activities – After you have the bare bones of the retrospective – the goal, duration, attendees, room, and setup – it’s time to think about activities. Activities are time boxed processes that help the team move through the phases of the retrospective. Activities provide structure to help your team think together and have several advantages over freewheeling discussion.

Fig. 3 – Demo video of the print version of Corinna Baldauf’s “retr-o-mat” – Taken from: http://www.plans-for-retrospectives.com/print/index.html