Three teams building one product are on different cadences and each waits on the others. Would you align their sprints?

Short answer

Aligning cadences makes the waiting comparable and gives you one integration point, which is worth having.It does not shorten the queue - it only tidies the moment work joins one.

Scaling shows up here as cross-team dependencies, not as a framework diagram. Good scaling makes cross-team dependencies visible early, decides which dependency must be removed, and gives teams a cadence for integration that matches the risk. Weak scaling adds coordination meetings while cross-team dependencies keep arriving late. Strong scaling asks whether the dependency should exist at all, then uses planning, contracts, integration tests, or ownership changes to reduce it.

Take the wait apart before you touch the calendar

The question hides an assumption worth refusing: that the teams wait on each other because their calendars disagree. Calendars contribute, and they are almost never the dominant term. Before recommending anything, decompose one real dependency into the three intervals it actually contains — the time between asking and the other team starting, the time they spend doing it, and the time between them finishing and you being able to use it.

That decomposition is arithmetic you can do in front of the sponsor, and it usually settles the argument.

ONE DEPENDENCY, MEASURED. Checkout needs a new field on the Identity API.

Checkout    two-week sprints, planning on alternate Mondays
Identity    three-week sprints, planning every third Wednesday
Data        continuous flow, WIP limit of four, no planning event

Asked on 4 June. Usable on 22 July. Seven weeks.

  interval                                    elapsed   set by
  ------------------------------------------  --------  ---------------------
  ask sits in Identity's inbox until their     11 days  their cadence, and
  next planning                                         where in it we asked

  not selected in that planning - ranked        21 days  their priority order.
  below two of their own goals                           Nothing to do with
                                                         cadence

  selected, built, reviewed                      6 days  actual work

  released behind Identity's own flag, which     9 days  their release policy
  they enable at their next deploy window

  Checkout picks it up at its own next            2 days  our cadence
  planning

  cadence contributes           13 of 49 days   27%
  their priority order          21 of 49 days   43%
  actual work                    6 of 49 days   12%
  release policy                 9 of 49 days   18%

Aligning every team to a two-week cadence, and nothing else, moves the first and last rows. On these numbers that is a saving of roughly a week out of seven — real, worth having, and not the answer to the question the sponsor asked. The largest single interval is the twenty-one days in which the request existed, was visible, was tracked, and lost a priority argument inside another team. No amount of synchronisation addresses a priority argument.

Why a synchronisation ceremony moves the queue rather than shortening it

The instinctive next move is a weekly cross-team sync, a scrum-of-scrums, or a dependency board reviewed by a coordinator. Each of these does one thing well: it reduces the time between a dependency becoming a problem and somebody knowing about it. That is genuinely valuable, because a surprise in week ten costs more than a known constraint in week two.

What it does not do is change the service rate. If Identity can absorb two external requests per sprint and four arrive, the fifth request waits regardless of how many people watch it wait. The meeting relocates the queue from Identity's inbox to a shared board, where it is now legible and still the same length. The failure that follows is specific and common: because the board is well run, the pressure that would have forced a structural change dissipates. Everyone can see the dependency, everyone agrees it is being managed, and it costs exactly what it cost before.

There is a second-order cost too. A coordination forum consumes the attention of the people who could have removed the dependency instead, and it grows superlinearly. Three teams have three pairs to coordinate; six teams have fifteen. That arithmetic is why scaling frameworks exist — they are mechanisms for absorbing coordination cost — and also why needing less of the framework each year is the only sensible goal to hold for one.

Rank the interventions by whether the wait survives them

The useful discipline is to sort every candidate move into one of two columns: does this remove the need for another team to act, or does it only make their action more predictable?

Intervention	What it changes	Wait after it
Align cadences to the shortest	Pickup and handback delay only	Down by the cadence terms, priority term untouched
Weekly cross-team sync	Time-to-know, not time-to-get	Unchanged
Dependency register with owners and dates	Predictability, and an escalation path	Unchanged, but no longer a surprise
Contribution rights: Checkout writes it, Identity reviews	Converts a planning queue into a review queue	Days rather than weeks
A versioned contract plus consumer-driven tests	Removes the coordination for compatible changes	Zero for most changes
Self-service: the field is configuration, not code	Removes the request entirely	Zero
Redraw the boundary so the capability sits in Checkout	Removes the dependency class, not one instance	Zero, permanently
A standing capacity reservation in Identity's sprint	Bounds the priority term rather than removing it	Predictable, still non-zero

The bottom half of that table is where a senior answer lives, and the last two rows are where the cost is. Moving a capability across a team boundary means changing who owns a codebase, whose on-call rota covers it, and often whose reporting line someone sits in. That is a months-long organisational change, not a facilitation move, and pretending otherwise is the fastest way to lose credibility with an engineering audience who have watched it fail before.

The standing reservation deserves a word because it is the honest middle. If Identity commits a fixed share of each sprint to consumer requests, ordered by the consumers themselves, the priority argument stops recurring per item and becomes one argument per quarter about the size of the share. That is a considerable improvement and it is still management rather than reduction.

What cadence alignment genuinely earns

Having argued it is not the main lever, do not throw it away, because two things do depend on it. The first is a shared integration point: teams that finish at different moments cannot demonstrate one increment together, and without an integrated increment nobody can see the product, only the parts. The second is comparability — throughput and cycle time measured over incompatible intervals cannot be aggregated, so a programme with three cadences cannot answer a question about itself.

There is also unhelpful arithmetic in mismatched lengths. Two-week and three-week cadences share a boundary only every six weeks, so a genuinely joint planning or review event happens once a quarter-ish by construction rather than by choice. Aligning to the shortest cadence, rather than to the average, is the version that helps: it lowers the pickup delay for everybody and it does not force the continuous-flow team to adopt a batch it does not need. A flow team can join the shared review and the shared retrospective without adopting a sprint commitment at all, and insisting it does is process for its own sake.

The specific mistake this question is built to catch

The mistake is answering a coupling question with a calendar answer, then defending it with the framework. Cadence is the visible attribute of the problem, it is cheap to change, and changing it produces a satisfying diagram in which all the boxes line up. Coupling is the actual attribute, it is expensive to change, and changing it produces an argument with a director about who owns what.

The other half of the mistake is subtler and interviewers listen hard for it: asking only which requests were late and never which were never made. Teams that have learned a cross-team request costs seven weeks stop making them. They build a local workaround, duplicate the data, or drop the feature and never mention it, so the dependency register looks healthy precisely because the coupling has become too expensive to attempt. Asking a team what they have quietly stopped asking for is the single most informative question available in this situation, and almost nobody asks it.

A dependency you have coordinated still costs a queue every time it fires; a dependency you have removed cost you one difficult organisational conversation, once.

---

© 2026 Preptima. Originally published at preptima.com.