Running a simple and effective retrospective meeting remotely

Besides being a software engineer, I also play the role of Scrum master for my team. Time management is really challenging sometimes and it's important to use it efficiently, both for the company, the team and myself.

In this post, I want to share with you a very simple, but efficient approach I'm applying for running retrospectives in my team. The first time I used it was in 2012, in a team with around 12 people. As you can imagine, it was a bit bigger than the usual recommendation of 7 people. We had to be efficient in our meetings and the whole team had a very good understanding of how important a Retrospective meeting is to keep improving the process.

Our sprint used to last 3 weeks and the Retro, of course, was happening at the very end of it.

We used to have a physical board next to where the team was located and this board had 6 columns with the following headers:

• +3
• +2
• +1
• -1
• -2
• -3

The idea was to collect all the sprint facts there, and classify it according to the degree (how good or bad we judged the facts).

Here are some examples:

• Let's say a new team member joined the team and I'm happy with it: I'd go to the +3 column and add a post-it: I'm happy that Cristiano joined the team.
• Cristiano, a new team member, is also happy with how supportive the team is. He goes there and add a +3 post-it saying: 'The team is really supportive' (yes, this team is so friendly that we could say we use +3 column almost as Kudos! 😁)
• The instability of Bamboo made some of the automated tests fail as false-positives, and it happened quite often. Someone goes to the board and add a post-it to the -2 column and says: 'Bamboo was too unstable and the delay affected the sprint goals'

I think you got the idea already, right? So… What happens is that at the end of the Sprint, when we are running the Retro, the scrum master was collecting the items, reading and discussing with the team one by one, and for each item, we were assigning some action items to someone, with a deadline (as in any other Retro).

There are many different Retrospective formats, and most of them will suggest different ways to collect these facts during the Retro. It's totally fine too, and it's always good to do something different, but depending on how your team spend time on discussions, it can be a precious time you could save if you collect these items beforehand.

The biggest benefits this approach gives you is that:

• By collecting the facts before, you save time in the retro since you don't have to run any dynamics to try to find improvements to do
• Everyone can check at any time the items that are going to be discussed in the Retro, so they can prepare and also have good ideas/solutions to keep improving the way of working
• A culture of continuous improvement is developed in the team

Normally I have funretrospectives as a reference for getting new ideas for running different types of retros. When we're working on-site, it's easier for me to observe the team and interact more, so I try to get new ideas aiming to trigger some discussions and drive the team towards specific topics, but since we started working remotely, I decided to use this format I presented, with small changes, and the results are very positive.

How it works?

A Trello board with the following columns:

• What went well
• New ideas
• Not so well

The team is asked to add their topics (sprint facts/ideas as cards in the columns) there during the sprint and everyone from the team has access to the board (It's important that everyone should know this is a safe space).

Normally in the day the Retro is happening, I send a reminder in the team's slack channel so that they have their last chance to add anything they want to discuss.

When we start the Retro, I share my screen with everyone and show the board, then I go item by item and ask the person who added it to say some words and let it clear to everyone why we should discuss this.

Next, I create another column named temporarily as Priority list and ask everyone on the team to vote 3 times on the topics they want to discuss (Trello has this Voting plugin that's very easy to install and use).

Once people finish voting, I sort the cards per priority on the Priority list column and we start discussing the topics.

From now on, it's no different from other retros. We discuss the topics, we take action items and we move forward.

Once the Retro ends, I rename the priority list column to Discussed on <date>, and that's it. (Well.. in my case since Trello is just a temporary tool, so I also document it on Confluence, but this is not relevant for you 😉).

Retrospective meeting board on Trello

Some learnings I got from my team:

• In the first times you’re applying this, since the team might not be used to it, they might not add many topics. If you want to create this culture, you should not let them add new tickets AFTER the retro starts (yes, we're educating 😉). Remember: one of the purposes is also to save time by using it more effectively. Also, an advice for the first time, try to add as many topics as you notice (as scrum master, you have to observe the sprint facts so, you'll definitely have items for it).
• If someone approaches you to comment something that happened during the sprint (while it's in progress), ask them to add a post-it about it in the board. This is a way to motivate them and it helps a lot!
• Since we sometimes have too many topics and can't discuss all of them in one single Retro, I created a Parking lot Column to accommodate these remaining items, so that we keep it for the next retros (if people vote for them, we respect the priority).
• After doing this for a while, the team gets into automatic mode. It might be good to do some ice breaker games or try some different approach once in a while to promote other types of interactions between team members.
• If someone asks you: Why don't we use a miro board? Just say it's for simplicity reasons! (I'm kidding 😆 o̵r̵ ̵n̵o̵t̵)

I've always been passionated by Software engineering. In my Computer Science bachelor thesis had to study 14 different methodologies (Scrum, XP, RUP, Waterfall, FDD, ADDIE and many others). Each of them normally has a purpose and also a context where they were created/applied. Being a huge fan of agile practices, my advice is: no matter which format you decide to do, do it! Retrospective meetings are the most important meeting for a team to keep working great and happy!