Vact Managing Project Dependencies Between Teams
Dependencies between teams are the primary cause of delivery delays in multi-team organizations. A feature team waiting for an API from the platform team. A mobile team blocked on a backend change. A product launch waiting for legal review, marketing assets, and infrastructure provisioning. Managing these dependencies requires visibility, communication, and deliberate architectural choices that minimize coupling between teams.
Managing Project Dependencies Between Teams
Types of Dependencies
Technical Dependencies
Team A needs a component, API, or service from Team B before they can complete their work. These are the most common and most manageable dependencies because they can be anticipated during sprint planning and addressed through architectural decisions.
Knowledge Dependencies
Team A needs expertise or information from Team B. A team implementing payment processing needs input from the security team. These dependencies are often invisible until the work begins and the team discovers they lack necessary context.
Resource Dependencies
Team A needs a shared resource (environment, tool, person) that Team B is also using. Shared staging environments, limited design resources, and shared DevOps engineers create contention.
Approval Dependencies
Team A needs sign-off from a person or committee before proceeding. Legal review, security approval, and architecture review board decisions are common approval dependencies.
Making Dependencies Visible
Dependency Boards
Create a dedicated Kanban board for cross-team dependencies:
| Column | Description |
|---|---|
| Identified | Dependency discovered, not yet communicated |
| Requested | Request made to the providing team |
| In Progress | Providing team is working on it |
| Delivered | Dependency resolved, requesting team unblocked |
| Verified | Requesting team confirms it meets their needs |
Each dependency card includes: what is needed, which team needs it, which team provides it, the date needed by, and the impact if not delivered on time.
Dependency Mapping in Sprint Planning
During sprint planning, explicitly identify all cross-team dependencies for the upcoming sprint. For each dependency, answer:
- Who provides it?
- When is it needed?
- What happens if it is late?
- Is there a workaround or mock that unblocks the requesting team?
Cross-Team Sync Meetings
Hold a weekly 30-minute cross-team sync where representatives from each team review the dependency board, discuss upcoming dependencies, and negotiate timelines. This meeting is distinct from individual team standups and focuses exclusively on inter-team coordination.
For organizations using SAFe, the Scrum of Scrums ceremony serves this purpose. For smaller organizations, a simple weekly sync suffices.
Reducing Dependencies
The best dependency is one that does not exist. Architectural and organizational choices can eliminate or minimize dependencies:
API Contracts and Mocking
When Team A depends on Team B’s API, agree on the API contract (endpoint, request/response format) early. Team A can then build against a mock implementation of the contract while Team B builds the real implementation. Both teams work in parallel, and integration happens when both are ready.
Decoupled Architecture
Microservices, event-driven architectures, and well-defined interfaces reduce runtime and development-time coupling between teams. Each team can develop, deploy, and iterate on their services independently.
Self-Sufficient Teams
Structure cross-functional teams to be as self-sufficient as possible. A team that includes its own frontend developer, backend developer, and designer has fewer external dependencies than a team that relies on separate frontend, backend, and design teams.
Feature Flags
Feature flags allow teams to deploy incomplete features that are hidden from users. This eliminates deployment dependencies: Team A can deploy their code without waiting for Team B’s complementary feature, and both features are activated simultaneously via flag configuration.
Escalation for Blocked Dependencies
When a dependency is not delivered on time and the requesting team is blocked, escalation follows a defined path:
- Team-to-team: The requesting team communicates directly with the providing team to understand the delay and negotiate a new timeline.
- Manager-to-manager: If the teams cannot resolve the conflict, their respective managers negotiate priority and resource allocation.
- Director-level: If the delay impacts project milestones or business commitments, escalate to the director level for a priority decision.
Each escalation level should resolve within 24-48 hours. Escalation that takes a week defeats its purpose.
Measuring Dependency Health
| Metric | Target | Warning Sign |
|---|---|---|
| Dependencies per sprint | Decreasing | Increasing over time |
| Dependency delivery rate | > 90% on time | < 70% on time |
| Time to resolve blocked dependency | < 48 hours | > 1 week |
| Stories blocked by dependencies | < 10% per sprint | > 25% per sprint |
Dependencies and Agile at Scale
Scaling frameworks exist largely to address the dependency challenge. SAFe’s PI Planning event is specifically designed to identify and negotiate cross-team dependencies across an entire program increment. LeSS reduces dependencies by having all teams pull from a single product backlog. Nexus addresses dependencies through the Nexus Integration Team.
Regardless of the framework, the fundamental practices are the same: make dependencies visible, communicate proactively, resolve blocks quickly, and invest in architectural choices that reduce coupling. Teams that manage dependencies well deliver faster and more predictably than teams that discover dependencies mid-sprint.