In 30 seconds
- Dependencies cause waiting, risk and late surprises.
- Best strategy: remove them; next best: make them visible.
- Plan around the ones you can't remove.
Types
| Type | Example |
|---|---|
| Team | Feature needs another team's API change |
| Technical | Shared database or component |
| External | Vendor or regulator |
| Knowledge | Only one person knows the system |
Reducing them
- Feature teams instead of component teams
- Clear service interfaces and contracts
- Spreading knowledge through pairing
- Rethinking team boundaries with Team Topologies
Tracking the rest
Make dependencies visible, for example on a program board during PI Planning, and review them in Scrum of Scrums. Sequence work so dependent items are done first.
Myth vs reality
Myth · Dependencies are unavoidable, so manage them.
Reality · Many can be designed away.
Myth · A dependency board fixes dependencies.
Reality · It only shows them.
Myth · Component teams are more efficient.
Reality · They often create more dependencies.
FAQ
How do we spot hidden dependencies?
Walk through stories end to end in refinement.
What's a dependency board?
A visual showing which teams depend on which items, and when.
Who owns cross-team dependencies?
The teams involved, with help from a coordinator if needed.