Dependency

A dependency exists when one piece of work cannot proceed without another being completed first. Dependencies create connections between tasks, teams, systems, or organizations that constrain when and how work can happen. In product development, managing dependencies is often the difference between smooth delivery and chaotic delays.

Why it matters

Dependencies are where projects fail. A feature slips because the API it depends on isn't ready. A sprint stalls because design assets haven't been delivered. A release delays because a partner hasn't certified their integration. The more dependencies in a project, the more opportunities for delays to cascade.

For product managers, dependencies determine what's possible to build and when. A technically isolated feature can ship independently. A feature requiring coordination across multiple teams and systems needs careful orchestration. Understanding dependencies shapes prioritization, planning, and communication.

Agile methods encourage cross-functional teams precisely to reduce dependencies. When a team contains everyone needed to deliver a feature, external dependencies disappear. But in practice, dependencies between teams, systems, and organizations are unavoidable at scale.

Types of dependencies

Dependencies come in several forms:

Task dependencies exist when one work item must complete before another can start. The database schema must be designed before the API can be built. The API must exist before the frontend can integrate.

Resource dependencies occur when multiple work items need the same limited resource. If one database administrator supports three teams, their availability creates dependencies between otherwise independent work.

Technical dependencies arise from system architecture. A service that calls another service depends on that service being available and stable. A mobile app depends on the app store review process.

External dependencies involve parties outside your organization. Third-party APIs, partner integrations, vendor deliverables, and regulatory approvals are all external dependencies.

Knowledge dependencies exist when work requires information or decisions from others. Waiting for legal review, executive approval, or design direction creates knowledge dependencies.

Managing dependencies

Several practices help manage dependencies effectively:

Identify early. Dependencies discovered late cause more damage than those identified during planning. Systematic dependency identification during refinement and planning catches issues when there's time to address them.

Visualize explicitly. Dependency boards, roadmap swimlanes, and planning tools that show connections help teams see where coordination is needed. What's invisible doesn't get managed.

Communicate proactively. When your work depends on others, communicate your timeline and needs early. When others depend on you, keep them informed of progress and risks.

Create buffers. Schedules that assume every dependency resolves on time are fragile. Building slack around dependent work absorbs inevitable slippage.

Reduce where possible. Some dependencies can be eliminated through architecture choices, team structure, or scope decisions. A dependency avoided is better than one managed.

Have backup plans. When critical dependencies involve high uncertainty, contingency plans reduce risk. What will you do if the partner API isn't ready? What's the fallback if design takes longer than expected?

Dependencies in agile

Agile methods acknowledge dependencies while trying to minimize them:

Cross-functional teams include all skills needed to deliver work, eliminating handoffs and external coordination for most tasks.

Vertical slicing creates work items that span the full stack, reducing technical dependencies between front-end and back-end work.

Continuous integration makes technical dependencies explicit through frequent integration rather than late-stage surprises.

Regular synchronization through ceremonies like daily standups and sprint planning surfaces dependencies early when they can be addressed.

Despite these practices, dependencies don't disappear entirely. Large organizations inevitably have platform teams, shared services, and enterprise systems that create dependencies. Scaled agile frameworks explicitly address cross-team dependency management through mechanisms like PI Planning.

Common problems

Hidden dependencies cause surprises because they weren't identified during planning. Teams discover mid-sprint that they need something from another team that's not available.

Dependency chains amplify delays. When A depends on B which depends on C, any delay cascades through the chain. Long chains are particularly risky.

Circular dependencies create deadlock where A needs B and B needs A. These require breaking the cycle through careful scoping or parallel work.

Deprioritized dependencies occur when another team knows about your dependency but doesn't prioritize it. Your urgent need is their backlog item.

Over-engineering dependencies adds unnecessary connections. Teams sometimes create dependencies through poor architecture or process rather than genuine necessity.

Dependency denial pretends dependencies don't exist because they're inconvenient to acknowledge. This leads to optimistic plans that reality doesn't support.

Reducing dependencies through design

Architectural and organizational choices affect dependency load:

Loose coupling in system design means services can evolve independently. Well-defined interfaces and contracts reduce the coordination needed for changes.

API contracts established early let teams work in parallel against agreed interfaces rather than waiting for implementations.

Modular architecture creates natural boundaries where changes on one side don't ripple to the other.

Team topology aligned with architecture reduces cross-team dependencies. Conway's Law works both ways - you can structure teams to get the communication patterns (and dependencies) you want.

Feature toggles allow incomplete work to ship without creating dependencies on completion. Features can be integrated continuously and enabled when ready.

Dependencies are an inherent part of building complex products. Acknowledging them, tracking them, and actively managing them prevents the invisible web of connections from strangling delivery. The goal isn't zero dependencies - it's visible, managed dependencies that don't surprise you.