Dependency Mapping

---

Origins

Dependency mapping isn't an Agile invention — project managers have drawn dependency diagrams since the dawn of project management. What changed in Agile contexts is what teams do with them. Traditional dependency mapping produced a critical-path diagram and a schedule; Agile dependency mapping produces a conversation, a coordination plan, and a list of risks to track.

The practice spread through SAFe's Program Increment Planning (where dependency mapping is the most visible artifact), through Scrum of Scrums coordination, and through team-of-teams patterns generally. The shared insight: cross-team dependencies are usually where multi-team releases break down, and surfacing them early is dramatically cheaper than discovering them late.

What Counts as a Dependency

Several kinds of dependency matter:

• Finish-to-start: Team A must finish X before Team B can start Y. The classic dependency.
• Concurrent: Teams A and B must coordinate on something they're both building — an interface contract, a shared schema.
• Resource: Both teams need the same specialist, environment, or piece of infrastructure.
• Decision: Team A is waiting on a decision from a stakeholder or another team.
• Knowledge: Team A needs information that only Team B has.
• External: Vendor delivery, regulatory approval, customer sign-off — outside the team's control entirely.

All of them can derail a release. Different kinds need different management.

How to Map Dependencies

1. Identify the work items

List the items in the release across all contributing teams. Each item is a node in the eventual map.

2. Ask the dependency question for each pair

For each item, walk through: does this depend on anything? Does anything depend on this? Different teams may have different answers; surfacing the disagreement is part of the value.

3. Draw the dependencies

Visual map of items as nodes, dependencies as arrows. Color-code by team. Patterns become visible — one team in the middle that everyone depends on; circular dependencies between two teams; an entire team's work that depends on one external item.

4. Sequence with the dependencies

Plan the release order respecting the dependency graph. Items that everyone else depends on need to land early.

5. Identify risks

Which dependencies are most likely to slip? Which would do the most damage if they did? Track the risky dependencies explicitly.

6. Plan mitigation

For each high-risk dependency: can it be eliminated (build a workaround)? Can it be parallelized (mock, stub, contract-test)? Can it be moved earlier (do the dependency work first)?

The PI Planning Wall

SAFe's Program Increment Planning produces a large visual wall — sticky notes representing items, red yarn or strings connecting dependencies. The visual scale matters; on a board with 200 items, the patterns are immediately visible. The same exercise in a spreadsheet doesn't produce the same insight.

You don't need SAFe to use the pattern. Any multi-team release can benefit from a physical or digital wall with items and visible dependencies. Miro, FigJam, or a literal wall all work.

Reducing Dependencies

The best dependency is the one that doesn't exist. Several patterns reduce dependency density:

• Contract-first design: agree on the interface between two teams' work; each builds against the contract with mocks; integration is mostly free.
• Vertical team alignment: organize teams around customer-facing slices rather than horizontal layers. Most dependencies disappear when one team owns the whole slice.
• Self-service platforms: a platform team's job is to make other teams independent of it. Dependencies become API calls, not coordination meetings.
• Pull requests instead of escalations: when one team needs another team's code changed, a PR is faster than a request.
• Async APIs: events and queues decouple producers and consumers in time, reducing real-time coordination needs.

Common Pitfalls

• Mapping once, never updating: dependencies change as work progresses. A static map is wrong by week two.
• No risk assignment: all dependencies treated equally. The truly dangerous ones get the same attention as the trivial ones.
• Coordination meetings as mitigation: weekly meeting to "track dependencies" without any actual mitigation work. The dependencies persist and so do the meetings.
• Missing dependencies: teams forget to list dependencies they don't think of as such. Resource dependencies and decision dependencies are commonly missed.
• Mapping without ownership: each dependency needs a named owner who is accountable for managing it. Unowned dependencies stay unmanaged.
• Architectural denial: heavy dependency maps are signals about team or system structure. Sometimes the right answer is restructuring, not better dependency tracking.

Coaching Tips

Make It Visual

Lists hide patterns; walls and boards reveal them. Use visual format for dependency mapping, not spreadsheets.

Assign an Owner

Every dependency needs a named owner. Unowned dependencies are unmanaged and slip silently.

Rank by Risk

Not all dependencies are dangerous. Rank by likelihood-of-slip and impact-if-slipped. Spend attention on the top of the list.

Watch for the Bottleneck Team

If one team appears in many dependencies, that team is structurally a bottleneck. The fix is usually organizational, not coordinative.

Mitigate, Don't Just Track

Dependency meetings without mitigation work are theater. Each high-risk dependency needs an action: workaround, parallelization, or earlier delivery.

Update Continuously

A static map is wrong by week two. Update at every sprint boundary, or whenever a dependency completes or shifts.

Summary

Dependency mapping is one of the cheapest practices for de-risking multi-team work. A few hours of mapping at the start of a release saves weeks of late-discovered blockers. The discipline isn't producing the map; it's keeping the map alive and using it to drive decisions about sequencing, mitigation, and structural change.

The deeper lesson most teams resist is that heavy dependency density is itself a problem — usually a signal about team organization or system architecture. Mapping and tracking dependencies forever is treating a symptom; restructuring to reduce dependency need is treating the cause.

Back to Agile Delivery