How to do Retrospectives with your Remote Teams
Introduction
I joined JULO as a Scrum Master in Q3 of 2022. Scrum had already been implemented at the time but doing retrospectives effectively was a big challenge as the Developers work remotely. Over time, I’ve come up with a few techniques to take on this challenge that may be useful for others.
Work from Anywhere
Last year, Engineering teams organized an outing as a chance for everybody to meet one another in-person. Since the pandemic hit, the Developers have been working remotely. Most of us in Jakarta, some in Bandung, and a few others in other cities. Around the same time, the teams also have grown. For product engineering, JULO comprises into 6 tribes, each containing 11 Squads. Therefore, delivering products requires us applying a framework effectively.
Retrospective as part of Scrum Framework
A framework like Scrum is purposefully incomplete so that the team adds whatever necessary to reach the goals. It provides a basic structure, guidelines and principles. Like Google Map showing places relative to one another. For directions, it provides the starting and the end points as well as the recommended route. However, it gives flexibility how we are going to take the path. We believe the Retrospective is an essential part of the Scrum that often requires flexibility to make it work.
The Retrospective Questions to Ask
“By the end of the sprint, the team inspects the processes, tools, individuals, interactions.”- Scrum Guide
Based on the well-practiced guide, there are four questions that we ask as a template for the squads:
- Is there anything that makes you frustrated and the team should drop it?
- Do you have any ideas you’d like to introduce in our team?
- What would you like to keep in our team and why?
- What is your burnout rate level?
4 Elements of the Retrospective for our Remote Teams
We’ve learned that for retrospectives to be effective, we have to starting thinking about it before the session, we have to have some guidelines, get in the mindset of problem solving, and go out with actionable items.
1. Preparation
We use two online tools that are essential for preparations:
- Retro Tool app for online retrospective boards,
- Yerbo app to measure the burnout level.
The links to the Retro Tool and Yerbo app are sent one hour before the meeting, so the squad members can give their thoughts earlier separately. This will maximize the 1 hour session for a full discussion.
If some of the squad members are unable to join, they are responsible to inform the squad on Slack and provide a valid reason for it. However, they still need to share thoughts on the retrospective questions.
If most of the squad members are busy, we reschedule the retrospective instead of cancelling because it’s an essential activity for the squad to inspect and adapt as they work together.
2. Guidelines
We conduct retrospectives on Google Meet and participants are expected to have their cameras on. To strengthen personal connections between members, I ask the team to open their camera. A picture is worth a thousand words and a video amplifies that saying. When we see one another, squad members can be focused and actively participating, creating the same atmosphere like being physically present with one another. We also encourage live chats during the session and sometimes it can start with ice-breaker topics to get to know the people more.
When discussing difficult technical problems, for some members it can be difficult to communicate in English. We allow everybody to speak in Indonesian first and have others translate the meanings to English. Another example of having some flexibility to increase engagement.
We believe having a meeting agenda creates structure and gives full context so the session can be effective. The meeting agenda is divided into 4 sessions:
- Reviewing Jira Reports. Mainly looking at the Completion Rate, the Sprint Burndown and the Velocity update.
- Evaluating action plans from previous retrospectives.
- Discussing the points gathered on the retro board.
- Summarizing the action plans.
Finally, the participants are limited for the Scrum Team only (the Product Owner, the Scrum Master, the Developers). The Stakeholders are typically not invited, as their presence might make the members hesitant to open up.
3. Problem Solving Mindset
Like in the onsite setting, we gather all insights on the retro board and base our discussions from there, so that we can get into the problem solving mindset.
Despite having the preparations and guidelines above to overcome the lack of in-person interactions, minor things being expressed can still be understood the wrong way. So, there is a simple mindset that I repeat in every session to ensure to eliminate hard feelings.
“Attack the problems, not the people.”
Discussing a failure on achieving the sprint goals is typical. However, certain problems require more in depth discussions. In these cases, we branch out the retrospective into a separate Root Cause Analysis (RCA) session per each problem. At JULO, we normally produce RCA documentation and organize sessions for solving technical problems, and we utilize the same format for feature development issues.
Comparing retrospectives and RCA sessions:
- Retrospective: discussing based on the start-stop-continue questions
- RCA: discussing what went wrong, what the impacts are, how likely it would happen again, how can it be detected, solutions and mitigation actions to prevent similar problems in the future.
We can see the RCA format extends the Retrospective questions deeper, giving an effective way to address why particular feature development has failed and to address prevention.
To ensure everyone’s concerns are heard and addressed, as a Scrum Master, the key mindset for me is to ask open-ended questions. I take notes from comments and opinions that each member says during daily stand-ups during the sprint. During the session, if the team is being silent, I would ask specific members a question like “How is your workload? I remember you saying that in the past few sprints have been tough for you. Would you like to elaborate on that?” This usually helps to kick start in-depth discussions.
4. Closing
In retrospectives, I act as the facilitator. So I ensure that at the end I wrap up the session by summarizing all the points mentioned and repeating the action plans, which may be taken directly in the next sprint or to be done over time across sprints. After the meeting, I write everything down as retrospective notes and share them again for the squad as takeaway items.
Takeaways
There are several things to consider when doing retrospectives in remote teams:
- Preparations: using the right collaboration tools, gathering thoughts before the session, and ensuring people can be present and focused.
- Guidelines: what ground rules to set to ensure focus, inclusive participation, and high engagement and how the session agenda is structured.
- Problem solving mindset: Focus on problems, not the people. Go deeper into problems with RCA mode. And asking open-ended questions.
- Closing: gathering points and ensuring action plans are tracked.
In Scrum, there are three pillars: transparency, inspection, adaptation. I do believe the retrospective is an important tangible application of these pillars for deriving knowledge from our experiences and make progress towards creating a great product. As a Scrum Master, using these pillars personally, I am also able to make retrospectives effective for remote teams.
Reference
- Scrumguide https://scrumguides.org/
- Scrum Theories and Values https://www.scrumalliance.org/learn-about-scrum/scrum-elearning-series/scrum-theory-and-values
