How to run a retrospective and why AI changes it

A retrospective should be a useful meeting in a team’s calendar: a protected chance to examine how the work happened and agree what to change. Yet plenty become a familiar tour of the same observations. Communication could be better, requirements arrived late, and somebody should do something about the build.

The problem is rarely the lack of a clever board template. A good retrospective needs enough safety for honesty, enough structure to prevent drift, and enough discipline to finish with a small number of owned actions. Here is a straightforward way to run one in 40 minutes.

Before the retrospective

Choose a useful boundary: a sprint, release, incident or difficult fortnight. Tell people what period you are reviewing and what the session should produce. “Review Sprint 24 and choose one improvement to test next sprint” is much more useful than “have a chat about how things are going”.

Invite the people who experienced the work. Six to eight participants is comfortable; larger groups need more silent input and stricter timeboxing. Gather useful facts beforehand, but do not turn the retro into a performance report. The team’s experience is evidence too.

1. Open with the purpose and the rules

Spend two or three minutes establishing the tone. The aim is to improve the system of work, not identify a culprit. Ask for specific examples, encourage curiosity, and allow disagreement without turning it into a trial. Managers should contribute without answering every point first.

We are looking for patterns we can learn from, not people to blame. Be specific, assume good intent, and help us leave with one change worth trying.

2. Collect observations silently

Give everyone a few quiet minutes to think before discussion begins. Silent input reduces anchoring and gives people who process internally a fair chance to shape the conversation. A simple Mad, Sad, Glad prompt works well: what frustrated you, what disappointed you, and what gave you energy or confidence?

• Ask for events and effects, not vague verdicts.
• Write one observation per note or contribution.
• Include positive patterns worth protecting, not only problems.
• Let people contribute privately before names become visible, where possible.

“Deployments were bad” is difficult to use. “Three deployments needed manual database fixes, which delayed testing by half a day” gives the team somewhere to begin. The facilitator should ask for clarification without cross-examining the contributor.

3. Find the themes, then choose

Read the contributions, group obvious connections and check that the group agrees with the themes. Do not spend half the meeting perfecting the taxonomy. The point is to reveal where several experiences describe the same underlying condition.

Next, vote on which theme would be most valuable to improve in the next cycle. Blind voting is useful because it prevents the first confident opinion from becoming the room’s opinion. State the criterion before voting and carry only the top one or two themes into action planning. A retrospective that tries to repair everything usually repairs nothing.

4. Turn discussion into an experiment

Discuss the selected theme long enough to understand it, then ask what the team can change within its influence. Prefer a small experiment over an impressive declaration. “Improve communication” is not an action. “Add a ten-minute API review before refinement for the next two sprints” is testable.

For every action, record three things: who owns the follow-through, what they will do, and when the team will inspect the result. Ownership does not mean doing all the work; it means making sure the action does not quietly evaporate after the call.

1. Who will move this forward?
2. What exactly will happen?
3. When will it happen or be reviewed?
4. What evidence would tell us it helped?

5. Close the loop next time

Begin the next retrospective by reviewing the previous action. Did it happen? Did it help? Should it continue, change or stop? This small habit tells the team that retrospective commitments are real. Without it, each session starts from scratch and cynicism is entirely rational.

Why AI changes the retrospective

A retrospective needs somebody to run it. Traditionally, that means hiring an experienced facilitator or assigning the job to whichever team member is organised enough to accept it. A template reduces preparation, but somebody must still explain the activities, watch the clock, run the vote and capture the actions.

Good facilitation should not be a special occasion

External facilitators are valuable, particularly when the stakes are high or the room is difficult. Few teams can afford one for every sprint retrospective, release review or prioritisation session. Ordinary team work therefore gets a board rather than active facilitation, or no structured conversation at all.

An AI facilitator makes a sound process economical enough to use every week. Clarvelo introduces each activity, gathers contributions, keeps voting private and carries selected themes into action planning. The team gets active facilitation rather than instructions on a canvas and the optimistic assumption that the meeting will run itself.

The organiser should get to participate too

Running the retro internally looks free because the cost lands on one diligent person. They spend the meeting changing hats: contributor, neutral chair, timekeeper and note-taker. While everyone else considers the work, they are thinking about what happens next.

The person who cared enough to organise the retrospective should not be punished by having to sit partly outside it. When Clarvelo facilitates, the manager, delivery lead or conscientious developer who booked the session can contribute on the same terms as everybody else. Nobody sacrifices their seat to operate the workshop.

A template lays out the workshop. An AI facilitator runs it

That distinction matters between activities. Observations remain connected to the themes the group reviews. The voting criterion is stated before anyone votes. Winning themes reach action planning with their context intact, and missing ownership is visible before the session closes. The process survives the journey from experience to priority to action.

The team still owns the substance. Clarvelo should not diagnose colleagues, manufacture agreement or invent certainty. Serious conflict, lost trust or a consequential organisational decision may require an experienced human specialist who can intervene with judgement. Most weekly retrospectives are not that meeting. They still deserve a good process, and every team member deserves to take part.

A 40-minute retrospective agenda

• 3 minutes: purpose, scope and working agreement
• 17 minutes: silent Mad, Sad, Glad input and clarification
• 5 minutes: group themes and blind vote
• 12 minutes: discuss the priority and write owned actions
• 3 minutes: read back commitments and close

The timings are not sacred. Protect the final action-planning section, even if that means discussing fewer themes. A shorter conversation with a clear consequence is more valuable than a comprehensive conversation that ends when the calendar notification appears.

Run the process without running the machinery

Clarvelo’s Rapid Retro guides a team through Mad, Sad, Glad, a blind vote, and Who, What, When in one focused session. Guests join from a link without creating accounts, while the AI facilitator keeps the structure moving and turns the selected themes into explicit follow-up actions.

Ready to run one with your team? Start a free Rapid Retro. Bring the people and the recent work; Clarvelo will handle the workshop mechanics.