12 Tricks for Running a Retrospective Meeting that People Actually Enjoy

Agile retrospective meetings can be a double edged sword. When routine, they’re invaluable tools for improving our work and celebrating the team’s achievements—that is, until they become stagnant over time.

Your retrospectives should leave your team on common ground and feeling optimistic about the next phase in your agile journey. If you feel like they’ve lost a bit of that magic, your meetings might be missing a few important prerequisites.

Let’s go deep on 12 of these best practices for breathing new life into the process.

Trick #1: Create a safe space

A successful retrospective meeting requires safety first and foremost. It’s important that the team feels safe enough to voice their concerns without fear of retribution, otherwise you can’t get the full benefit from retrospectives. Problems keep cropping up if not addressed.

How do you break down that wall of fear? Two things come into it: who you invite and the expectations you set.

First of all, avoid inviting management. Even with the best of intentions, managers can stall progress if their presence intimidates people. You might want to invite folks from other departments, which is fine if necessary, but try to keep things within the team if possible.

As for expectations, you’ll want to create rules of engagement to keep everyone on the same page as far as what’s safe and off-limits. Rules like “listen with an open mind,” “express wishes instead of accusations” and “what happens in the room stays in the room” can help set the right tone before you get started. (Just keep the list to fewer than five—any more is too complicated to be practical.)

Trick #2: Make it a ritual

Consistency is crucial to productivity. And the more productive your retrospective meeting, the better its results and the more your team will look forward to it. Rules help, but ritualizing your retro is an even more powerful way to remind everyone to stop and reflect.

This in part means establishing a cadence and sticking to it. Even if you feel like nothing much came up in the last sprint, you’d be surprised what can come up when everyone gets together. Most teams meet for retros:

• At the end of each sprint for traditional two-week sprints
• Monthly or quarterly for kanban-style workflows
• Quarterly, if possible, for distributed teams

But why stop at the confines of meetings? Retros are about continuous improvement, and most valuable when the team is in the habit of thinking retrospectively all the time.

In his book Atomic Habits, James Clear says one of the most effective ways to get into this kind of rhythm is by habit stacking: latching a new habit onto something you already do. Try adding a few minutes to your daily scrum for a lightning-round-style “microspective” where everyone shares one reflection.

Trick #3: Amplify the good

Retrospectives are inherently meant for finding ways to improve your work. Safe spaces foster open discussion, which is great, but open discussion of the wrong nature can lead to finger-pointing, which criticizes people instead of the work. If bogged down in what individuals did or didn’t do, your retro will quickly become something your team dreads.

Instead, find ways to celebrate small wins and bring more positivity to your retrospective meeting. I like to sandwich it onto either end: beginning with what went well, then wrapping up with a round of acknowledgments where team members take turns in the hot seat and others volunteer what they appreciated about the individual’s contributions (“You really served the group when… and I’d like to see more of…”).

Your scrum master will be instrumental in guiding conversations in a positive direction and keeping your meeting on track. So…

Trick #4: Choose your scrum master wisely

This job takes someone empathetic and impartial, with the skills to:

• Remain objective. If the scrum master takes sides, team members might feel attacked and unable to contribute.
• Identify learning opportunities. The scrum master should be good at identifying exercises that can gain the most insight into problems bothering the team.
• Clarify insights. Let’s be real: engineers are technically minded and not always the most eloquent at expressing our thoughts. The scrum master should be able to act as interpreter to ensure all insights are understood by everyone.
• Ask questions. It’s not the scrum master’s responsibility to provide the answers, but rather ask relevant questions that help facilitate discussion.
• Summarize. This doesn’t always get enough attention, but the scrum master’s most important job is to clarify what’s been agreed and what actions need to get done.

Let’s unpack that last point some more.

Trick #5: Create clear actions

This point deserves to stand alone because unclear actions are perhaps the biggest sticking point in retrospective meetings. Whenever someone complains they don’t see the value in these meetings, their frustration can almost always be traced back to miscommunication.

You’ve probably heard of SMART goals:

• Specific: what do we want to accomplish?
• Measurable: how will we know when we’ve accomplished it?
• Achievable: is the goal realistically possible to attain?
• Relevant: is the goal worthwhile and applicable at this time?
• Time-bound: when do you want to accomplish it?

This is a great framework for retrospective actions, but there are a few areas that need special attention:

• The owner, or who Apple calls the Directly Responsible Individual. Try to assign one to each task to save confusion and work being replicated.
• Resources. Be sure everyone has everything they need to complete the task.
• The measuring part. The easiest way to decide if an action is measurable is to ask whether it can be defined as “done” or “not done.”
• Follow-up. You’d be surprised how many teams forget to check if previous actions were implemented, but it’s a critical part of evaluating improvement.

What you don’t want is a laundry list of action items. This is common, especially in projects with a lot of moving parts, but overwhelming and frustrating when you can’t get it all done. Instead, make small changes. Small, regular wins are proven to add up to something big.

Trick #6: Keep the format consistent

As well as making it a habit, try to formalize the overall format of your retrospective meeting. Here’s an agenda proven to work best for retros (see my this post on retrospectives for more detail):

1. Intro (5 minutes): Setting the stage by outlining goals and themes for the session
2. Discovery (10 minutes): Collecting and analyzing data on the results of the last sprint
3. Ideas (5 minutes): Brainstorming solutions to what went wrong
4. Decision (5 minutes): Choosing one to three solutions to take into the next sprint
5. Wrap-up (5 minutes): Assign action items and reflect on the retro itself

Bear in mind that there is no size fits all approach to retrospectives. Maybe you need more time to cover a larger team or scope of work. Or to start with an ice breaker. Whatever works for your team! Once you have the overall framework, you can have fun experimenting with each block of time—which leads us to our next trick.

Trick #7: Keep everything else fresh

Retrospectives should never be boring. Switch things up from time to time by varying your:

• Exercises. A common one is “what went well/not so well.” But there are so many other ways to analyze data, brainstorm ideas, narrow down solutions, and get people out of their shells. Try a tool like Retromat to randomly generate a new plan for your next retrospective meeting or refer to the Retrospective Wiki for more ideas.
• Environment. Analysis takes creativity and a lot of brainpower. A change of scenery can get those cogs turning. Try taking the team outdoors, or out to lunch, or to a coworking space, for example.
• Scrum master: A change of leadership, too, can ensure there’s no bias involved. You could even try different leadership models, like breaking the team up in pairs and having each pair lead a different part of the discussion.

Trick #8: Create a feedback loop

I’ve seen great leaders invest a lot of time and money into feedback training, and for good reason. You can’t be agile without feedback. Data shows 98% of workers disengage when they get little or no feedback.

So, encourage your team to offer constructive, tangible feedback when they can—good or bad. (Here’s a good HubSpot post on giving negative feedback without sounding like a jerk.)

And though it might seem a bit meta, it’s also a good idea to gather feedback on the retro itself. Retros need continuous improvement too. I’m not saying hold a formal retro for your retro, but do carve out a few minutes at the end of the meeting to check in on whether it was useful and what could change.

Trick #9: Record everything

When you don’t, it’s easy to forget or lose track of the topics and actions covered in each retrospective meeting. Detailed notes (or photos of the whiteboard if you prefer) will not only keep everyone up to date, but can also be used as data for future sprints.

My advice here is to share meeting minutes within 24 hours to ensure effective follow-up. Use document sharing tools to keep all action items and owners in one place and synced up.

And remember the rule “what happens in the room stays in the room”? Be sure to establish up front what must stay private and what can go public, and to communicate that company-wide. Oftentimes, managers make the mistake of assuming what gets recorded can be distributed. Again, this is counterproductive to creating a safe space. If your company is serious about knowledge sharing, just share on a need-to-know basis.

Trick #10: Get to the root cause

In order to improve, you need to find the right solutions to problems. And to find the right solutions, you need to know the root cause of problems. Without this deep understanding, any solution you come up with will probably be no more than a band aid.

As you might have noticed, the Discovery part of the agenda is the longest. That’s because root cause analysis deserves serious time. You can (and should) experiment with different methods to find one that works for you, so here are some of our favorites:

• Force-field analysis: Looking at the forces that drive or block movement toward a goal, then deciding which forces to strengthen or weaken forces to make the goal more attainable
• 5 whys: When you’re faced with a problem, repeatedly asking why it happened until you get to the true source
• Impact mapping: Defining the value of work by its “impact” (rather than just its completion) and mapping out project scope by four aspects: the goal, actor, impact, and deliverable

If you don’t take a disciplined approach to root cause analysis, you might be jumping to conclusions too quickly. But the first solution isn’t always the best.

Trick #11: Don’t jump to a decision

Experts say smart decisions result from two types of cognitive processes: intuitive and rational.

It’s important to follow intuition to a point. If the chosen solution doesn’t get the team excited, they probably won’t implement it effectively. But like root cause analysis, decision-making should be scientific and rooted in facts—and that’s where practical strategies can help.

Common group decision-making models include:

• Consensus, the most popular for retrospectives, whereby you negotiate the decision until all group members support it to some degree (not necessarily unanimously)
• Voting, by majority, by negative minority, or by ranking
• Decision by authority, whereby the scrum master calls on the group for ideas and advice before making the ultimate call

The only model I wouldn’t recommend is the last. That means assigning the scrum master ownership. Retros are about making team decisions, and the scrum master can be expected to facilitate but not to solve the group’s problems for them.

Otherwise, all bets are off! If you’re not sure which decision-making style works best for your team, try using the Vroom-Yetton Decision Model to decide.

Trick #12: Don’t force it

Ultimately, the key to take away from these tricks is to make the retrospective meeting your own. And that includes allowing others to make it their own.

You don’t want to force anyone to do any exercises they aren’t comfortable with or single anyone out for input. Yes, chances are, they have something to say—but maybe they’re not ready in that moment.

Keep using that feedback loop and meta-retrospective to understand everyone’s comfort levels. With that insight, you won’t have to force it. People will want to participate.

Just give it time. Investing a little extra attention to making your retrospective meetings as productive and effective as they can be will help the whole team get the most out of this critical learning opportunity.

These tricks should help get you started, but remember: they’re tools to adapt to your team.