I believe in self-improving systems, and retrospectives are a core way of reflecting and then changing behavior accordingly. There’s a lot out there on what a retrospective is, formats to use, and other techniques, so I’ll just highlight my facilitation thoughts on them here. This is influenced by the CAST handbook and my own facilitation background.
Must be blame-free / a psychologically safe space
People will not open up and be actually present and interrogative if they don’t feel safe. It is your responsibility when setting up, facilitating, and debriefing to make sure the system is what is being critiqued, not the humans within it. The humans made the best possible choice they could given the circumstances they were in, so let’s change the circumstances in the future. Make this explicit early and often. As Charity says on the sticker on my megaphone, “communicate positive intent.”

Must be scoped well
If people don’t know what they’re talking about, they won’t talk about the same thing, and getting to concrete outcomes will become nearly impossible. Focus on a specific project, timeline, or outcome. Communicate this early and often.
Should encourage creative thinking
Whatever format you pick should be mildly novel (not so novel that it disrupts how people approach things, but novel enough to edge them out of their comfort zone). Use a different prompt set or a different tool, but rarely both at the same time. Ask more of people to engage and challenge them into someplace new.
Needs to lead to concrete, actionable tweaks
If you don’t arrive at experiments that will change how you’re behaving, you have wasted everyone’s time. I like to set aside about 1/4 of the time of the retro to listing, refining, and then selecting one or two these experiments. I ask the following questions:
- What will change if we take this action?
- What would prevent us from making the change?
- How will we know if we’re successful or not?
- When should we check back?
- What is our next step, and who is responsible for it?
I only pick up 1-3 concrete steps to take after each retro. I track them just like any project, and I report back on them before the next retro to show that the time and vulnerability is worth it.
One goal should be building trust with the team
A core part of the system is team trust, and in improving the system, we should be focused on building that part of it. By being blame free, enacting suggestions, and pushing people to engage more, we build that trust. If something about the retro process is eroding trust, pause and reassess your approach.






