Running a 4Ls Retrospective for Remote and Hybrid Teams
A skill from the 4Ls Sprint Retrospective: Liked, Learned, Lacked, Longed For method.
Run a 4Ls retrospective for remote and hybrid teams with async input, a short video session, hidden voting and equal footing for everyone.
Run a 4Ls retrospective for remote and hybrid teams with async input, a short video session, hidden voting and equal footing for everyone.
Before you start
Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.
Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.
If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.
At a Glance
| Field | Value |
|---|---|
| Difficulty | Intermediate |
| Time to Learn | A few retrospectives of practice |
| Outcome | You can run a 4Ls retrospective for remote and hybrid teams where everyone contributes on equal terms, across time zones, and the team still leaves with owned actions. |
| Prerequisites | Experience facilitating a 4Ls retrospective in person, a digital board tool, a video call tool |
| Part of | 4Ls Sprint Retrospective |
Overview
The 4Ls format moves well to distributed teams. Its four categories map directly onto columns in a digital board, and its core step, silent individual writing, does not need anyone in the same room or even online at the same time. Ben Linders calls it a suitable exercise for remote or distributed retrospectives using a shared editable document. What changes is the facilitation: time zones, uneven connections, cameras and the gap between people in a room and people on a screen.
The main adaptation is to split the retrospective in two. The divergent part, writing notes under each L, happens asynchronously over a day or two, so everyone can contribute at a time that suits them. The convergent part, discussing themes and agreeing on actions, happens live when the notes call for it. GitLab's handbook takes a similar approach for its own groups: collect feedback asynchronously in an issue so people can think on their own time, and hold a video call only when necessary, for example after a difficult iteration or when emotions are likely to run high.
Hybrid teams, where some people share a room and others dial in, need the most care. The people in the room hear side conversations, read body language and reach the board first. Remote people get a camera view of a wall and a delayed audio feed. The fix is to run a hybrid retrospective as if everyone were remote. The method page covers the categories and the standard session; this skill covers what to change when the team is distributed.
How It Works
A remote 4Ls retrospective has three parts: an async writing window, a pre-processing pass by the facilitator, and a live session.
The async window replaces silent writing. The facilitator opens a board with the four columns and prompts, shares the sprint facts, and gives the team a window, often a working day or two, to add notes. Writing alone at their own pace gives people more time to think than a timer in a meeting, and it removes the pressure of typing while others watch. Anonymous notes are easier to offer in a tool than in a room, and they help when trust is uncertain.
The pre-processing pass saves live time. Before the call, the facilitator reads all notes, groups obvious duplicates and drafts theme names, leaving everything editable. The live session then starts from a mostly clustered board and spends its time on judgment calls, not on reading notes aloud.
The live session covers the phases that need conversation: confirming clusters, voting, discussing the top themes and agreeing on actions. It follows the later phases of Derby and Larsen's structure, generate insights, decide what to do and close, and it can be shorter than an in-person retrospective because the data is already on the board. Voting works best in the tool with results hidden until everyone is done, which the Nielsen Norman Group points out removes the pull of seeing where others' votes went.
Time zones shape the live session. If there is no hour that works for everyone, GitLab suggests scheduling the meeting twice, once for each group of time zones. Some GitLab groups also choose not to record the meeting so people feel free to speak, and some leave out direct managers for the same reason. Each of these is a trade-off the team should agree on openly.
Hybrid sessions add one rule: everyone joins from their own device, including people in the room. That puts every face in the same size box, every voice on the same microphone, and every note on the same board.
Step-by-Step Guide
Step 1: Set Up the Board and the Tools
Choose one digital board tool the whole team can use and create the four columns with prompts under each. Turn on anonymous notes if the team wants them, and check that hidden voting is available. Add a header with the sprint goal, what shipped, incidents and last retrospective's actions with their status. Test the board link with someone outside the facilitator's own setup. Book the live session and share both links in one message.
Step 2: Open the Async Writing Window
Send a short message explaining the purpose, the four categories, the deadline for notes and roughly how long writing should take. Give a window long enough to cover everyone's working hours, often a day or two before the live session. Ask for one idea per note and for specific events rather than general moods. Remind people once, midway through the window, without singling anyone out. Close the window before you start pre-processing, so nobody adds notes to a board you are reorganizing.
Step 3: Pre-Process the Board
Read every note. Group clear duplicates, draft a short name for each cluster, and leave everything editable. Flag notes that seem to be in the wrong column, but do not move them; ask during the live session. Note any theme that looks sensitive so you can plan how to open it. Share the pre-processed board with the team before the call so people arrive already oriented.
Step 4: Run the Live Session
Open with purpose, scope and a quick check-in in which everyone speaks, cameras on if the team is comfortable. Review last retrospective's actions. Walk through the clusters, asking the team to confirm or fix the grouping and names. Run a silent vote in the tool with results hidden until everyone has voted, then discuss the top themes in order. Watch the participant list and invite quieter people by name, since remote silence is easy to miss.
Step 5: Close the Hybrid Gap
If some people share a room, ask each of them to join from their own laptop with their own headset. Keep the board on everyone's screen, not on a wall display. Ask in-room people to keep side conversations out of the session, and repeat any comment the remote people might have missed. Rotate who speaks first so the room does not always set the frame. If the imbalance persists, run the next retrospective fully remote.
Step 6: Record and Follow Through
Agree on actions with one owner and a date each, and add them to the sprint backlog during the call. Post a written summary within the day in the team's usual channel: themes, votes, actions and owners. GitLab's handbook asks for actions assigned with clear expectations for completion, which the summary should show. Keep the board archived with the same naming scheme each sprint. Start the next async window by linking to the previous actions.
Best Practices
- Split writing from discussion. Async writing gives everyone time to think and removes time-zone pressure; the live session keeps the parts that need conversation.
- Treat hybrid as remote. Everyone on their own device, on the same board and the same audio, removes most of the advantage in-room people have.
- Hide votes until everyone has voted. Digital tools make this easy, and it keeps early votes from steering the rest.
- Pre-process the board before the call. A mostly clustered board lets the live session spend its time on decisions instead of reading notes.
- Agree as a team on recording and attendance. Whether the call is recorded and whether managers attend both affect how freely people speak, so decide openly.
- Keep the live session short and focused. Long video calls wear people down, so move the reading work into the async window.
Common Mistakes
- Copying the in-person agenda onto a video call: Running silent writing, clustering, voting and discussion live makes the call long and tiring. Move writing and first-pass clustering into the async window.
- A camera pointed at a whiteboard: Remote people cannot read or move notes on a wall. Use a digital board for everyone.
- One time slot that suits only part of the team: The same people end up joining late at night every sprint. Rotate the time or run the session twice.
- Leaving the async window open during pre-processing: New notes arrive on a board you are reorganizing and get lost. Close the window first, then cluster.
- Letting remote silence go unnoticed: A quiet participant on video is easy to overlook. Watch the participant list and invite people by name.
References
- Examples: Worked examples and scenarios
- FAQ: Frequently asked questions
- Parent Method: 4Ls Sprint Retrospective
Related Skills
- Building a 4Ls Retrospective Board and Template
- Facilitating a 4Ls Sprint Retrospective Meeting
- Tracking 4Ls Retrospective Trends Across Sprints
- Sorting Team Feedback into the 4Ls Categories
- Writing 4Ls Retrospective Questions for Each Category
- Turning 4Ls Retrospective Insights into Action Items
Sources
- Ben Linders: Four L's, a classic retrospective exercise
- GitLab Handbook: Group retrospectives
- Derby, Larsen and Horowitz: Agile Retrospectives, Second Edition
- Nielsen Norman Group: Dot voting
Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.
Other Skills in This Method
Building a 4Ls Retrospective Board and Template
Build a reusable 4Ls retrospective board and template, physical or digital, with prompts, voting space and an action area the team reuses.
Sorting Team Feedback into the 4Ls Categories
Sort team feedback into the 4Ls categories, tell Liked, Learned, Lacked and Longed For apart, and resolve notes that fit more than one.
Turning 4Ls Retrospective Insights into Action Items
Turn 4Ls retrospective insights into a few concrete action items with one owner and a due date each, carried into the next sprint.
Writing 4Ls Retrospective Questions for Each Category
Write 4Ls retrospective questions for Liked, Learned, Lacked and Longed For that draw specific, usable feedback out of every team member.
Facilitating a 4Ls Sprint Retrospective Meeting
Plan, timebox and facilitate a 4Ls sprint retrospective meeting so every person contributes and the team leaves with owned action items.
Tracking 4Ls Retrospective Trends Across Sprints
Track 4Ls retrospective trends across sprints: log and tag themes and actions so recurring, systemic problems become visible and get fixed.
Related Methods and Skills
Decide What to Do in a Retrospective: Prioritize Actions
Decide what to do in a retrospective: prioritize improvements with voting and a control check, then commit to one or two owned actions for the next sprint.
Tracking Retrospective Action Items Across Sprints
Tracking retrospective action items: keep improvements visible, give them capacity, review them every retro and watch whether problems stop recurring.
Running Sprint Retrospectives for Continuous Improvement
Retrospective facilitation for agile teams: set the stage, gather data, find causes, and leave with a few owned changes the team follows up.
Building a Reusable Sprint Retrospective Template
Build a reusable retrospective template that maps activities, timings and facilitator cues to the five phases, so anyone can run a solid sprint retro.
Facilitating a Start Stop Continue Retrospective
How to run a start stop continue retrospective: prepare, review the facts, write in silence, group and vote, then leave with a few owned actions.
Choosing Retrospective Activities and Exercises
Choosing retrospective activities: pick one exercise per phase to suit the sprint, the team and the time, so each retro surfaces something new.
Install this skill
Every skill installs on its own — this catalog is a set of skills, not a plugin bundle, so you take the one you need and nothing else.
Claude Code
.claude/skills/adapting-4ls-for-remote-and-hybrid-teamsnpx skills add gethamster/skills --skill adapting-4ls-for-remote-and-hybrid-teams --agent claude-code --yesCursor
.agents/skills/adapting-4ls-for-remote-and-hybrid-teamsnpx skills add gethamster/skills --skill adapting-4ls-for-remote-and-hybrid-teams --agent cursor --yesCodex
.agents/skills/adapting-4ls-for-remote-and-hybrid-teamsnpx skills add gethamster/skills --skill adapting-4ls-for-remote-and-hybrid-teams --agent codex --yesAntigravity
.agents/skills/adapting-4ls-for-remote-and-hybrid-teamsnpx skills add gethamster/skills --skill adapting-4ls-for-remote-and-hybrid-teams --agent antigravity --yesOr browse the skills and pick interactively:
npx skills add gethamster/skillsSource: gethamster/skills on GitHub, MIT licensed.