Retrospective
Avi Siegel
•
5 min read
What is a Retrospective?
A Retrospective, often shortened to “Retro”, is a recurring ceremony held after a sprint is closed out. It’s a dedicated time for the development team to reflect on their way of working, celebrate successes, identify challenges, and create actionable plans for improvement.
As a cornerstone of the Agile methodology, Retrospectives embody the principle of continuous improvement (as laid out in the Agile Manifesto), allowing teams to adapt and evolve their practices over time.
What are the goals of Retrospectives?
The primary goals of Retrospectives are to:
Give the team a pressure-free space to think about what may have gone imperfectly in the previous sprint, and collaborate on ways to do better in the future
Ensure the team agrees to act on specific plans for exactly how they can make continuous, incremental improvements to their work processes
What is involved in a Retrospective?
A Retrospective is a typically 30-60 minute meeting during which the engineering manager (EM) leads the development team through an open discussion as to how the previous sprint went and what could be done better in the future. The product manager (PM) may also be there, but that is at the discretion of the rest of the team.
Together, the team will run through the following activities.
Revisit action items
Before getting into new Retrospective topics, the EM should bring up action items from the previous Retro, to discuss progress with the team. This step is paramount to ensuring the team is actually making progress toward building a better working environment, and not merely using the meeting as a session to complain and/or pat each other on the back.
Gather thoughts
Collect information from all participants about what happened during the sprint. This exercise may or may not be anonymous, depending on how comfortable the team is at expressing their viewpoints publicly.
The EM is responsible for providing the format for the Retro - a set of top-level categories that spur thinking from different angles. For instance:
Start / Stop / Continue
Drop / Add / Keep / Improve
Mad / Sad / Glad
4 Ls: Liked / Learned / Lacked / Longed for
Original 4: Wins / Improvements / Learnings / Questions
Sailboat: Winds pushing us forward / Anchors holding us back / Rocks risking our future / Island destinations we seek to reach
To refresh their memory as to what went on over the course of the sprint, participants should review their activities. This includes:
Tasks worked on (whether by way of coding, reviewing, collaborating, etc.)
Calendar entries (meetings, reminders, tasks, etc.)
Communications (emails, Slack threads, etc.)
Anywhere else with evidence as to what happened during the sprint
Note that this is not (yet) the time for deep analysis, but rather for a brain dump of what went well and what didn’t. As such, it is important to not get overly detailed with the information written during this part of the Retrospective meeting. Brief titles should be sufficient so that others who may have been involved can recognize what each thought is specifically pertaining to. In a later step, more in-depth conversation will happen.
Group thoughts into discussion topics
Once everyone’s thoughts are on (likely digital) paper, pool related thoughts into the same buckets. This typically takes the form of stacking post-it notes on top of each other, so as to lessen the total number of remaining topics that will be discussed in the next step.
Possible reasons for grouping include:
Thoughts that are truly saying the same thing
Thoughts related to the same task or process, for which the topic can be summarized at a higher level to enable broader discussion about said task or process
Thoughts that are unlikely to warrant action items or deep discussion (e.g., successful closing of multiple epics)
Don’t overdo this grouping activity. It’s always technically possible to keep thinking one level higher, and continue grouping until there’s a single stack of items. The intent here is not to have less topics to discuss, but rather to streamline the conversations to come.
Vote on topics to discuss
The team won’t necessarily have enough time to review all topics together. So, it is imperative that they prioritize topics based on where they think useful, collaborative, actionable conversations can occur.
Typically each team member will be granted a certain number of votes (dependent on how many potential discussion topics there are), to be allotted in any quantity (perhaps up to a reasonable maximum) toward any specific topic. For instance, if there are 15 total discussion topics, each team member may get 5 points to assign to topics, with a maximum of 3 points to any individual topic.
Once all votes are assigned, reorder the list of topics based on the number of points each topic received.
Discuss topics and determine action items
The engineering manager will lead the group through discussion of each topic, in decreasing order of votes received. The EM will open a given topic to the floor by way of brief introduction, and then immediately step back to allow discussion to take place.
It is useful, but not required, for the person who added a given thought or topic to provide additional context as to why the topic is up for discussion. Remember, the exercise to gather thoughts is often anonymous, so don’t force anyone to speak, even if it is obvious who wrote something.
When conversation has mostly died down (or if a reasonable amount of time has passed, and for the sake of time, discussion needs to move on), the EM should transition to the next topic. Before doing this, though, the EM should make sure that whenever relevant, there is an action item, specifically assigned to someone, to improve or fix a given issue.
Review action items
Before ending the meeting, the EM should review all discussed action items to bring them back to the forefront. After deep conversations occur in a Retrospective, some action items may have already been lost in the shuffle, so it’s important for the team to be reminded.
Who should attend Retrospectives?
Retrospectives are primarily for the engineering team to improve their way of working. As such, the following individuals should be invited:
Engineering manager (to facilitate the meeting)
Engineering team (to provide their thoughts and collaborate on improvements to be made)
Optionally, the product manager may also be invited to collaborate with the rest of the team. However, it is important they understand that the meeting is designed for the engineering team, so they must not overstay their welcome.
How should the team prepare for a Retrospective?
All invitees should come to the meeting with thoughts on what they’d like to discuss, so as to lessen the amount of time necessary to gather those thoughts during the early stage of the meeting.
Beyond the above note, each role should further prepare as detailed below.
Engineering manager
The engineering manager is the facilitator. As such, they need to enter each Retrospective prepared to lead the conversation. They should especially:
Become familiarized with the steps the meeting will take
Choose the format for the Retro (i.e., the categories to spur reflection from different angles, which can optionally change Retro by Retro)
Select and acquire the technology the team will utilize (whether using paper post-it notes on a physical whiteboard, or a digital product to mimic the approach in a collaborative application)
Engineering team
The development team’s most important pre-meeting tasks are to:
Come prepared with thoughts they’d like to add to the conversation - it can be productive to write down these thoughts as they occur over the course of the sprint
Come prepared to have an open and collaborative conversation - this may be a mindset shift if they have been spending their time in a focused zone of individual contributor work
Product manager (optional)
If the product manager is invited, they should mostly be there to add context and hear how they themselves can do better so the team can be more productive. They can, and still should, come with their own thoughts, but they should be limited in nature to ensure the PM doesn’t accidentally dominate the conversation.
Best practices for Retrospectives
Create a safe space. Foster an environment where team members feel comfortable sharing honest feedback without fear of retribution. You don’t want team members to stew in their anger or frustration, and you can’t fix what you don’t know is broken. All that said, steer the meeting away from any playing of the blame game.
Be reasonable about when Retros are scheduled. Retros should happen after the end of the previous sprint, but they don’t necessarily need to happen before the start of the next sprint (i.e., Sprint Planning). Depending on which ceremonies your team performs at which times, it may be unrealistic to squeeze yet another meeting into a given day. And that’s okay! Just make sure to not delay more than a few days; otherwise conversation will too easily bleed into being about the current sprint.
Timebox each step of the Retrospective process. Gathering thoughts should take 3-5 minutes. Collating thoughts should take 1-3 minutes. Voting should take 1-3 minutes. Discussion on any given topic may need to be a bit more flexible depending on the conversation at hand, but ensure time is left for all important topics. Of course, the above time constraints are just suggestions to start with - iterate based on what works best for your team.
Retros are not meant to be complaint sessions. It is fine for team members to express frustrations (as long as there is no finger pointing), but by the end of the meeting all negative thoughts should be accompanied by an action item to address the issue.
Focus on actionable outcomes. It is easy for the team to get carried away with casual conversation about a given topic, or simply become repetitive with what is being said - it is important to keep the spotlight on topics which can lead to iterative improvements for the team.
First focus on problems, then focus on solutions (akin to how proper product development is done). Force conversation to first dive into the issue. Once the problem is truly fully understood, it is easier for the team to be more creative and robust about what the available solution options may be.
Celebrate successes! It’s true that the main purpose of retros is to fix what is broken, but there are lessons to be learned in what went well, too. Plus, making space for hard-earned congratulations can help keep motivation high.
Allow Retrospectives to be chances for the team to breathe. The engineers literally just sprinted. They may still even be in sprinting mode, trying to multitask during the conversation - don’t let them. Give everyone the opportunity to stop focusing on heads-down work, and raise their heads up to think about the higher meta level of how they work.
Don’t skip Retros. Many teams tend to skip the Retrospective meeting altogether because they don’t see value in it. Often, those teams are right - they are indeed getting no value from the meeting. This is typically because there is too much focus on back-patting or complaining, with no focus on how to take action to make the situation better. This is easily addressable by limiting (but not completely removing) overly-positive discussions, and forcing negative conversations to conclude with the assignment of action items.