top of page

Retrospectives: Making Good Teams Great


team party

Let’s start by discussing the importance of the sprint retrospective. It is one of the most important components of the scrum framework, but unfortunately, it is one of the most overlooked. As we know in Agile, the team dynamic with fluid communication is critical to the success of the implementation. This retrospective ceremony, often coupled with sprint planning, should happen often and truly be an open, active discussion of the TEAM.

So what does the retrospective look like? There are a couple of models that are effective depending on the type of team, and we will investigate just some of the models below.

Traditional model:

Ask the below questions to the team.

  • What went well?

  • What didn’t go so well?

  • What should be improved in the next sprint?

This provides a controlled framework to discuss not only good things in the sprint, but also things that were not so good.

Quadrant model:

In working with a client recently, who is dealing with organizational change, I suggested they added a fourth component to the mix.

  • Kudos/Shout outs to team members

This addition adds the element of human to the productivity conversation. A very healthy addition to a reluctant team. Many teams have also commented how the Shout Outs help them acknowledge the positive contributions made by team members. The recognition becomes contagious after the first few rounds where team members are looking to contribute to the success of the team and being acutely aware of what is occurring around them.

Starfish model:

Instead of the typical three questions, the starfish exercise contains a circle with five words:

  • Stop – These are the activities that do not bring value to a team or to a customer. Activities that bring waste into the process.

  • Less – These are activities where the effort required to perform such activities is much smaller than the benefit. (Or activities that were brought into the team in the past but did not show any overall improvements to a process.)

  • Keep – Usually these are good activities or practices that team members want to keep. These activities are already being applied.

  • More – Activities on which a team should focus more and/or perform more often. For example, many teams tell me how pair programming is good, yet they do not do it each time they should.

  • Start – Activities or ideas that a team wants to bring into the game.

With the starfish exercise, teams can get a good overall picture of what’s going on within the team, what is working and what is not. They can get an overview covering both failed and successful work experiences in the past.

retrospective

When you would use this technique: this exercise is quite simple and does not require any special occasion. Although, it might be interesting to apply it to situations wherein a team went through several ups and downs during the iteration. This technique reveals all the good things and less positive things achieved by a team. Therefore, this might be a good tool with which to make a summary of the sprint.

In working with a team recently using this model, it becomes very important to keep the topics brought up very actionable to address key learnings. The team found it very beneficial to revisit the sprint and identify some key happenings. They then used dot-voting to identify the top 2-3 ideas on what to focus on over the coming sprint.

One comment was made that “Well really need to keep doing this”. Another comment mentioned, maybe we should “Start” using the Parking Lot model after out stand-ups to keep the Stand-up meeting more focused. Following a similar trend with other areas yielded some actions to move forward instead of being abstract. Another team mentioned that we need “More” time to do our work and “Less” organized meetings during our sprint that seem to eat up too much of our time. While diving further into the crux of the issue behind the meetings, “Less” meetings meant less of the meetings that didn’t have a specified purpose, agenda and expected outcome. Being productive is the key here and not just busy.

The biggest takeaway that should come from using any model is that you “Stop” just doing something in the same exact way unless it is yielding the intended results. If it is not beneficial, change it up. Find a way to get closer to the desired outcome you are looking for. Look for other great models that have been shared for years so your retrospectives can make your team high-performing!

Credit:

Agile Retrospectives: Making Good Teams Great

by Esther Derby and Diana Larsen

bottom of page