Back to blog
Async and Meetings

Running Retros Async Across Time Zones

5 min read
async retrospectiveretro across time zonesdistributed team retroasync retro formatremote retrospective

The short version

  • Split the retro in two: gathering is async and works better that way; deciding is live and short.
  • Async gathering removes the biggest flaw of the live retro, which is that the loudest and most senior voices set the agenda.
  • Two days to contribute, one 30-minute slot to decide, and one owner per action. Anything more elaborate will not survive three sprints.
  • Retros fail on follow-through far more often than on format. Publish the actions where the team will see them daily.

A retro across three time zones has no good hour. Whichever slot you pick, someone joins before breakfast or after dinner, and the people at the edges contribute least, which quietly weights every conclusion toward the zone in the middle.

"Retro is at 7am for Warsaw or 7pm for Denver. Nobody comes."

The 7am retro problem

Attendance is the visible symptom and it is not the real cost. The real cost is that the person joining at 07:00 contributes the least, and the retro concludes that things are broadly fine, which is the conclusion of a meeting held at a convenient time for the people who found it convenient.

Rotating the slot spreads that distortion rather than removing it, as covered in rotating meetings treats the symptom. The better move is to change what has to happen live.

Split gathering from deciding

A retro does two different things, and only one of them needs everyone present at once.

Gathering is collecting what happened and how people experienced it. It benefits from time, reflection, and the absence of social pressure, which means async is not a compromise here, it is an improvement.

Deciding is choosing which two or three things to change and who owns each. This benefits from live discussion, because trade-offs get argued and commitments get made in front of witnesses. It needs thirty minutes, not ninety, and it needs the people who will own the actions rather than everyone.

The format, end to end

When What happens Live?
Days 1 to 2 Everyone adds items in writing, three prompts, in their own hours No
Day 3 morning Facilitator groups items and posts the three biggest themes No
Day 3, 30 minutes Decide two or three changes, name an owner for each Yes
Day 3, after Actions posted where the team sees them daily No

Three prompts, not five: what slowed us down, what worked that we should keep, and what we should change. Written contributions, visible to everyone from the start, since hiding them until the meeting adds ceremony without adding honesty.

What async actually improves

Two things get measurably better, and it is worth saying them out loud so the team does not experience the change as a downgrade.

The first is who contributes. In a live retro the first three speakers set the frame, and anyone whose observation does not fit that frame tends to drop it. In writing, everyone's item is recorded at equal weight and the quiet person's observation survives.

The second is specificity. People write more precisely than they speak, especially about things that went wrong. "The handoff on the payments work was thin on Tuesday and I lost the morning" is the kind of sentence people write and do not say, because saying it aloud sounds like blame.

One more benefit that accrues over time: if people are already confirming a ninety-second brief at the end of each day, the raw material for the retro already exists. Nobody has to reconstruct the sprint from memory, which is where the vaguest retro items come from.

Follow-through is the real failure

Retros do not usually fail at the retro. They fail in the two weeks afterwards, when the actions sit in a document nobody opens and the same item reappears next sprint, which is the point at which people stop bothering to contribute.

Two rules fix most of it. A maximum of three actions, each with one named owner and a date, because a retro that produces nine actions produces none. And the actions go somewhere the team already looks daily, not into the retro document. Start the next retro by reading last time's three actions aloud and saying done or not done. Nothing improves follow-through like that thirty seconds of mild public accountability, and if you want the async version, each owner can simply carry the action in their brief until it is closed.

Common Questions

Can you run a retrospective fully async?

You can, and the deciding half suffers. Gathering async is better than live; deciding async tends to produce vague actions with weak ownership, because nobody commits in writing the way they commit in front of the team. Thirty minutes live is worth protecting.

How long should the async gathering window be?

Two working days, which gives everyone a full day in their own zone plus overlap for reading what others wrote. Longer and the early contributions go stale; shorter and one zone gets a single evening to contribute.

Who should facilitate?

Rotate it, and keep the facilitator out of the grouping step if they were heavily involved in the sprint's problems. Grouping is where a retro gets quietly steered, so it benefits from someone with less at stake.

What if people do not contribute in writing?

Usually the prompts are too broad or the previous retro produced nothing. Narrow the prompts to the sprint just finished, and demonstrate that last time's three actions actually happened. Participation follows evidence that contributing changes something.

When you're off, your StandIn is on.

It answers your teammates' questions from work you've already done, in your words, with a source under every answer.

You might also like