A coordination rhythm is the fixed schedule of cross-team conversations that resolve dependencies and surface blockers, sized to the smallest set of meetings that actually clears work. It is fixed so that nobody has to call a meeting to raise a problem, and it is small because coordination that consumes the capacity it is meant to protect has stopped being coordination.
Meetings are one of the six operational drivers PPM4Agile governs, and the rhythm is where that driver lives during the Deliver practice.
How does a coordination rhythm work?
A rhythm is three things: a fixed slot, a fixed agenda, and a defined output.
The slot is on the calendar at the same time every cycle, whether or not anybody has a problem this week. The value of a fixed slot is that a blocker raised on Tuesday has a known destination on Thursday, so nobody has to decide whether a problem is big enough to warrant convening people. That decision is where coordination usually fails, because the people closest to a blocker consistently judge it smaller than it is.
The agenda is not a status round. It is the open dependencies by age, the sprint goals at risk, and anything one team needs from another before the next slot. Status belongs in the tool everyone can read on their own time.
The output is a list of decisions and named next steps with dates, written during the session. A cross-team meeting that produces notes but no owners has converted a blocker into a record of a blocker.
Most portfolios need two levels. Teams working on the same release need a weekly or twice-weekly slot of 30 minutes. The portfolio needs a longer session once per cadence, monthly or once per planning interval, where sequencing and capacity trade-offs get decided rather than escalated further.
How much coordination is enough?
It fails in both directions, and the two failures look nothing alike.
Too little, and teams find out about conflicts at integration. Two teams build against different assumptions about the same interface for six weeks, and the cost of the discovery is the rework plus everything that was queued behind it. The symptom is a release that goes from green to red in one reporting period, which is rarely a sudden change and usually a delayed discovery.
Too much, and the meetings become the work. Senior people spend their week reporting status to each other, teams optimize for having something to say, and the calendar leaves no block long enough to build anything. The symptom is a full coordination schedule where nothing gets unblocked, and where the real decisions happen afterward in a smaller conversation that was not on the calendar.
The size test is a practical one. For each recurring cross-team meeting, ask what got unblocked in it during the last month. If the honest answer is nothing, the meeting is a report and can become a written one. If the honest answer is that it prevented something, keep it.
What does a good coordination rhythm look like?
Every recurring cross-team meeting has a decision it exists to produce, and someone in the room who can make that decision when the teams cannot agree. People arrive prepared because the agenda is the same every time, and they leave with owners and dates rather than notes. Blockers get raised in the slot, not saved for a crisis.
The clearest sign it is working is that the schedule gets smaller over time, not larger. Meetings that stop unblocking anything are turned into written updates or deleted, and the time goes back to building.
What does a coordination rhythm look like in practice?
Picture a financial services organization running four recurring cross-team meetings during delivery: a daily scrum of scrums, a weekly delivery sync, a weekly architecture review, and a fortnightly steering call. Across one month, the first three produce no recorded decisions. Blockers are raised in them, noted, and carried to the next occurrence.
Now reduce the rhythm to two sessions. A 30-minute Tuesday cross-team session works the dependency register by age, with the delivery lead present and able to decide sequencing. A monthly portfolio session handles capacity trade-offs between initiatives, with the sponsors who can actually move people.
The architecture review is replaced by a standing rule: an interface change that affects another team is posted in the shared channel with the affected team named, and comes to Tuesday if it is not settled in two days. Time spent in cross-team meetings goes down, and the change to look for is dependency rows closing between sessions rather than being restated in them.
What goes wrong with coordination rhythms?
- The meeting is a status round. Each team reports, nothing crosses between them, and the only person who needed the information was the person compiling the report.
- No decision authority in the room. Every conflict becomes an escalation, and the rhythm turns into a queue feeding a slower meeting.
- Attendance grows. Once a session is seen as where things happen, people join to stay informed. A room of 20 is a briefing. Invite the teams with dependencies on each other and publish the notes to everyone else.
- Cancelled when things get busy. The rhythm is most valuable in exactly the weeks people want to skip it. Shorten it rather than cancel it.
- New meetings added for each new problem. The schedule accumulates and nothing is ever removed, because removing a meeting requires someone to argue that a problem no longer exists.
Coordination rhythm vs scrum of scrums: what is the difference?
A scrum of scrums is a specific scaling pattern: a representative from each team meets, often daily, to raise cross-team impediments. A coordination rhythm is the wider question of what the whole schedule of cross-team conversations should be, of which a scrum of scrums may be one part.
| Scrum of scrums | Coordination rhythm | |
|---|---|---|
| Scope | One recurring meeting between teams | The full set of cross-team slots |
| Level | Team representatives | Teams and the portfolio |
| Frequency | Usually daily or a few times a week | Sized to what actually clears work |
| Judged by | Is it happening | Is anything getting unblocked |
The practical difference is what you do when it is not working. Inside a scrum of scrums, the available fixes are attendance, timeboxing, and facilitation. At the level of the rhythm, the available fixes include deleting the meeting, moving the decision to someone who can make it, or accepting that the blockers are a symptom of too much parallel work, which is a portfolio matter rather than a meeting one. The WIP limits checklist covers that case.
Where does this fit in PPM4Agile?
The rhythm carries the Deliver practice work that the agile portfolio management terms glossary describes: dependencies getting owned and closed, sprint goals at risk being raised early, and the evidence for release readiness accumulating rather than being assembled the week before go-live. Getting the meeting set right is part of what a PPM4Agile implementation does when it configures the operational drivers.