Let’s be real: dependency management isn’t progress – it’s maintenance of dysfunction. In this article, I unpack why these fancy PI planning boards might be making things worse, and how to actually design for flow instead.

Stop Managing Dependencies. Start Eliminating Them.

Let’s start with a blunt truth:
Managing dependencies is a trap.

(Yes, I’m looking at you, PI Planning boards with your red strings and sticky-note spiderwebs. 🔍)

These boards don’t make your organization agile.
They just make your dysfunction visible.

And instead of fixing the dysfunction, most companies double down and start optimizing it. As if better coordination of handcuffs makes them any less binding.

Dependency management is just a fancy way to polish the handcuffs that are slowing you down.

The Real Problem Isn’t the Dependencies

It’s that we’ve normalized them.

• A frontend team that can’t ship until backend finishes their part.
• A team stuck because QA is a separate department.
• A release blocked because Bob from infrastructure is on holiday.

These are not laws of physics. They are design flaws.

And yet, whole frameworks and roles have emerged to “manage” them.

It’s like building a house with holes in the roof and then hiring a full-time person to hold an umbrella over your bed.
(And when they’re out sick, we hold a “cross-team coordination” meeting.)

Let’s stop the madness.

Dependencies Are a Symptom

They are a signal that your org is not structured around the flow of value.

They usually come from:

• Functional silos (“QA does the testing”, “Backend does the APIs”)
• Overspecialization (every dev is a one-trick pony)
• Hero dependencies (Bob is the only one who knows how to deploy)

So what do we do instead?

The 3-Step Dependency Algorithm

Here is a better way to deal with dependencies.

1. Eliminate

Most dependencies are homemade. Unmake them.

• Cross-functional teams that can ship value end-to-end.
• Platform teams that enable autonomy, not gatekeeping.
• Small batches so you don’t coordinate 27 teams at once.

If you only take one thing from this article, take this:
Stop normalizing structural blockers. Start designing for flow.

2. Mitigate

Can’t eliminate it today? Fine. Make it hurt less.

• T-shaped skills reduce handoffs.
• Communities of practice reduce the “only one person knows this” trap.
• Shared language and domain understanding reduces the coordination tax.

Most “dependencies” dissolve when teams understand just enough of each other’s world.

3. Manage (as a last resort)

Okay, fine. Some things do require coordination.

But don’t create an empire of ticket routing and dependency wranglers.
Do it peer-to-peer.

• Let teams talk directly.
• Kill the middlemen.
• Use lightweight protocols, not heavyweight process.

Dependency management should be a last resort, not a lifestyle.

A Final Word for the Dependency Managers

I’m not saying you’re not doing important work.

I’m saying the system has set you up to manage a problem it created—
instead of empowering you to fix it at the root.

And honestly? I want you to be out of a job.

Because in an org designed for flow, you’re not needed as a translator between misaligned teams.
You’re needed as a systems thinker, a coach, a flow optimizer.

Don’t be the person who builds better band-aids.
Be the one who stops the bleeding.

---

Want to help your org stop managing dysfunction and start designing for agility?
Check out Agile Coach Evolution – a program for coaches ready to lead real transformation.

---

FAQ

What is dependency management in agile?
Dependency management refers to identifying, tracking, and coordinating work that requires input or completion from other teams or systems. While necessary in some cases, excessive dependency management indicates poor organizational design.

Why are dependencies bad?
Dependencies slow down delivery, introduce bottlenecks, and increase coordination overhead. They often signal siloed teams, specialization without cross-training, or unclear ownership of value streams.

Should we eliminate all dependencies?
Not always, but most dependencies are not inevitable—they’re results of conscious (or lazy) design decisions. Aim to eliminate as many as possible by reorganizing teams and improving skills. Manage the rest with lightweight coordination.

What are T-shaped skills and how do they help?
T-shaped professionals have deep expertise in one area (the vertical bar of the T) and enough breadth across others to collaborate effectively. They reduce handoffs and help teams self-serve more of what they need to deliver value.

Are platform teams a good way to reduce dependencies?
Yes—if they focus on enabling others rather than acting as gatekeepers. Great platform teams offer APIs, tooling, and shared services that empower product teams to move independently.

---

Read on the blog →