A dependency is a reliance in which one software, organizational, or architectural element requires another to function or change successfully. Changing one component can affect connected components, so dependencies shape both technical evolution and team flow. section 5.4.2 section 11.0
Useful questions for examining a dependency include:
- Does it slow a team’s rate of change or require teams to synchronize code, decisions, or deployments? section 11.0 section 10.1.1
- As one component evolves, what new products, practices, or sources of value become possible? section 5.4.2
- Would changing boundaries remove the dependency, or would it merely relocate an unresolved coordination or priority problem? section 11.4.2
When a dependency makes teams awkward
A logistics company launched a second product that depended on its established product. The new-product team needed rapid experimentation, while the established-product team prioritized stability for a large customer base. Daily requests created friction because neither team could meet its goals independently. The practical response was to clarify company priorities, agree where compromise was acceptable, and reward both teams for the overall outcome before considering boundary changes. section 11.4.2
Use the dependency diagram to inspect how a new product relies on an existing product and why the interaction becomes awkward. section 11.4.2
