Tips and tricks for Scrum teams: How to run better retros

In this article, I would like to explore the topic of ineffective retrospectives and why teams often overlook this meeting, even though it is one of the most important Scrum events. Of course, I will also share techniques that have helped me and my teams organize more productive and effective retrospectives that no one wants to skip.

Retrospectives are crucial meetings for Scrum Teams, and they should be driven by team members to empower them to own their work and self-improvement. So, why is it usually underestimated and challenging for both the Scrum Master and the Scrum Team? Team members may hesitate to speak openly about daily issues or more widespread problems that require urgent revision and discussion. The key issue here is that when people in a team don't feel safe, they are less likely to speak transparently about real issues.

The problem may also arise with remote teams. When I worked with such teams, finding a way for all team members to participate equally in the conversation was challenging and, for sure, could be a demotivating factor.

Another popular misconception is the belief that retrospectives don't bring about any changes. If your retrospectives haven't led to any changes in the past, why should anyone want to attend them in the future? A very banal but no less important reason is general boredom with this meeting. When teams run retrospectives regularly and frequently, they can get bored, especially if they use the same techniques repeatedly.

Retrospectives are about frank and open discussions of issues and collaborative problem-solving for continuous improvement. So, how can a Scrum Master help team members feel safe, open, energized, and reflective during retrospectives?

In my opinion, there is no universal remedy that can help in all situations and for all teams since we are all unique with different backgrounds, experiences, and skills, placed in different life circumstances. However, different techniques can help teams conduct their retrospectives efficiently. These techniques are useful for both new teams adopting the Scrum framework and those that have been working together in a Scrum Team for a longer period.

Technique #1: Attendance Review

Agile practices tend to give teams and individuals ownership of their work. The higher the level of responsibility, the more involvement each person feels in their work. To ensure this feeling of responsibility, the entire Scrum Team needs to attend retrospectives. This usually includes developers, the Scrum Master, the Product Owner, and anyone else highly involved in designing, building, and testing the product.

Pay attention to the people who attend this meeting. Perhaps someone from management is a regular guest at your retrospectives. Team members with their managers in the room may be less likely to express themselves emotionally due to fear of it impacting their performance reviews, for example. Trust is the key feeling for this event, and we want to hear what people are really thinking. If someone outside the Scrum Team wants to contribute to the team's work, they can be invited to the Sprint Retrospective as an exception, but not regularly. Alternatively, they can have a one-on-one talk with the Scrum Master to share their ideas.

Technique #2: Let's Play

People don't like boring retrospectives, and bored people don't care about improving anything; they just want to end the meeting quickly. One of my favorite role-playing games is:

C-suite role-playing: This game is great when your team feels that there are issues beyond their control, and they can't influence the situation. Each member of your team imagines themselves as a C-level executive for one day and writes down the top three things they would like to change immediately. After collecting feedback from everyone, you may notice common patterns. When you see these patterns, it's time to share this information with the decision-maker.

Chocolate Brand: Each team member describes the latest sprint as a chocolate brand. For example: Did it feel like a breezy vacation with a Bounty or distant and vague like Mars? Using this technique, team members can discuss specific problems indirectly to provide more direct feedback. It could be a very amusing activity.

These kinds of games are like icebreakers; they lead to more open communication during retrospectives.

Technique #3: Short Retrospective

Short retrospectives are not a long-term solution. Usually, a retrospective should last at least 45 minutes for a one-week sprint, and for a two-week sprint, it should be a 90-minute event. However, some teams don't conduct retrospectives at all or don't want to do it regularly because they think it is a waste of time. In this situation, a short retrospective could be a game-changing event. Here's how to plan a short retrospective:

• Set a 20-minute timer at the beginning and inform everyone that it won't last longer.
• Set a measurable goal (identify three issues that affect team productivity and three actions for the next sprint).
• Collect feedback in advance (before the meeting starts, ask everyone to send their top three issues from the last sprint).

Plan your time well:

1. 3 minutes - Explain how the retro will go.

2. 3 minutes - Share the top three issues from the last sprint (anonymously).

3. 5 minutes - Ask everyone to vote on the most important issues.

4. 7 minutes – Propose to every team member at least one action to solve one of the top three issues.

5. Close the retrospective, thanking everyone for their time.

In 20 minutes, you'll have an action plan for the next sprint with the top three issues your team identified during the retrospective. You can present this plan during the next sprint planning. This technique will help you restore team trust in retrospectives by proving that retrospectives can be efficient even when they are very short. Finally, keeping at least a short retrospective is better than having no meeting at all.

Technique #4: Appreciative Retrospective

Sometimes, with less experienced teams, someone may start criticizing other team members too much or blaming the Product Owner (PO) for all the failures the team had in the last Sprint. This could be due to unclear requirements or the inclusion of too many user stories in the Sprint. On the other hand, the PO might blame the developers for committing to work but not estimating tickets precisely enough (precise estimates are an oxymoron, but this is a topic for another discussion). There are always enough reasons to blame someone, but what results will it bring you?

Complimenting people all the time won't give them an opportunity for self-reflection either. So, as with all activities, you need to find the right balance. Focus on positive things, and transfer negative experiences into positive ones. Ask team members questions that will help them focus on team strengths and successes. This session may help restore trust within a team and facilitate a positive vision of team members.

Technique #5: Safety Check

When a team has just finished a tough sprint and doesn't feel comfortable about speaking the truth, running a safety check before all the discussions can help recognize uncomfortable zones or pain points. The Scrum Master can prepare a safe space and promote honest feedback from the entire team for a friendly conversation.

Among the most popular techniques are:

• Sailboat: This retrospective technique helps any team struggling to stay aligned from sprint to sprint. Sailboat discussions improve team alignment and provide valuable feedback on project goals, issues, and assets.

• Mad, Sad, Glad: When a team feels burnt out or drained, this technique provides insights into the needs of the team and the emotions of team members.

• Start, Stop, Continue: Well-known and often used by Scrum Masters, this technique is a great way to examine the systems and habits of the team. It helps reprioritize team goals, focus on strengths, and overcome team obstacles.

• Starfish: This technique goes a step further than Start, Stop, Continue. Use this technique when your team needs a systems overhaul or more innovative workflow ideas, or when the team is looking for specific improvement actions that can be put in place in multiple areas.

Remember that you need to spend enough time planning for the retrospective meeting. Free-form techniques are great, but a little focus is even better. Don't invite too many participants to this meeting; more than 10 people can be too much. However, keep in mind that if someone can't participate, they should still be able to contribute. Also, make sure everyone shares what went well and what could be improved next time, so you don't focus only on what went wrong. Please don't forget to summarize all discussions at the end of each session. You can use stickers and markers or their electronic substitutes (for example, digital boards in Metroretro or Miro) to document everything and save the list of suggestions and action items for follow-up work that can be packed into tickets of the Product Backlog.

There are many other techniques that could be relevant in different situations, but the most important technique is trust. Our goal is to create an environment where people are relaxed, fostering a friendly atmosphere because only then can they do their best. Every voice must be appreciated and heard. It is essential to motivate your team to learn, move forward, not be afraid to make mistakes on that journey, and be able to solve conflicts and speak openly about all issues that happen. As Thomas Edison once said: "There's a way to do it better – find it." So our goal is to find this better way for continuous improvement 😊.