Cross-Team Dependencies: Design Them Out Before You Coordinate Them

In most organizations with more than a few teams, a surprising share of leadership attention goes to coordination: dependency boards, integration meetings, program managers chasing handoffs. When delivery slows, the usual response is to add more of it, with another sync meeting, another coordinator or another tracking tool.

The scaling frameworks' own guidance points in a different direction. Before you get better at managing dependencies between teams, ask how many of them you could remove by changing how teams, products and work are structured. That is an organizational design decision, which makes it a leadership decision.

Why dependencies are a leadership problem

The Nexus Guide from Scrum.org says cross-team dependencies are often caused by mismatches in two areas: product structure, meaning how cleanly different concerns are separated in the product, and communication structure, meaning how people communicate within and between teams. It also notes that increasing the number of people and the size of a product "increases complexity and dependencies, the need for collaboration, and the number of communication pathways involved in making decisions."

Neither of those causes is something a single team can fix. Team boundaries, reporting lines, architecture investment and the number of people assigned to a product are set by leaders. The U.S. Government Accountability Office's Agile Assessment Guide (GAO-24-105506) acknowledges the same reality, noting that many projects incur dependencies and require multiple agile teams to collaborate, and that a number of frameworks exist to help in exactly those circumstances.

Component teams versus feature teams

The biggest structural driver of dependencies is how teams are formed. LeSS contrasts two models. A component team owns one part of the system, such as a database layer or a user interface. A feature team, in LeSS's definition, is "a long-lived, cross-functional, cross-component team that completes many end-to-end customer features—one by one."

The LeSS comparison table is blunt. With component teams, dependencies between teams lead to additional planning; feature teams minimize dependencies between teams to increase flexibility. LeSS adds that a component team structure reinforces sequential development, with many queues, high work in progress, many handoffs and increased multitasking.

For example, imagine a hypothetical benefits portal built by three teams: one for the web front end, one for back-end services and one for data. Almost every customer-facing change needs all three, so every change becomes a three-team scheduling exercise. Reorganizing into teams that can each deliver a whole feature removes that coordination instead of managing it.

LeSS is candid about the trade-offs. It notes that every member of a feature team does not need to know the whole system, because the team as a whole needs the skills. It warns that hybrid models "have the drawbacks from both worlds." And it describes a safe but slow transition: form one feature team inside the existing structure and add more once it performs well.

Make the remaining dependencies visible early

Some dependencies will remain, and the frameworks agree they should surface before work starts rather than mid-sprint. In Nexus, Cross-Team Refinement of the Product Backlog "reduces or eliminates cross-team dependencies," and the Product Backlog must be decomposed so that dependencies are transparent, identified across teams, and removed or minimized. The Nexus Sprint Backlog then makes the remaining cross-team dependencies transparent, and the Nexus Daily Scrum exists to identify integration issues.

SAFe takes a more structured route. Its Agile Release Train aligns multiple teams to a common vision and roadmap, with cadence and synchronization through Planning Intervals, so that, in SAFe's words, the value teams develop "is ready for use at the same time."

Either way, the leadership question is the same: are dependencies discovered in planning, or discovered when a team is blocked?

Prefer decentralized coordination

When coordination is needed, leaders often reach for a central role. LeSS rules lean the other way: "Cross-team coordination is decided by the teams. Prefer decentralized and informal coordination over centralized coordination." The rules list techniques such as Just Talk, communicating in code, cross-team meetings, component mentors, travelers, scouts and open spaces.

Scrum@Scale addresses the same concern through structure. Its guide says that grouping teams into a Scrum of Scrums, and those into larger groupings, "reduces the number of communication pathways within the organization." At the top, its Executive Action Team coordinates multiple Scrums of Scrums and interfaces with the parts of the organization that are not agile. The guide makes it accountable for removing impediments that the Scrums of Scrums cannot remove themselves.

Integrate continuously, not at the end

A dependency that is only tested at release time is a risk hiding in plain sight. GAO's guide calls continuous integration of developed components on a daily, if not more frequent, basis a critical success factor for large and complex programs. It warns that teams that delay integration until just before release will likely run out of time to test, fix defects and prepare infrastructure.

LeSS makes the same link from the team-design side: applying modern engineering practices, especially continuous integration, is essential when adopting feature teams. Continuous integration supports shared code ownership, which LeSS calls a necessity when multiple teams work on the same components at the same time. Nexus builds it into its definition of success, with an Integrated Increment at least once every Sprint.

What leaders can do this quarter

You do not need a reorganization to start. These steps are within most leaders' reach:

• Ask each team to list the other teams it waited on in the last month, and look for patterns that point to a team boundary or architecture problem.
• Before approving a new coordination role or meeting, ask which dependency it manages and whether that dependency could be removed instead.
• Limit how many cross-team initiatives are in progress at once. The Kanban Guide notes that controlling work in progress often improves focus, commitment and collaboration.
• Watch blocked work. The Kanban Guide lists unblocking blocked work and ensuring items do not age unnecessarily as part of actively managing a workflow.
• Fund the engineering work that makes integration routine, such as build automation and automated tests, which GAO identifies as necessary for continuous integration.
• Try one feature team as an experiment, and compare how often it waits on others.

Key takeaways

• Many cross-team dependencies come from team boundaries and product architecture, which leaders control.
• LeSS contrasts component teams, which create dependencies and extra planning, with feature teams, which minimize them.
• Make unavoidable dependencies visible in refinement and planning, as Nexus and SAFe both describe.
• Prefer decentralized coordination between teams over adding central coordinators.
• Integrate continuously; GAO calls daily integration a critical success factor for large programs.

Sources

• Scrum.org, The Nexus Guide (January 2021)
• The LeSS Company, Feature Teams
• The LeSS Company, LeSS Rules (November 2024)
• Jeff Sutherland and Scrum Inc., The Scrum@Scale Guide, Version 2.1 (February 2022)
• Scaled Agile, Inc., Agile Release Train
• John Coleman and Daniel Vacanti, The Kanban Guide (May 2025)
• U.S. Government Accountability Office, Agile Assessment Guide: Best Practices for Adoption and Implementation, GAO-24-105506 (reissued with revisions December 15, 2023)