A new meeting notification pop-up often steers a slight feeling of dread. Poorly planned or pointless meetings erode productivity and make distributed workers frustrated.
Fortunately, retrospective meetings aren’t like that. They come with a clear goal, some feel-good discussions, and clear-cut follow-up action plans.
This guide explains why retrospective meetings help build stronger, happier, and more productive software engineering teams.
What is a Retrospective Meeting in Agile?
A retrospective meeting, retro for short, gives Agile teams an opportunity to reflect on the past work cycle and identify ways to improve during the next run. Retrospective meetings are also called Scrum retrospectives. The two are the same thing.
The Agile framework promotes continuous improvement through incremental, ongoing positive changes. The Ninth Agile principle in the Agile Manifesto states:
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
Retrospective meetings are the embodiment of this principle. It allows teams to contemplate on the achieved results, analyze the mistakes, and then incorporate all the learnings into the Sprint processes.
During a retrospective, each team member is encouraged to think about the following questions:
- What worked well for us?
- What did not work well for us?
- What actions can we take to improve our process going forward?
In other words: Everyone is encouraged to celebrate the wins and acknowledge the shortcomings, but without casting blame. A retrospective meeting in Agile promotes constructive, candid evaluations of the past working cycle. All the shared ideas get documented, evaluated, and shaped into suggestions for further improvements.
Note: Don’t confuse Sprint retrospectives with Sprint Reviews. A Spring Review (SR) focuses on discussing the shipped product or features, whereas a Sprint retrospective facilitates the discussion about team processes.
Overall, Agile retrospective meetings are a simple, yet effective practice, which is used by collocated and distributed teams.
What is the Goal of the Sprint Retrospective Meeting?
The purpose of a retrospective meeting is to reflect on and analyze the last working cycle. Its main goal: Identify blockers, weak processes, and other annoyances hindering the software engineering team’s progress.
Clinical studies have proven that self-reflection enhances a person’s ability to perceive the emotions of others, show altruism, and develop higher emotional intelligence. In a group setting, reflection promotes greater bonding, a sense of trust, and better coherence in execution.
Generally, regular Agile retrospectives:
- Promote a transparent and safe work environment
- Highlight the teams’ strengths and weaknesses
- Help identify bottlenecks in processes
- Create more realistic expectations
- Improve project planning and management
- Increase team morale and engagement
According to the Annual State of Agile Culture Report 2022, teams with mature Agile practices are happier, more productive, and more open to embracing change — and regular retrospectives are essential for building such an environment.
Source: Annual State of Agile Culture Report 2022.
Who Leads the Sprint Retrospective?
Traditionally, Scrum Master leads retrospective meetings. Although, Product Owners or Project Managers also frequently take the mediator role. In fact, any team member with strong people skills can lead a Sprint retrospective meeting. However, they must agree to do so each time. Having the same retrospective meeting host is essential for building trust and consistency.
One of the key values of outsourcing IT partnerships we cultivate at Edvantis is transparency and consistency in all communication, be it among the teams or with our clients. Sprint retrospectives offer a great opportunity to raise legit concerns (which we encourage to do in our Code of Conduct) and cultivate a culture of open, candid conversations around work, which result in better operational results for our clients and our company.
How to Run a Remote Retrospective? Best Practices
Let’s start with the basics: Each retrospective meeting, remote or in-person, roughly follows the same structure:
- Set the stage
- Gather data
- Exchange insights
- Decide what to do
- Close the retrospective
Such a retrospective meeting agenda helps the participants come well-prepared and have a productive, meaningful discussion. Retrospectives encourage active participation from every team member and open opinion sharing.
That said, without some boundaries, retrospectives can get chaotic. The meeting leader should always remind that the scope of the meeting is limited to the last Spirit / release itself. A retrospective isn’t the place to rant about peripheral issues such as wider operational problems (e.g., long approval times for new software) or personal grievances (e.g., a recent health issue).
New and experienced team managers alike occasionally struggle with leading remote Agile retrospectives. If that’s your case, here are several best practices to try.
1. Select The Optimal Retrospective Technique
Looking for some fresh retrospective ideas for remote teams? Here are the four options we recommend!
4Ls Retrospective
The premise: During the meeting, encourage a discussion about the things your team loved, loathed, learned, and longed for during the last Sprint.
Prepare by setting up a shared document with these 4L columns. Open the meeting with a quick recap of the key project milestones, celebrate the wins, and thank everyone for the great job. Encourage the participants to share their own “victories” too.
Afterward, move on to discussing the 4Ls. Ask everyone to contribute their ideas. Write everything down in the document. Time this part of the meeting to 15-20 minutes tops.
Once you have everyone’s thoughts, select one most pressing item from the Loathed list and think how you can deal with it. Ask each person to contribute opinions. Then analyze the Longed for a list and select item(s), that you could easily incorporate into the next sprint.
Mad, Sad, Glad
The premise: This retrospective play encourages the team to analyze their emotions and share their feelings with the rest of the team. It’s a great technique for measuring the team’s physiological health and diffusing some long-term tensions.
Share a virtual whiteboard with three columns:
- Mad: Everything that made your blood boil during the last work cycle.
- Sad: A laundry list of frustrations, disappointments, and mood-tankers
- Glad: Everything that made you feel positive
Give the participants 15 minutes to add their ideas to each column. Then block another 20-25 for discussion and reflection.
The Mad, Sad, Glad technique helps the team to get more comfortable with sharing their emotional responses to different events. It also helps everyone better understand the emotions of other people and other POVs. For example, Sam may see nothing wrong in being perpetually late to meetings with Sarah. But Sarah feels hurt because she thinks that Sam disrespects her time.
A candid discussion about feeling helps build better team bonds and fosters a safe, trusting work environment.
Starfish
The premise: As the name implies, Starfish retrospective meetings are shaped by five questions:
- What should we keep doing?
- What should we do less of?
- What should we do more of?
- What should we stop doing?
- What should we start doing?
The outcome is a visual snapshot of your key processes: You can easily see if there’s a negative bias towards one side (e.g., things to do less). Or on the contrary — a high degree of satisfaction with various events, which should be replicated in the next work cycle.
Fundamentally, this retrospective idea encourages the team to think about the value generated by their actions. Then reflect on the ways to optimize value production by addressing the hindrances and areas of dissatisfaction.
Scrum Values
The premise: A classic retrospective technique, built around the discussion of five main Scrum values: Openness, courage, focus, respect, and commitment.
Create a 5-column chart of a digital whiteboard and ask everyone to rate the Sprint based on these values, on a scale from 1 to 5. One stands for the lowest rating and five — for the highest.
After the votes are cast, encourage each member to speak up on their reasoning for the selected score. Ask them to provide concrete evidence and examples of how each value was (or wasn’t) properly cultivated. For example, “I assigned 3 to openness because the Product Team wasn’t really straightforward about giving feedback on the suggested changes to the set of user stories. The request bounced between several people until it reached the Head, who finally made the call.”
Based on the expressed sentiment, create follow-up action plans.
2. Adopt The Right Retrospective Meeting Cadence
Scrum methodology encourages having retrospectives at the end of each Sprint.
Considering an average project lasts 11.6 weeks and a Sprint lasts 2.4 weeks, you should have at least 4 retrospective meetings throughout each project.
OK, but how long should each retrospective meeting be?
Ideally, you should plan at least 45 minutes per week of project work. So if your last Sprint was 2 weeks, block a 1.30-hour slot.
That said, there’s no hard rule on Sprint retrospective duration. Adjust the meeting length and frequency, depending on the current Sprint’s size and/or importance. For example, plan a longer project retrospective meeting at the end of a bigger Sprint that marks a new product release.
As a rule of thumb, check in with your remote team to understand how they feel about catching up. Then schedule the retrospective meeting at least 3 days in advance to give the team enough time for prep.
3. Use Digital Props to Steer Online Discussions
Sometimes getting the entire distributed team on a video conference can be challenging due to time-zone differences or schedule conflicts. Also, video tools don’t allow the same conversational flow as an in-person interaction, which means that not all people will get equal “screen time”.
To address these challenges in remote retrospectives, combine async independent reflection with real-time group discussion.
Use a simple retrospective template to collect preliminary ideas and share ground rules for in-person discussion. Then go through these during a video call. This way, you can give everyone time to contemplate their outputs and perhaps even come up with possible issue-resolution strategies to talk through in real-time.
Here are several other great remote retrospective templates:
Pick a simple, sharable option, which supports real-time editing.
4. Cultivate “Blameless Culture”
The purpose of a retrospective is to learn and reflect, not seek and moralize the “guilty”. And it’s a powerful practice for creating a culture devoid of blame within their teams.
The idea of “blameless post mortems” was originally popularized by the Etsy engineering team. Etsy’s former CTO, John Allspaw, described their blameless culture as such where “you’re making an effort to balance safety and accountability”. This means that all the mistakes are analyzed through the situational aspects of a failure’s mechanism and the person’s decision-making process leading up to the failure. By adopting such an approach instead of traditional “punishment”, organizations could become much more resilient.
The “blameless” approach was later picked up by Google and many other Agile teams. When discussing any sort of failures during a project retrospective or post-mortem analysis, people are encouraged to candidly speak about:
- Actions taken
- Effects/responses observed
- Expectations they held
- Assumptions they made
And the discussion happens without any talk about “blame” or punishment.
Failure is a powerful source of learning. Early admission of mistakes helps detect and resolve issues earlier (i.e., at the development stage of the SDLC rather than in production). So another important goal of retrospective meetings should be open conversations about failure and mishaps.
5. Always Create a Follow-Up Plan
Retrospective meetings aren’t just for airing complaints. The team should jointly decide on how to make things better for the next run.
Based on the identified “negatives”, create a concise list of action items you’ll address before the next meeting. If a lot of ideas emerge in the “Actions” category, vote on which ones you’ll immediately prioritize.
Transfer the selected items into a documented follow-up plan and monitor its execution.
You can create a separate Kanban board for retrospective action items. Or add the current list of retrospective actions to the top of the Sprint backlog to keep them visible at all times. Afterward, use the Daily Scrum meeting to ask about progress on your retrospective action plan.
This way you create an ongoing culture of accountability and encourage team members to continuously improve their behaviors. A list of cross-off Action items also creates a sense of accomplishment among your team and helps them stay motivated.
Conclusion
Thanks to all the digital tools, remote retrospectives don’t differ much from in-person ones. Follow the best practices of avoiding blame, giving everyone one opportunity to speak, and following through with the identified action for improvement. Mix things up once in a while by trying new retrospective ideas — and you won’t struggle with low software engineering team morale or engagement levels!
Agile methodology is a cornerstone operational practice at Edvantis. By partnering with our managed teams, you get to also benefit from our lean best practices for software engineering and team coaching.
FAQs About Retrospective Meetings
Sprint retrospectives are typically scheduled at the end of the Sprint, which is roughly every 2-3 weeks. A retrospective gives your team to analyze the completed work, evaluate the shared processes, and make necessary changes for the next work cycle.
There are several ground rules for conducting effective retrospective meetings:
1. All opinions and experiences are valid
2. No one person should dominate the discussion
3. Mistakes are for learning, not mocking or blaming
4. Nothing should be made personal or taken personal
5. Approach the discussion with an open mind
These ground rules help create a safe, trusting environment for discussions.
No. Other manager(s), apart from the one leading the meeting, don’t get invited to a retrospective unless each member explicitly agrees to have them in one of their sessions. A new person will inevitably change the team dynamic and may undermine the session efficiency if the team feels shy or wary about speaking openly in front of the invitee.
Everything that has nothing to do with the processes during the last Sprint should be off the table. Likewise, all the product or engineering-related discussions should be conducted during other meetings. The focus of a retrospective is discussing the team’s workflows and interpersonal dynamics above anything else.
