Who Pays for Your Retrospective Improvement?

A retrospective action can make work easier for some people by moving the burden to someone else. Ask what the improvement replaces, then follow its real cost.

6 October 2026 · The Tellenze team

A teal chute carries blocks from an ivory workbench into the most heavily loaded of four wheeled trays, as a hand steadies the tray.

Picture an illustrative product team at its next retrospective. Most people say the interruptions have eased. They can finally finish a thought without another support question landing in their messages.

The team had tried a simple change: one engineer would be the support contact each day. Questions would go to that person first.

The experiment sounds successful until the engineer who covered yesterday asks which feature commitment was supposed to move. The support work took most of the afternoon. Their delivery plan still assumed an ordinary day of development.

The interruption problem has become easier to live with for several people. Its cost has become harder to see.

A retrospective improvement needs to answer two questions together: what should get better, and who will make room for the work that gets us there?

The effort hiding inside a useful idea

There is nothing inherently wrong with a support rotation. Concentrating interruptions can protect focus, improve coordination and give customers a clearer route to help. Sharing that duty can also spread useful product knowledge.

But “take turns” leaves several decisions unanswered.

Does the person on duty still carry a full feature workload? Who helps with a question beyond their expertise? What happens to a request that arrives just before the handoff? Is a quiet day available for development, or does the role require constant availability?

These are part of the improvement itself.

The 2020 Scrum Guide asks teams to identify helpful changes and address impactful improvements promptly. That makes acting on a retrospective important. It also leaves teams to work out the practical consequences of their chosen change.

A clear owner and a completed action are a useful beginning. They do not tell us whether the team has paid for the new arrangement honestly.

Name what the improvement replaces

Before trying the rotation, our imaginary team can make a small capacity decision.

On a support day, the engineer's main responsibility is support. The team reduces that person's planned feature work, names a backup for specialist questions and agrees how unfinished requests pass to the next contact. It also tells the people waiting for features what has changed.

That may make the delivery plan look less ambitious. It makes the existing support demand visible.

If the team cannot make that trade-off, it has learned something before the trial begins: the proposal depends on someone absorbing work beyond the plan. A rotation alone will not create the missing capacity.

DORA's guidance on organizational change connects experimentation with the autonomy, resources, capacity and management support needed to do improvement work. The practical implication here is my own: an improvement deserves a place in the plan, including the work it displaces.

For a different retrospective action, that displacement might be preparation for a new meeting, maintaining a checklist or writing a release note. Ask the people who will do it how it fits into their day. “Only ten minutes” is a hypothesis until someone has tried the whole task.

Follow the work to its new home

Now the team has something concrete to try: route ordinary support questions through the daily contact for a short agreed period, with adjusted commitments and an explicit handoff.

The implementation can have a verifiable end: the rota is agreed, the route is communicated, the backup is clear and the handoff has been tried. Keep that delivery evidence with the action.

Google's account of postmortem practice makes a useful case for specific actions, ownership, tracking and verifiable end states. It comes from incident management rather than ordinary team retrospectives, but the follow-through lesson travels well.

The next conversation concerns how the arrangement behaves in use.

Fewer direct messages to most engineers might show that routing changed. It does not establish that support became easier or that customers received better answers. Questions may now wait in one queue. The daily contact may still interrupt colleagues to find an answer. Handoffs may add work that nobody counted.

Follow a few requests from arrival to resolution. Where did they wait? Who became involved? What happened to planned work while the request was being handled?

This need not become minute-by-minute timekeeping. A short record of meaningful exceptions, existing request timestamps and a conversation with each person who tried the role can reveal where the load moved.

Listen for the cost the dashboard misses

The original SPACE article on developer productivity, by Nicole Forsgren and colleagues, argues for several dimensions of productivity and attention to work that simple activity measures miss. It also describes tensions between individual flow and collaboration.

That is a useful caution for our example. A team can protect most people's focus while leaving the support contact unable to make progress on other commitments.

Ask people who covered the role separately before interpreting a team average. Could they finish within their normal working day? Were the revised commitments realistic? Did the backup arrangement actually help?

Use those answers to improve the arrangement. Preserve people's privacy and avoid turning the trial into a ranking of who answers the most questions. Different days and requests are not interchangeable.

A fair distribution is not necessarily an equal distribution. Some questions need specialist knowledge; some days bring incidents. The important decision is whether the team understands those differences and makes room for them, rather than letting the same person quietly compensate.

Bring back a decision, including what will stop

At the agreed check-in, the team should be able to choose its next move.

If the rotation helps customers and protects focus at an acceptable cost, keep it and document the capacity assumption. If the handoff creates delays, change it. If the role depends on working late, reduce the demand, change commitments or stop the arrangement while considering another response.

The evidence may be inconclusive. Perhaps too few requests arrived, or a release made the period unusual. Extend the trial only with a clear question and another check-in. Do not let uncertainty turn a temporary arrangement into a permanent obligation.

In Tellenze, the retrospective guide describes reviewing an action's scope, criteria, destination and assignees before creating linked follow-up work. Put the capacity decision and later check with that work. Share approved action content; private workshop reflections can stay in the workshop.

This gives the Loop something useful to carry forward: where the change helped, what it cost and what the team decided next.

Before your next retrospective action becomes a commitment, add one sentence:

To make room for this improvement, we will change or stop ______.

Then ask the person who will carry the work whether that sentence is true.

Bring their answer back when you inspect the result. The improvement should make sense for the people doing it as well as the people relieved by it.