The ability to inspect and adapt is what differentiates good software development teams from great software development teams. For agile teams, the retrospective is a key event to making that happen. Just as the daily scrum is a scheduled time each morning to plan an attack for the day, the retrospective is a scheduled time at the end of each sprint for the team to inspect how these daily attacks were executed and create an adjustment and improvement plan for the next sprint. If your team’s retrospectives have become stale and boring, or fail to generate concrete actions and experiments for the next sprint, then try some of the following adjustments.

Get Everyone Involved…Early

In the beginning of each retrospective, ask each team member to use one word to describe the sprint. Involving everyone on the team within the first five minutes is important. Even if it is just asking them to use a single word to describe how well the sprint went, getting the team involved from the very beginning of the retrospective will help keep them engaged as the retrospective continues — especially the quieter team members who might hesitate to share their opinions during the retrospective.

As with any meeting or group, the loudest and prominent ideas are not always the best, and getting everyone involved early helps ensure the retrospective feedback is as diverse as possible.

The Format: A Natural Progression of Thought

For your team’s next retrospective, consider trying out the template below, which is described in detail in Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen:

1.  Collect Data

Start by reviewing metrics and charts from the completed sprint — burndowns, user stories/features completed, team calendars, bug reports. Next, review data for improvement initiatives identified from the prior sprint. The team should use this time to review how the experiments identified in prior sprint(s) worked (or didn’t work). Finally, be sure to ask team members how they feel about specific events in the sprint, the overall outcome of the sprint towards the sprint goal, and the value delivered by the team to the users of the software. How the team members feel about the accomplishments in the sprint is just as important as what the team accomplished.

Everyone will have a different perspective on how well a sprint went. All of this data builds a “sprint picture” and creates a shared view or perspective of the sprint. Collecting all of the important data on the team’s work during the sprint helps team members have a complete and common understanding of what was accomplished within the sprint and how well (or not well) it went. If your team is geographically distributed or does not have the opportunity to work together in person often, then this part of the retrospective is even more critical. It allows the whole team to be on the ‘same page.’

2.  Derive Insights

Review the data that the team has collected.  Start to ask “why” the sprint went the way it did. Look for patterns in the “sprint picture” that may have contributed to the team’s success, as well as the team’s struggles or failures. Many of the analysis techniques the team already uses to break down user stories and solve technical problems will be helpful when it comes to analyzing the sprint and deriving insightful conclusions from the sprint data.

Coming up with conclusions and insights requires the team to step back and review the broad picture of the sprint outcomes and perform a root cause analysis. A solid understanding of the impacts and events within the sprint that had an effect on the team is important as they start to identify ways they can improve not only their ability to work together, but potentially their ability to work with external teams as well.

3.  Determine Actions

Now that the team has a clear, shared understanding of the sprint, you can build a backlog of potential adjustments and improvements to try within the next sprint.  As a team, select a couple – maybe two or three – experiments to try out. I like to refer to these as “experiments” because the team will have a chance during the next retrospective to review the implementation and outcome of these experiments and make additional adjustments.

Instilling change is difficult, and these experiments are all about change, so limit the number of selected experiments to only a few, manageable adjustments that the team will be able to focus on in the next sprint. If you select too many, the team’s focus might be spread too thin and you will have less understanding of the impact of any one change – the next sprint might be great or terrible, but it’ll be less clear which change caused that.

Some teams will try to skip straight to loaded questions that ask what has worked well for the team or what the team can do to improve. For a small team that has been working together for a long time, these questions by themselves might be sufficient.  However, for most teams, a retrospective built around these questions alone will fail to generate the valuable insights that are needed for high performing teams.

Instead, try the format above and time-box each section with a different activity. Each activity or simulation should allow the team to follow a natural progression of thought – from collecting data about the sprint and generating insights or conclusions from this data, to finally identifying actionable items or experiments to try in the next sprint.

Keep It Fresh, Change It Up

No two retrospectives should be the same – even for the same team. Far too often, I see teams just going through the motions in their retrospectives. They know “being agile” means they should have a retrospective, but often times these retrospectives fail to provide any valuable action items.The team is bored and the discussion is stale.

So be sure to change it up. Choose a team goal for your retrospectives and focus on a different aspect of the project during each retrospective. Continually change the activities used to collect data, identify insights, and select actions/experiments. There are hundreds of activities which can be used for each of the three sections described above.

Finally, consider rotating the role of “retrospective facilitator.” The same team member does not need to be the leader for every retrospective. Allowing each team member to rotate into the role of facilitator and select the retrospective activities will keep your team’s retrospectives interesting and unique.

Continually Improve

The Agile Retrospective Wiki is a useful resource for sharing retrospective plans and activities. The wiki even includes guidance for leading a retrospective of your team’s retrospectives.

For even more guidance and tools and tips for gathering data, generating insights and selecting actions, check out Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen.  This book is filled with tips for improving your retrospectives, and the authors also include guidance on facilitating retrospectives and an astounding list of activities for each section of your team’s next retrospective.