How to Run a Weekly Team Retrospective

A retrospective is only as good as the honesty in the room. Retrium's guide to psychological safety quotes Harvard Business School professor Amy Edmondson's definition: psychological safety is "a belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns or mistakes." It also quotes Esther Derby, co-author of a well-known book on agile retrospectives: psychological safety does not mean feeling comfortable all the time, but feeling comfortable talking about what makes you uncomfortable.

Retrium makes a point that changes how you prepare. You cannot create psychological safety inside the retrospective. If you wait until the meeting, you have waited too long. Safety comes from how the leader behaves every day. Retrium lists three leader behaviors drawn from Edmondson's work:

1. Frame the work as a learning problem, not just an execution problem.
2. Acknowledge your own fallibility. "I might miss something, and I need you to tell me when I do."
3. Model curiosity by asking questions instead of always having the answer.

Within the meeting, three habits help:

• Read the Prime Directive. Retrium recommends opening with Norm Kerth's retrospective prime directive: "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."
• Say where the information goes. The Atlassian playbook suggests making clear whether what is said stays in the group or is shared with leadership, and mentions the Chatham House Rule as one option.
• Collect input privately first. Retrium recommends that people write their ideas privately before anything is shared, to prevent groupthink and anchoring on the first person who speaks. The Atlassian playbook also suggests anonymous submissions when people hold back.

A predictable agenda keeps a weekly retrospective short. This version fits in half an hour:

Asana's retrospective guide suggests gathering input asynchronously before the meeting, so quieter team members have time to contribute thoughtfully and the meeting can go straight to finding patterns. For a weekly cadence this is especially useful: a shared board open from Thursday lets people add notes when something happens, not only when they are asked.

Retrium's start, stop, continue guide recommends timeboxing both the whole meeting and each topic, for example five or ten minutes per theme. It also stresses that the facilitator should write down action items as they come up in discussion, so they are not lost by the end of the meeting.

Rotate the facilitator. A different person running the meeting each week spreads the skill, keeps the format fresh and stops the retrospective from becoming the manager's meeting.

A format gives people a frame for their notes. The same format every week becomes stale, so keep three or four and rotate them.

Mike Cohn of Mountain Goat Software favors start, stop and continue because it is fast, easy, non-threatening and action-oriented: every item leads directly to a change in behavior. The article adds a useful detail about the continue list: it holds practices the team wants to keep emphasizing until they become habits, and items come off the list once they have stuck. It also suggests varying how ideas are gathered, for example going around the room for one item each, or asking only for "stop" items in a given week.

Atlassian's list of retrospective techniques describes the alternatives. The 4Ls (liked, loathed, lacked or longed for, learned) works for personal reflection as well as team reflection. Mad, sad, glad focuses on how the work made people feel. The timeline exercise takes only a few minutes and refreshes everyone's memory of what happened. What, so what, now what keeps the conversation pointed at next steps.

The most common retrospective failure is a long list of good ideas that nobody does. Cohn's advice is to have the team vote and pick no more than three items, because choosing too many dilutes the importance of the ones selected. The same article notes that many good retrospective actions are behavioral and cost no time at all, such as starting meetings on time.

Atlassian's techniques article suggests dot voting: each person places three votes on the ideas they most want to address, then the team discusses why the top items matter and assigns owners and due dates. The Atlassian playbook adds that action items should go straight into the team's planning or task tool, not only onto sticky notes or a document, so they are part of the actual plan.

Good retrospective actions share the same shape as any good task:

• Specific. "Post the deploy checklist in the release channel before every release", not "be more careful with releases".
• Owned. One person is responsible for making it happen.
• Small enough for one week. A weekly retrospective should produce weekly-sized experiments.
• Checkable. At the next retrospective, anyone can say whether it happened.

Treat each action as an experiment. "For the next two weeks, we will try no-meeting Wednesday mornings and see whether focus time improves." Framing changes as experiments makes them easier to agree to and easier to drop if they do not work.

Follow-through is what separates a useful retrospective from a ritual. Start every retrospective by reviewing last week's actions: done, not done or no longer relevant. Cohn suggests bringing the full list of ideas from the previous retrospective, including those not chosen, because it often jump-starts the next discussion.

Watch for patterns across weeks. The Atlassian playbook recommends focusing on trends rather than one-time mistakes or successes that are unlikely to happen again. Atlassian's techniques article adds a warning: if the same issues are top-voted retrospective after retrospective, you may only be treating the symptom. That is the moment for a deeper look, such as the five whys, asking "why?" repeatedly until you reach the underlying cause.

A simple running log makes patterns visible:

WEEK OF:
FORMAT:            FACILITATOR:
LAST WEEK'S ACTIONS: done / not done / dropped, one line each
TOP THEMES:
ACTIONS (max 3): action, owner, due date, ticket link
REPEATING ISSUE?: yes / no, and how many weeks

Once a month, read the last four entries together. Repeating themes deserve their own focused session.

The same structure works for teams that include AI agents in their workflow. A weekly retrospective is a good place to ask which agent outputs needed rework and which instructions should change. Quanta Intelligence's team playbooks include retrospective templates in this format, but a shared document and a recurring 30-minute slot are all a team needs to start.