Don’t Manage Dependencies – Eliminate Them!

When it comes to dependencies, most teams and managers immediately ask, “How do we manage these dependencies?” But are we asking the right question?

What’s a Dependency?

A dependency occurs when one person or team relies on another part of the company to complete their work. This could mean waiting for a component from another team, needing support, or relying on another’s expertise.

Dependencies aren’t inherently good or bad. Relying on others can be positive! It’s about teamwork. But when dependencies pile up, they can slow us down and complicate things. So, we need to handle them efficiently.

Types of Dependencies

We can distinguish between two kinds:

• Structural dependencies
• Instances of dependencies

A structural dependency, for example, might be a frontend team relying on a backend team. An instance of this could be the frontend waiting for an API endpoint from the backend for a specific feature like a shopping cart.

Each structural dependency has countless instances, which we often see in our daily work. The structural dependencies are the root cause of these instances.

Now, let’s tackle how to handle these dependencies!

Eliminate, Don’t Manage

Many clients ask, “How can we manage our dependencies?” But that’s the wrong question!

Managing should be the last resort. First, we must eliminate dependencies whenever possible.

As a coach, scrum master, or leader, observe how your organization tackles dependencies. Often, I see dependency boards popping up (like in SAFe PI Planning). Visualizing dependencies is great, but we can’t stop there.

Just because we’ve listed a dependency doesn’t mean we’re done. The first question should be: “How can we eliminate these dependencies?”

How to Handle Dependencies

Let’s find a better approach.

Most dependencies I encounter are homemade. The organization created these structural dependencies, and thus, the organization can remove them!

Some dependencies might be necessary, and removing one may create another. In such cases, it’s crucial to choose the right ones to maintain the best balance.

Of course, some dependencies are inherent to the domain due to complexity. These cannot be eliminated.

While all dependencies manifest in specific tasks, let’s focus on structural ones.

The Dependency Algorithm

Here’s a general algorithm to handle structural dependencies:

1. Eliminate: Try hard to eliminate the dependency.
2. Mitigate: Consider the impact of dependency A vs. B. Sometimes removing A may create B, but it might be worth it if B has less negative impact.
3. Manage: What remains must be managed.

1. Eliminate

Organizations often create dependencies through their structure and processes. For instance, having separate development and test teams creates a structural dependency. Since value flows through both teams, they must rely on each other.

Many dependencies can be eliminated by reorganizing around value streams!

For example, forming a cross-functional team with developers and testers allows for direct collaboration. They attend the same Sprint planning, communicate daily, and work on features together.

Reorganization isn’t always straightforward, but don’t give up! You don’t always have to change the org chart. People can work across boundaries if encouraged and allowed.

In my experience, at least half of structural dependencies can be eliminated! Just don’t skip this crucial step.

2. Mitigate

If eliminating isn’t possible, mitigate the impact.

A T-shaped skill set can help. When team members extend beyond one area of expertise, they can prevent dependencies from becoming blockers.

For instance, if a team developing a new song UI in a music app needs to integrate with the search functionality but the search team is busy, a developer might handle basic integration themselves. This avoids being blocked and allows the search team to help later.

Also, consider communication patterns. If teams are organized around specific features (like “song UI” and “search”), you might not eliminate all dependencies, but you reduce them. Instead of daily discussions between frontend and backend, it might be occasional among backend developers in a community of practice.

In short:

• Daily communication? Keep them in the same team.
• Weekly communication? Use a larger construct like a CoP.
• Occasional communication? Keep them further apart.

Organize around value streams to eliminate or mitigate dependencies.

3. Manage

By now, we should have tackled most dependencies. Now, it’s time to manage the remaining ones.

Here’s a crucial tip: don’t appoint a dependency manager. Instead, make it easy for teams to manage dependencies peer-to-peer. This agile approach has proven effective over the years.

Encourage teams to talk directly whenever they depend on each other. Don’t let them just report dependencies and wait.

Improve transparency. The more your team knows about others’ work, the easier it is to spot dependencies and address them. Understanding other teams’ goals helps align with the overall objective.

There are many agile techniques for this, but that’s for another article.

Conclusion

Before you jump into managing dependencies, try hard to eliminate them! Organize around value streams and communication patterns, cultivate T-shaped skill sets, and encourage direct collaboration.

There’s so much more to discuss about decoupling and eliminating dependencies. If you’re interested, check out my ACE program. And if you’re not quite ready for that, I’m developing a course specifically on handling dependencies in agile contexts. Interested? Reply or drop a comment, and I’ll keep you updated!