A recurring theme in scaled-Agile discussions on LinkedIn this month: teams aren’t slow because they lack effort, they’re slow because they’re waiting on each other. Research backs the anecdote — a 2026 industry report found that nearly 70% of delays in scaled Agile initiatives trace back to unmanaged cross-team dependencies. The work gets done; it just gets done late because the blocking team finished on a different schedule, in a different tool, where nobody could see it coming.

Why cross-team dependencies hide

Single-team dependencies are usually visible — they sit on the same board. Cross-team dependencies hide because of fragmentation: Team A’s blocking story lives in a different project, board, or even a different tool than Team B’s blocked story. Without a shared view, nobody sees the link until the blocked work is already stalled. By then the only options are to descope or slip the date.

Surface dependencies before you commit, not after

The single highest-leverage change is timing: map dependencies before teams commit to sprint or release scope, not after they’re stuck. That means three habits:

• Make the link explicit. Record every “needs” and “blocks” relationship as a real link between issues, not a note in a comment.
• Check links at planning time. A story that depends on another team’s unfinished work isn’t ready, no matter how well it’s estimated.
• Sync across teams regularly. A lightweight Scrum-of-Scrums exists to surface inter-team blockers and drive them to action, not just to share status.

Design for fewer dependencies

The best dependency is the one you don’t have. Cross-functional teams that hold the skills to deliver a feature end-to-end need fewer hand-offs than specialist teams organized by component. You won’t eliminate every dependency, but every one you design out is a delay you’ll never have to manage.

Making cross-team dependencies visible in Jira

Native Jira links record a dependency but don’t make it easy to see the whole web across projects and boards — which is exactly where cross-team work lives. Dependency Manager for Jira visualizes dependencies across teams and projects, flags blocking issues that aren’t progressing, and surfaces the at-risk links during planning rather than after a sprint stalls. When you can see, before committing, that a release-critical story depends on another team’s not-yet-started work, you can sequence around it or escalate while there’s still time to act.

Because unmanaged dependencies are one of the top reasons releases slip, dependency visibility is really a release-planning discipline. See how it fits the bigger picture in our release planning guide, and for the single-team view, read managing dependencies in Scrum.

Rob Borges

Rob Borges spent the first half of his career hunting waste as a Lean Six Sigma Master Black Belt and wrangling portfolios as a PMI Portfolio Manager — until he realized the tidiest process on earth still can't out-plan an optimistic human. So he switched sides and became an Agile Coach. These days he helps Kanban, Scrum, and Agile-at-Scale teams trade gut-feel deadlines for flow data, turning "we'll probably ship sometime in Q3" into release dates leaders can actually take to the board. His rule of thumb: hope is not a forecast, but your throughput history usually is.

See Full Bio