For a new Scrum Master, the mechanics of getting started with retrospectives are deceptively easy. Somebody tells them to write three columns on the whiteboard (What Went Well, What Did Not, Ideas) and to facilitate the discussion. The Scrum Master makes sure that management is not invited to the meeting. He/she Identifies the team members who are not participating and try to get them talking. Simple. The retrospective becomes a blend of problems mixed with solutions and “action items” for the next sprint. If the team is lucky, it identifies the most valuable areas for improvement. Unfortunately for many teams, they go through the motions but do not get to the heart of their biggest problems/opportunities. It becomes a stale ritual and the team plateaus.

Surprisingly, many Scrum Masters fall short on the basics of how to conduct a retrospective. They think that all it takes is writing the three columns on the board. Properly done, it actually starts as soon as sprint planning is done.

In their book “Agile Retrospectives – Making Good Teams Great”, Esther Derby and Diana Larsen suggest the following structure for a retrospective:

1. Set the stage – get the team in the right mindset for a retrospective
2. Gather data – identify the key things that happened during the sprint
3. Generate insights – about those things and why they happened
4. Decide what to do – new practices to improve
5. Close the retrospective – take a minute to step back and reflect on the sprint, the team’s accomplishments, and the retrospective itself

Lots of different techniques exist for each of the stages of a retrospective. The art is in the Scrum Master recognizing which one fits the team at that particular moment in time.

To set the stage for the retrospective, the Scrum Master may remind the team that the retrospective is a safe environment. They could also do a check in where they go around the room and ask each person “How are you doing today?” to engage the team. Another technique is to ask people “if the team were a car, what kind/make/model of car were we in this sprint?” and record each person’s answer on the board. This can provide an interesting reference point to revisit if someone says the team was a Pinto but during the remainder of the retrospective does not point out any problems that occurred during the sprint.

In gathering data about the sprint, the Scrum Master and team consider:

• The sprint goal
• The sprint backlog and the results (done, not finished, etc) for each story.
• Impediments or challenges that occurred during the sprint. Laying them out on a calendar can help illustrate how they affected the sprint and generate conversation for how to handle them in the future (the Scrum Master may get in the habit of noting these as they happen).
• Is the team going through a storming phase? Asking team members to track how they were feeling about the sprint during specific stages of the sprint can help surface opportunities for working agreements, practices the team should adopt, etc.
• After trying to remember what happened over the last week or two (they know better than to do three or four week-long sprints) the team and Scrum Master may start to note some events as they happen to make data gathering easier in the retrospective.

To generate insights, the team can approach the discussion a number of different ways:

• Was every story closed? If not, what state was each one in at the end of the sprint? Ask why. Then ask why again.
• Did the team stretch yet still meet the sprint goal? Reflecting on what the team did well could reinforce those practices and also set the stage for a discussion about how to take it to the next level.
• Is there a lot of discussion about whether the team should adopt certain practices? The insights could be focused on things the team to start doing, stop doing, and continue doing.

Teams are usually pretty good at coming up with ideas for how to do things differently. Trying to do all of them at once or forgetting about them in the throes of the next sprint are common pitfalls.  A good Scrum Master will gather these ideas as the team identifies them during the retrospective. A great Scrum Master will sense when the team has not really gotten to the heart of an issue or opportunity and prod them to drill down to the heart of the matter.

Once the team has identified ideas or new practices to try in the next sprint, posting them near the Scrum board is an easy way to quickly remind the team about them when the team is gathered around the board during the daily standup. The remaining ideas go into the Insight Backlog. This backlog can be evaluated along with new ideas that come out of each retrospective to decide which ones to try next.

Some formats for gathering data and generating insights include:

• (Old reliable) What Went Well, What Did Not, Improvements. Team members write ideas on sticky notes and put them in the respective columns. Dot voting for which ideas to adopt.
• Reviewing results for each story, conducting 5 whys for each one.
• Start Doing, Stop Doing, More Of. Again, sticky notes placed by team members can help with participation.
• Sailboat. What things are the wind in the team’s sails, propelling it? What are the anchors that are slowing it down? Another variation is Motorboat, where the team identifies the anchors that are slowing down the boat (team) and they can even place them a different ‘depths’ to indicate their severity.

Reflections

• There are many ways to conduct a retrospective. The Scrum Master’s job is to find the right way to help the team improve at that particular moment in time.
• Overcomplicating the format of the retrospective can get in the way of improvement.
• Letting the format of the retrospective get stale can result in team members who have shut down from boredom before they even enter the room.
• The Product Owner should be there. They are a member of the team after all.
• In closing the retrospective, take time for Appreciations. Good people aren’t just working for a paycheck.