Retrospective

Avi Siegel

•

10 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

Pro Tip: An implicit goal of Retrospectives is to create a general feeling of transparency and collaboration amongst the team. Give team members the opportunity to feel their feelings and air their thoughts, but importantly without assigning blame. It doesn’t matter who may have caused a particular issue; it only matters that the team is working together to improve things going forward. Any finger-pointing can quickly destroy the desired openness the meeting is meant to enable.

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

Pro Tip: Often teams will choose one format, and stick with it until someone voices that they need or want something new. To get ahead of this, but more importantly to keep things fresh and ideas flowing freely, consider switching up the format (perhaps even as often as every Retro).

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

Pro Tip: To ease the burden on the team’s individual memories, it is a good idea for each participant to take notes during the sprint, in preparation for the Retrospective ceremony, so as to not lose track of useful feedback. By the time the end of the sprint comes, it’s easy to have lost the context of why a given thought was important or relevant, or forget it entirely.

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)

Pro Tip: It’s common for teams to leave it to the EM leading the discussion to group the discussion points themselves. But, everyone can participate in this part to speed it along. This is more of a logistic step - the faster it goes, the more time there is for the meat of the meeting (i.e., discussion).

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.

Pro Tip: The EM should be careful not to speak too much. This space is mostly reserved for the engineering team to provide their thoughts, complaints, and ideas. The EM should chime in only when necessary to keep the conversation moving and help conclude any action items.

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.

Pro Tip: Action items should be iterative in nature. For instance, if a given process is not working well for some reason, focus on a relatively small change that can be made to improve the situation. Sometimes it will indeed be necessary to rebuild a process from the ground up, but that should rarely be the first option.

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.

Pro Tip: It may not be enough to leave the action items here. If necessary, it’s on the engineering manager to check back in with the assigned parties between Retros to ensure they are making the necessary changes to their workflows.

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.

Pro Tip: The product manager isn’t always a welcome addition to Retrospectives. When this is the decision, it’s generally so the rest of the team can 1) focus on engineering-specific issues, and 2) feel comfortable bringing up issues about the PM side of the house (which the EM would then separately discuss with the PM). If the PM is in fact invited, they must recognize that, unlike many other meetings they attend, this is not their meeting, so they must be careful not to overstep their authority, attempt to run the meeting, dominate the meeting with their opinions, or get defensive when product-specific issues arise.

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.