Retro

Run a retrospective that produces action items, not just observations. A retro without specific next steps is a venting session.

Principles — hold these throughout:

• Blame-free. Focus on systems, processes, and circumstances — not people. "The deploy process let a bug through" not "Bob broke prod."
• Actions over observations. Every theme must produce a concrete change. If it doesn't lead to action, note it and move on.
• Max 3 action items. More than three won't get done. Prioritize ruthlessly.

Step 1: Set Context

Establish the boundaries before gathering input:

Write a 2-3 sentence summary: "We set out to [goal]. We [what happened]. The result was [outcome]."

If the user hasn't provided this context, ask for it. Don't fabricate project history.

Step 2: Gather Input — The 4Ls

Use the 4Ls framework to collect observations. Ask the user to contribute to each category:

Gathering tips:

• Ask for specifics, not generalities. "Liked: good communication" is useless. "Liked: daily 10-min standups kept everyone unblocked" is actionable.
• Aim for 3-5 items per category.
• If working async, give people a template to fill in before the session.

Step 3: Identify Themes

Group related items across the 4Ls. Look for patterns:

1. Cluster related items. If three people mention deployment issues, that's a theme.
2. Name each theme clearly. "Deployment reliability" not "various issues."
3. Find root causes. For the biggest themes, use the 5 Whys:

Problem: Feature launched 2 weeks late.
Why? → Integration testing took longer than expected.
Why? → We discovered API incompatibilities late.
Why? → No integration test environment existed.
Why? → We hadn't invested in test infrastructure for this service.
Why? → Test infra wasn't prioritized because the team was focused on feature work.

Root cause: No dedicated time for test infrastructure investment.

Stop when you reach something the team can actually change. Don't go deeper than useful.

4. Rank themes by impact. Which ones, if fixed, would make the biggest difference next time?

Step 4: Generate Action Items

For each of the top 2-3 themes, create one action item. Every action must be:

ACTION ITEM TEMPLATE:

Theme: [theme name]
Action: [specific thing to do]
Owner: [person or role]
Due: [date or sprint]
Success looks like: [how we know it's done]

Hard limit: 3 action items. If you have 5 good ones, pick the 3 with highest impact. Carry the rest to next retro if they're still relevant.

Step 5: Write the Retro Summary

Produce a single document the team can reference:

# Retro: [Project/Sprint Name]

**Period:** [start] — [end]
**Team:** [names/roles]
**Goal:** [what we set out to do]
**Outcome:** [what actually happened]

## Summary
[2-3 sentences: goal, what happened, result]

## 4Ls

### Liked
- [item]
- [item]

### Learned
- [item]
- [item]

### Lacked
- [item]
- [item]

### Longed For
- [item]
- [item]

## Themes
1. **[Theme name]** — [1-sentence description]. Root cause: [root cause].
2. **[Theme name]** — [1-sentence description]. Root cause: [root cause].
3. **[Theme name]** — [1-sentence description]. Root cause: [root cause].

## Action Items

| # | Action | Owner | Due | Done? |
|---|--------|-------|-----|-------|
| 1 | [specific action] | [owner] | [date] | [ ] |
| 2 | [specific action] | [owner] | [date] | [ ] |
| 3 | [specific action] | [owner] | [date] | [ ] |

## Notes
[Anything else worth recording that doesn't fit above]

Output

Deliver the retro summary using the template above. Customize it to the actual project — don't leave placeholder text. If information is missing, flag what you need from the user rather than filling in generic content.