3 Key Steps to Make a Retrospective More Efficient

No matter how you organize your team’s work, whether it be Scrum, Kanban, Waterfall, or none of the above, I highly recommend conducting Retro (short for Retrospective) calls with your team. It’s the easiest and fastest tool to identify problems, blockers, and bottlenecks affecting your team’s performance. In this article, I am not going to explain how Retro works in general; instead, I would like to focus on three things I personally use to make my Retro more efficient, useful for both managers and peers, and effective in solving problems.

Focus on Action points instead of Positives and Negatives

2 signs you need to do that:

1. Similar problems have been raised before or are raised every time.
2. Retro has only a psychological effect; it doesn’t improve work processes or solve existing issues.

If some of the points above are valid for your team, convert the last column on the Retro board into a TO-DO list:

1. For every problem written in the Negatives column, come up with an Action point. Avoid generic ones; instead, formulate it as a clear task (e.g., instead of “Improve testing,” write “Schedule a call every two weeks to perform battle testing before release; invite John and Sam”).
2. Assign every problem to a dedicated person. If it’s a one-off task, create a ticket. If the solution requires regular work, document it or create a recurring calendar event to remind.
3. Start every Retro by reviewing previous action points. If something wasn’t done, understand why. Copy that action point to your current Retro and update it to ensure achievement. This way, every team member can see that their problems are addressed and not forgotten, and the Retro is not a waste of precious time.

Collect Negative Feedback All the Time Instead of Last Minute

Imagine you have a Retro on the last Friday of each month. If a problem occurred on the first Monday, there’s a 99% chance you will forget about it. Collect negative feedback through all channels and write it down on the board immediately to not miss a thing. Here are some situations when problems are raised but usually forgotten:

1. The problem was raised in the middle of a long Slack thread.
2. You have a shy engineer who usually doesn’t highlight problems on group calls but can mention it in a 1-to-1.
3. The problem is a reason for some behavior but is never reflected. For example, your iOS and Android engineers started working at the same time. iOS is done, but the Android engineer in Standup says, “I need two more days for development and one day I am going to test every scenario manually.” It’s a perfect situation to understand if there’s something you can improve as a manager. Does the development take more days due to legacy code you can refactor next quarter, or is the lack of UI tests on Android making the engineer do manual testing? The engineer is already accustomed to such a situation, so ask clarifying questions to exclude problems to be solved.

Create Space for Everyone to Speak

1. Question every person affected by the problem. Using a legacy code example, ask each Android engineer in the team, one by one, for their opinion on what action point we can take. Depending on temperament, you may hear answers ranging from “Rewrite everything” to “It’s okay, I can work with it.” After everyone has spoken, ask engineers from other platforms about their usual approaches. Finally, come up with an answer that satisfies every team member, especially Android engineers affected by the mentioned problem. Don’t turn it into a process where an engineer mentions a problem, provides a solution, and you simply move on to the next issue.
2. Don’t mix problems and action points. If someone wrote three negative points in one, split them and discuss each separately. Don’t be afraid to spend more time; use the approach from the first piece of advice to gather as much feedback on each of the three problems as you can.
3. Don’t be afraid of making the wrong decision. If, in a problem with legacy code, you agreed on an approach of minor refactoring but noticed no results, raise the problem again, gather opinions, and choose a different action point. Perhaps this time, you can try a more radical approach from another engineer. Such a situation will be correctly accepted by team members; the approach of one engineer didn’t work, the problem persists, and now we proceed with an approach from another engineer.

Conclusion

In my opinion, Retro is the most effective tool to find and solve team problems. Unfortunately, Retro is like going to the gym; if you skip it often or do it without commitment, it won’t have any effect. Focus on making every Retro useful, and you should see positive results soon!