8 tips for better agile retrospective meetings

Here's how to get more positive results from your retro meetings, and build a stronger team while you're at it.
320 readers like this.
Worth it?


I’ve often thought that retrospectives should be called prospectives, as that term concerns the future rather than focusing on the past. The retro itself is truly future-looking: It’s the space where we can ask the question, “With what we know now, what’s the next experiment we need to try for improving our lives, and the lives of our customers?”

What’s a retro supposed to look like?

There are two significant loops in product development: One produces the desired potentially shippable nugget. The other is where we examine how we’re working—not only to avoid doing what didn’t work so well, but also to determine how we can amplify the stuff we do well—and devise an experiment to pull into the next production loop to improve how our team is delighting our customers. This is the loop on the right side of this diagram:

Retrospective 1

When retros implode

While attending various teams' iteration retrospective meetings, I saw a common thread of malcontent associated with a relentless focus on continuous improvement.

One of the engineers put it bluntly: “[Our] continuous improvement feels like we are constantly failing.”

The teams talked about what worked, restated the stuff that didn’t work (perhaps already feeling like they were constantly failing), nodded to one another, and gave long sighs. Then one of the engineers (already late for another meeting) finally summed up the meeting: “Ok, let’s try not to submit all of the code on the last day of the sprint.” There was no opportunity to amplify the good, as the good was not discussed.

In effect, here’s what the retrospective felt like:

Retrospective 2

The anti-pattern is where retrospectives become dreaded sessions where we look back at the last iteration, make two columns—what worked and what didn’t work—and quickly come to some solution for the next iteration. There is no scientific method involved. There is no data gathering and research, no hypothesis, and very little deep thought. The result? You don’t get an experiment or a potential improvement to pull into the next iteration.

8 tips for better retrospectives

  1. Amplify the good! Instead of focusing on what didn’t work well, why not begin the retro by having everyone mention one positive item first?
  2. Don’t jump to a solution. Thinking about a problem deeply instead of trying to solve it right away might be a better option.
  3. If the retrospective doesn’t make you feel excited about an experiment, maybe you shouldn’t try it in the next iteration.
  4. If you’re not analyzing how to improve, (5 Whys, force-field analysis, impact mapping, or fish-boning), you might be jumping to solutions too quickly.
  5. Vary your methods. If every time you do a retrospective you ask, “What worked, what didn’t work?” and then vote on the top item from either column, your team will quickly get bored. Retromat is a great free retrospective tool to help vary your methods.
  6. End each retrospective by asking for feedback on the retro itself. This might seem a bit meta, but it works: Continually improving the retrospective is recursively improving as a team.
  7. Remove the impediments. Ask how you are enabling the team's search for improvement, and be prepared to act on any feedback.
  8. There are no "iteration police." Take breaks as needed. Deriving hypotheses from analysis and coming up with experiments involves creativity, and it can be taxing. Every once in a while, go out as a team and enjoy a nice retrospective lunch.

This article was inspired by Retrospective anti-pattern: continuous improvement should not feel like constantly failing, posted at Podojo.com.

[See our related story, How to build a business case for DevOps transformation.]

User profile image.
Catherine Louis is a Certified Scrum TrainerTM, independent Agile coach, founder of CLL-Group.com, PoDojo.com, and founding member of Tech Ladies®. When she's not helping companies with their business agility efforts, she's busy with Search and Rescue - focused on training dogs and their handlers how to find and rescue missing people.


As an outsider, this Agile movement has all the trappings of a religion, and probably a temporary one. I see the creation of a lot of rites and rituals, with artificial lingo to go along. I guess the idea is to distribute responsibility and problem-solving, but there are many ways to do that. Perhaps without the religious experience aspect, it's hard to get top level buy-in.

It can certainly become one of those things, which ironically is the antithesis of what Agile should be. The answer to "Why are we doing this ritual?" should not be "Because the Agile Book told us to." The answer should be about how well it works and why it works. One of the big positives of Agile, if done right, to me is that it finally empowers the development team in decision making processes. Another positive if it is done right is that it reinforces solid principles. Of course the whole thing can, and often does, go off the rails very quickly if it becomes a religious following or is turned into a micromanagement tool but that doesn't have to be the foregone conclusion.

In reply to by Greg P

I really liked this article. I think these are all very good ideas. I especially like the idea of treating this as a more scientific process and to add some emphasis on the positives. Otherwise the whole thing can feel like the bi-weekly bitchfest which is a negative energy thing.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.

Download the Open Organization Guide to IT Culture Change

Open principles and practices for delivering unparalleled business value.