This article is the third in the From Busy to Flow series, which explores what it takes to unlock sustainable agility by improving the flow of work. In the previous article, we examined key metrics for measuring flow across an organization. This post builds on that foundation by focusing on one of the most critical and often hidden dimensions of flow, what I am calling, Dependency Friction. By understanding how dependencies impede flow—and learning how to quantify that friction—organizations can make more informed decisions about where to invest in improvement.
Dependencies and Flow
Agile organizations strive for flow—the smooth, steady movement of work through a process to ensure that good economic value is delivered. Achieving flow means avoiding idle or blocked work in economically sensible ways.
Yet across many organizations, flow remains elusive—not because individual teams are failing, but because the broader system is entangled in dependencies. A dependency is a relationship between two or more activities or resources that requires a level of coordination to achieve desired flow.
Dependencies are everywhere—between teams, platforms, governance bodies, shared services, and even policy layers. These are all forms of shared dependencies: dependencies where the work required to satisfy the dependency spans across teams or organizational boundaries. When these shared dependencies accumulate, they introduce Dependency Friction: a systemic drag on the organization’s ability to deliver value predictably, sustainably, and efficiently.
What Is Dependency Friction?
Dependency Friction is the organizational tax created by the waiting, coordination overhead, rework, and delivery risk associated with managing dependencies across the system.
It’s not limited to blocked work—although blockers are part of the picture. A blocker is something that actively impedes the flow of work. Work must be in a blocked state to classify something as a blocker.
All dependencies are potential blockers—they carry the risk of impeding flow if coordination fails. A dependency becomes a blocker when it actively prevents work from progressing. Importantly, not all dependencies become blockers—but all blockers are the result of a failed or delayed coordination of a dependency.
Even when work isn’t fully blocked, dependencies can still degrade flow through uncertainty, delays, or coordination overhead. Recognizing this distinction is essential to understanding the full impact of Dependency Friction across a system.
This friction:
- Reduces flow efficiency, increasing the time work spends waiting rather than progressing.
- Introduces delivery risk due to misaligned schedules and misunderstood constraints.
- Forces teams into coordination patterns that reduce autonomy and increase context switching.
Organizations with high Dependency Friction often experience declining morale, slower time-to-market, and brittle plans that fall apart when reality diverges from expected sequencing.
Why You Must Measure It Systemically
Dependency Friction is not a local team problem—it is a systems-level condition. Even if individual teams are operating with agility, the surrounding structure may constrain them with structural dependencies—interdependencies that are embedded in the way the organization is designed, funded, or governed.
If leaders focus only on local velocity, team capacity, or individual productivity, they miss the real source of drag. What needs to be visible is how shared dependencies between parts of the organization inhibit overall flow.
That’s why measuring Dependency Friction is critical: it shifts attention from blaming teams to understanding and improving the system.
Creating a Dependency Friction Metric
It’s not clear that there is—or even should be—a universal formula for measuring dependency friction. In my work with clients, we define a custom Dependency Friction Metric by assembling measurable indicators that reflect their unique structure, delivery model, and flow goals.
What I present here is a work in progress. I expect my thinking to evolve as I and my clients continue to discover better ways to measure dependency friction and use that data to make value-added improvements to flow.
How to Use These Indicators
Each of the following indicators can be measured in multiple ways—ranging from simple counts to more advanced time- or effort-based calculations. You don’t need to implement them all at once. Start with what your tools and teams can support, and refine over time. The goal isn’t precision—it’s visibility. These indicators are meant to shine a light on where dependency friction is impeding flow so you can investigate and adapt your system accordingly.
1. Blocked Time Ratio
Measure the percentage of total Flow Time that a work item is in an explicitly blocked state due to a dependency—where work cannot proceed until the dependency is resolved.
This indicator draws a clear line between normal coordination lead time and actual friction that impedes flow. Not all waiting is blocking: if a team plans around a known lead time (e.g., expecting another team to deliver in five days), that’s coordination. But if the dependency fails or arrives late—causing progress to halt—then the work enters a blocked state.
Formula:
Blocked Time Ratio = (Time Work Was Actively Blocked by a Dependency / Total Flow Time) × 100
Why it matters: High blocked time is a signal of failed or delayed coordination. Not all dependencies become blockers—but when they do, they have an outsized impact on flow.
Systemic insight: Tracking blocked time due to dependencies reveals where the delivery system is most sensitive to coordination failure—and where friction is impeding progress.
Systemic connection: Variability in blocked time contributes directly to Flow Time Variability (another indicator defined below). If some items are blocked unpredictably while others are not, the result is a highly inconsistent delivery experience—even for similar types of work.
2. Dependency Density
Count the number of distinct teams, systems, or resources that must coordinate to complete a work item. This number is the dependency density of that work item.
Since different work items have different coordination needs, there is no single system-wide dependency density. Instead, you can summarize the metric across a portfolio or timeframe using:
- Average Dependency Density
- Weighted Average (e.g., by story points or business value)
- Probability Distribution (e.g., % of work items that require 2, 3, 4+ teams)
This allows leaders to ask not “what’s our dependency density?” but rather “how often does our work require cross-team coordination—and how extreme is it when it does?”
Why it matters: More dependencies mean more coordination effort, risk, and time in flow.
Systemic insight: Frequent high-density work patterns suggest deeper structural issues: coupled architecture, cross-cutting responsibilities, or centralized functions that bottleneck delivery.
3. Coordination Load
Coordination Load measures the total time, effort, and distraction caused by the need to coordinate with other teams, systems, or governance layers in order to complete work. This includes both planned and unplanned coordination.
Planned coordination is the known overhead of managing dependencies. For example, if your organization performs scheduled dependency-coordination events (e.g., PI Planning in SAFe), a significant coordination load is baked into your process.
Unplanned coordination is additional—and often more disruptive—friction that comes from unscheduled meetings, clarifications, escalations, or ad hoc decision-making needed to move work forward.
Measurement Options:
- Time Spent in Coordination – Includes both scheduled meetings and unscheduled syncs (as reported or estimated)
- Interrupt Frequency – Track how often teams are pulled into unexpected coordination (e.g., “We needed 3 extra meetings to resolve this integration”)
- Messaging or Comment Volume – Use tool activity as a proxy for coordination density (e.g., Jira comments across teams, Slack pings)
- Survey-Based Perception – Ask teams: “How much coordination effort did this work require?” or “Which dependencies were most burdensome to coordinate?”
Why it matters:
Coordination load consumes time and attention that could otherwise be spent delivering value. Planned coordination may be necessary in complex environments, but unplanned coordination is costly and disruptive. Both represent a form of waste—waste that can often be reduced by decreasing the number or intensity of dependencies in the system. Measuring coordination load reveals just how much effort is being spent not on doing the work, but on managing the interdependencies required to get it done.
Systemic Insight:
High coordination load isn’t a failure of discipline—it’s a signal that the system requires excessive effort to align. It often stems from brittle interfaces, poor separation of concerns, or organizational structures that push complexity onto teams. Instead of asking teams to coordinate better, ask: Why is so much coordination required in the first place?
4. Rework Due to Dependency Misalignment
Rework is an often overlooked effect of Dependency Friction. It occurs when completed work must be revised or redone due to unmet or shifting assumptions across a dependency. Dependencies increase the likelihood that assumptions will diverge, timelines won’t align, or constraints will change midstream. Whether it’s mismatched APIs, late-breaking policy changes, or evolving upstream inputs, the more dependencies in the system, the greater the likelihood that rework will be required to accommodate them.
Measurement Options:
- Rework Count – Number of rework events or reopened work items
- Rework Rate –
- Formula: (Items Reworked Due to Dependencies / Total Completed Items) × 100
- Unit: Percentage
Rework Effort –
- Formula: (Effort Spent on Rework / Total Effort) × 100
- Unit: Hours or Points
Use tags, workflow status changes, linked tasks, or retrospective flags to help teams identify when rework was required due to a dependency problem—not just general revisions.
Why it matters: Rework not only delays delivery and demoralizes teams—it’s often a hidden cost of Dependency Friction that gets normalized or absorbed silently.
Systemic insight: Persistent rework reveals deeper misalignment in shared ownership, interface definitions, or coordination rhythms across teams. If rework is frequently driven by recurring dependency failure, it’s a signal that upstream structural change may be needed.
5. Flow Time Variability
Analyze the variability in Flow Time—the total elapsed time from when a work item is committed (e.g., pulled into active development) to when it is delivered. Focus on similar types of work items, especially those involving different dependency profiles.
Measurement Options:
- Standard Deviation of Flow Time
- Calculate how much variation exists across similar work items.
- Unit: Time (e.g., days)
Flow Time Range or Percentile Spread
- Track the 80th percentile range (e.g., P90 – P10) to understand delivery consistency.
Flow Time Variability by Dependency Profile
- Compare flow time variability for work items with low vs. high dependency density.
Why it matters: High variability in Flow Time reduces predictability, undermines stakeholder confidence, and drives teams to pad plans with buffers.
Systemic insight: Much of the variability isn’t due to team performance—it stems from how dependencies are managed. Teams with similar skills may still deliver inconsistently if their dependencies are unstable or misaligned.
Related signal: Flow Time Variability is often driven by inconsistent dependency coordination. Work items with unexpectedly high blocked time can disproportionately stretch delivery timelines, making it harder to forecast with confidence—even when teams are performing consistently.
6. Perceived Friction (Survey-Based)
Ask teams to rate which dependencies most impacted their ability to deliver. This taps into the human experience of coordination cost.
Measurement Options:
- Friction Score per Dependency (1–5 scale)
- Team Friction Footprint (average across dependencies)
- Trend Analysis and Perception Outliers
Teams know where the pain is—even if tooling doesn’t show it. Use surveys periodically to reveal unseen friction.
Why it matters: Perceived friction reveals what quantitative metrics might miss.
Systemic insight: Persistent high-friction scores map to weak organizational interfaces or ill-defined ownership.
Crafting a Composite Score
These indicators can be weighted and combined into a Dependency Friction Score—not to enforce a universal formula, but to reflect what’s most meaningful and impactful to your organization’s flow. The score becomes a directional signal tailored to your structure, scale, and delivery model.
Options for Combining:
- Normalized Weighted Average – Scale each indicator to a 0–100 range and assign relative weights based on what matters most to your flow goals.
- Friction Index by Area – Aggregate indicators by value stream, product, or delivery area to identify where dependency friction is most experienced.
- Radar or Heat Maps – Visualize friction patterns across teams, departments, or product lines to guide targeted improvements.
The result is a single score that helps leaders visualize where dependency friction is most concentrated—whether by team, product area, or value stream. The goal isn’t to compare team performance, but to highlight systemic hotspots where coordination breakdowns, structural misalignments, or architectural bottlenecks are most likely to impede flow.
Friction should be attributed to the area experiencing the disruption to flow, not necessarily the area causing it. This creates a consistent and objective basis for comparison—highlighting where in the system work is being delayed or reworked the most. Once those hotspots are visible, you can investigate what’s driving the friction—whether it’s upstream teams, brittle architecture, unclear ownership, or something else entirely.
The score doesn’t need to be perfect—it’s a signal. Use it to track changes over time, guide conversations, and shift attention from team-level blame to system-level design opportunities.
From Invisible Drag to Visible Metric
Dependency Friction is real—and it’s systemic. If you’re not tracking it, you’re likely misdiagnosing delivery problems and optimizing the wrong things.
By building a metric that reflects where and how Dependency Friction occurs, you create a critical feedback loop—one that helps your organization evolve toward more resilient, decoupled, and flow-optimized systems.
Reducing Dependency Friction
This article is about seeing the dependency-friction problem so you can measure it meaningfully. This article does not provide solutions to reduce dependencies or improve flow. For that, see:
- Shared Dependencies: The Critical Issue When Adopting Agile at Scale
- The Economic Consequences of Dependencies
- Agile Organizations Must Address Both Structural and Instantiated Dependencies
- Dependencies Are Killing Your Agile Flow at Scale
If you are interested in training on this topic, check out my class focused on how to reduce dependencies and improve flow called:
Dependencies Are Killing Your Agility: Learn to Fight Back!
Or, if you want tailored support, let's start a conversation!