The synchronization of teams working on the same product is a crucial challenge in large-scale agility. Without proper coordination, dependencies between teams can cause delays, rework, and ultimately a loss of overall efficiency.

Why Synchronize?

When multiple teams work on the same product, they inevitably share dependencies:

  • Technical dependencies (shared components, APIs, etc.)
  • Functional dependencies (interconnected features)
  • Resource dependencies (shared infrastructure, environments, etc.)

Without synchronization, these dependencies can lead to:

  • Integration conflicts
  • Delays in delivery
  • Quality issues
  • Frustration within teams

Synchronization Levels

Synchronization can occur at different levels:

1. Daily Synchronization

  • Scrum of Scrums: representatives from each team meet daily
  • Shared communication channels (Slack, Teams, etc.)
  • Shared task boards

2. Sprint/Iteration Synchronization

  • Aligned sprints across all teams
  • Joint planning sessions
  • Synchronized demos
  • Joint retrospectives

3. Release Synchronization

  • Product Increments coordinated across teams
  • Integration testing phases
  • Coordinated deployments

Synchronization Practices

Scrum of Scrums

The most common practice: one representative per team (often the Scrum Master) participates in a daily meeting to:

  • Share progress
  • Identify blocking dependencies
  • Coordinate necessary actions

System Demo

A regular demonstration (often at the end of each sprint) where all teams present their work integrated into the overall system.

Big Room Planning

A planning session bringing together all teams to:

  • Define common objectives
  • Identify dependencies
  • Plan work for the next increment

Communities of Practice

Technical or functional groups that meet regularly to:

  • Share best practices
  • Align technical decisions
  • Resolve cross-cutting issues

Common Pitfalls

Over-synchronization

Too much synchronization can become counterproductive:

  • Too many meetings
  • Loss of team autonomy
  • Slowed decision-making

The key is to find the right balance between necessary coordination and team autonomy.

Lack of Preparation

Synchronization meetings are only effective if teams prepare properly:

  • Update shared information beforehand
  • Identify issues to discuss
  • Come with proposals, not just problems

Ignoring Dependencies

Failing to identify and manage dependencies is the main source of synchronization problems. It’s essential to:

  • Map dependencies regularly
  • Make them visible (dependency boards)
  • Actively manage them

Conclusion

Synchronization is essential for agility at scale, but it must be done intelligently. The goal is not to synchronize everything, but to synchronize what’s necessary while preserving team autonomy as much as possible.

The key is to find the right balance between coordination and autonomy, between structure and flexibility."

For several years, agility – or a certain form of agility – has gained ground in large-scale enterprises. Its success has pushed it to question how to respond beyond the team.

First, the team

Because the team is the essential component of an agile organization. It’s the collection of teams that make up the organization. They can be grouped by intermediate levels (product, program, etc.). When we talk about agile at scale, it’s to evoke this multi-team dynamic. In an agile team, we sought: autonomy and involvement in a scope. So we redesigned our scopes in a “vertical” way, with multidisciplinary teams. The benefit being not only to involve by controlling one’s work tool end-to-end, a real autonomy, but also to deliver finished things (always end-to-end), and thus benefit from commitment and a quick return on investment. All this reversed the classic structure of previous years by breaking down “horizontal” silos.

Then inter-team synchronization

Synchronization between silos with nothing finished and without autonomy was a real headache (it still is in many places), and a system reinforcing inter-silo animosities. By inverting this matrix, dialogue was relaunched (in addition to commitment and quick return on investment). But with programs or large multi-team projects, synchronization becomes necessary again, we’ve simply changed the axis of the matrix. Instead of having to aggregate pieces from different silos to see if everything starts working (with the risk-taking we know and lack of reactivity – everything is needed to assemble –), we now must aggregate the pieces from different entities to see if they make sense together and if they continue to work together. We must do it upstream to maintain sense of value (does my whole make sense, have value), and we must do it downstream to ensure that what is finished is truly finished in the whole. Finally, we must do it regularly to have a sense of progress (and thus reinforce commitment) and always benefit from a quick return on investment.

In agile teams, this generally happens at two moments: during planning, during the review (what some call the demo). And this is consolidated in project/product portfolios.

On planning (quarterly planning, pi planning, etc.)

Generally, over a cycle we trigger what some now call “quarterly planning”, or others “pi planning” (my next article: “why to be wary of SAFe” without a question mark), etc. The cycle is generally two months or three months. The idea is to synchronize teams working on the same “macro-scope”. Synchronize teams at the start of a cycle? That means:

  • co-locating them. Teams of 7-8 maximum and maximum of 6-7 teams, in my experience (some people go much further). We break down into groups of fifty people if we need to go beyond that, and this for one or two days.
  • ensuring a common vision (and why not present it through impact mapping)
  • avoiding the maximum number of dependencies to maintain a sense of control and autonomy
  • validating the harmonization of action plans, for this I try to use visual management through user story mapping.

It is essential that storytelling prevails over senseless nesting. Each story is part of the big story.

The start of a cycle is also an opportunity to strengthen agile culture

Ideally, this synchronization doesn’t only happen on the product but also on intention and attitude, on the culture of the group as a whole.

Assessment of the culture

We can question respect for agile culture or the values we wish to uphold at the beginning of each cycle. For example with the Spotify healthcheck

or on a spider chart.

Proposing experiments

Strengthening agile culture also means reinforcing the idea of being able to experiment, the idea of continuous improvement through experiments. What will we experiment with during this cycle? Where do we need to advance? Experimentation is at the heart of successful change management. Thus, the list of experiments for the cycle is a good thing to define.

On the product (demos, reviews)

At the end of this cycle, we ensure that what we judged finished along the way is truly finished and that the view we have of the big story still makes sense. Because it is – very – desirable that we were able to validate progressively that we truly have something finished globally (problem of “commit” in IT environments on a “trunk” or on a “branch” for example; problem in IT of validation platforms, pre-production environments that integrate the finished additions of each team along the way).

This global coherence is achieved during reviews (also called “demos”). All teams gather and show their story in the middle of the big story that takes shape through the small stories.

My preference is for this synchronization during reviews to only exist at the end of the cycle (but not too late!). I appreciate that teams carry their product visibly, and thus independently during the cycle (review dedicated to each team). This mass effect of multi-team reviews tends to erase the team’s identity. Moreover, it considerably lengthens the duration of reviews and thus key people show up less frequently than they should.

Project portfolio

This multi-team aggregation is read through a project/product portfolio: ideally in the form of a kanban dedicated to this. This aggregation is also read through a consolidated release plan (as if you were aggregating 4 or 5 of this type of release plan)

A short series on scaling (and self-organization).

And otherwise, the event we’re organizing around agile at scale with Dragos Dreptate: