Delivery Manager's Guide to Dependency Management

Why Dependencies Kill Delivery

In a single-team environment, dependencies are internal — the team manages them naturally. In multi-team environments, dependencies become external — they cross team boundaries, require coordination, and introduce waiting time that no single team controls.

Research consistently shows that cross-team dependencies are the primary predictor of delivery delays in enterprise software. A team with three external dependencies has a significantly lower probability of meeting its sprint commitment than a team with zero.

The Dependency Lifecycle

Every dependency moves through a lifecycle. Your job is to ensure each one progresses — and to intervene when it stalls.

1. Identification

Dependencies must be surfaced before they become blockers. The earlier a dependency is identified, the more options exist for resolution.

When to identify:

• During backlog refinement (stories that need input from other teams)
• During sprint planning (items that can't start without another team's output)
• During PI Planning (programme-level dependencies across ARTs)
• During architecture discussions (system integration points)

What to capture:

• Providing team and consuming team
• What's needed (specific deliverable, API, data, decision)
• When it's needed by (date, sprint, milestone)
• Who owns delivery on the providing side
• What happens if it's late (impact assessment)

2. Tracking

Once identified, dependencies need active tracking — not passive hope.

The dependency board: A shared, visible board (physical or Jira board) showing all active dependencies with:

• RAG status (Green: on track, Amber: at risk, Red: blocked/late)
• Owner on each side (provider and consumer)
• Due date and current confidence level
• Last update date (stale items = hidden risk)

Update cadence: Weekly minimum. For critical-path dependencies, daily.

3. Resolution

Dependencies are resolved when the consuming team has what they need to proceed. Resolution strategies:

Eliminate: Redesign the work so the dependency doesn't exist. Can the consuming team build what they need themselves? Can the architecture be changed to decouple the teams?

Sequence: Plan the work so the providing team delivers before the consuming team needs it. Requires advance planning and reliable delivery from the provider.

Parallel with interface agreement: Both teams work simultaneously against an agreed interface contract (API spec, data format). Risk: the contract might change. Mitigation: frequent integration testing.

Accept and buffer: Acknowledge the dependency, add buffer time to the consuming team's plan, and monitor closely. Use when elimination and sequencing aren't possible.

4. Escalation

When a dependency is at risk and the teams can't resolve it themselves, escalate:

• First escalation: Delivery Manager facilitates a conversation between the two teams. Often, a direct conversation resolves misunderstandings or reprioritises work.
• Second escalation: If the providing team can't prioritise the work, escalate to their Product Owner or Delivery Manager. Make the business impact visible.
• Third escalation: If organisational barriers prevent resolution (different budgets, different priorities, different leadership), escalate to steering committee with a clear decision request.

The Dependency Review

Run a weekly dependency review as part of your delivery governance:

Format (15-20 minutes): 1. Walk the dependency board from Red → Amber → Green 2. For each Red/Amber item: What's the blocker? Who owns resolution? By when? 3. New dependencies identified this week 4. Dependencies resolved this week (celebrate!) 5. Any escalations needed

Attendees: Delivery Manager + one representative per team (usually Scrum Master or Tech Lead)

Reducing Dependencies Structurally

The best dependency is one that doesn't exist. Invest in structural changes that reduce dependencies over time:

Feature teams over component teams: Teams that own a vertical slice of the product (frontend + backend + data) have fewer external dependencies than teams organised by technology layer.

API contracts and decoupling: Well-defined API boundaries between services allow teams to work independently. Invest in contract testing (Pact, Spring Cloud Contract) to catch integration issues early.

Self-service platforms: Platform teams that provide self-service capabilities (infrastructure, CI/CD, monitoring) eliminate dependencies on manual provisioning.

Shared libraries and standards: Common libraries for cross-cutting concerns (authentication, logging, error handling) reduce the need for teams to coordinate on shared functionality.

Architecture alignment: Regular architecture reviews that consider team boundaries. If two teams constantly depend on each other, either merge them or redesign the system boundary.

Dependency Metrics

Track these to measure whether your dependency management is improving:

• Dependency count per team: How many external dependencies does each team have? (Target: decreasing over time)
• Dependency resolution time: Median time from dependency identified to resolved. (Target: within one sprint)
• Dependency-caused delays: Sprint items delayed because a dependency wasn't met. (Target: <5% of sprint items)
• Stale dependency rate: Dependencies on the board with no update in 7+ days. (Target: zero)
• Escalation rate: % of dependencies that require escalation beyond the teams involved. (Target: <20%)

If dependency-caused delays exceed 10% of sprint items, the delivery system has a structural problem that process alone can't fix. Look at team topology and architecture.

Common Dependency Anti-Patterns

The invisible dependency: Not identified until it becomes a blocker mid-sprint. Fix: make dependency identification part of every refinement and planning session.

The assumed dependency: "We think Team B is working on that" without confirmation. Fix: every dependency has a named owner on the providing side who has explicitly committed.

The one-way communication: Consuming team logs the dependency but never talks to the providing team. Fix: dependencies require a conversation, not just a Jira ticket.

The permanent dependency: The same dependency appears sprint after sprint because nobody invests in eliminating it. Fix: track recurring dependencies and invest in architectural solutions.

---

Download the [Dependency Matrix template](/templates) to track cross-team dependencies with RAG status and escalation paths.