Part 2: Dependencies kill flow

The number of internal dependencies determines the maximum speed of an organization. If one team is late or slow to respond, other teams will suffer, too, and the problem can spread to everyone in a domino effect.

If a group of collaborating teams has dependencies, the result can’t be produced sooner than the slowest team within the group. This is a fragile situation because any team can run into trouble for whatever reason and trigger a delay.

 

A dependency means that one team delivers something (code, knowledge, services) that the other needs. An exchange like that requires some form of synchronization between the two, and synchronization (almost) always means that one party has to wait for the other, making one of them slower than it would have been otherwise.

Are dependencies bad? Should we remove all of them? No!

Some dependencies are necessary. Without them, applications and workflows wouldn’t function properly. For example, a mobile app often has to exchange information with a server backend. Any information exchange leads to a (usually desired) dependency. Another example is a workflow dependency, like the dependency between a bank and its customers. To deposit and withdraw money from an account, there has to be a value and information exchange between the customer and the bank, hence a dependency.

These were two examples of desirable, valuable dependencies. What we don’t want are dependencies that cause us grief.

Four types of dependencies

Before we figure out how to find the harmful dependencies, we should look at the different types of dependencies. I like to boil them down to four different categories:

• Missing skills or knowledge
• Not having the mandate
• Architectural and technical
• Process and Scheduling

Missing skills or knowledge is one of the most common reasons for inter-team dependencies:

Here, teams should strive to become even more cross-functional and adopt skills and knowledge from others until they can solve their problems independently. It’s perfectly fine to ask for help, but that should not always happen for the same things. If you need the skills and knowledge, solve it through training or recruiting to the team.

Not having the mandate is often coupled with the missing skills or knowledge, but not always.

Often, teams are responsible for a piece of code that nobody outside the team can modify independently. Collective code ownership isn’t possible because other teams are not trusted to have the skills and knowledge to make safe changes in code created by the originating team.

Resolving the reason for the lack of mandate to make the necessary changes or operations is the way to remedy this situation. It could be a trust issue, a process issue, a knowledge issue, or something else. Base your organization on trust, transparency, and competence.

Architectural and technical reasons for dependencies are perhaps the first thing we engineers think of when talking about dependencies:

Problematic dependencies are often well-known and understood, but fixing them is another story. Fixing technical dependencies sometimes involves changing the application’s fundamental structures, and postponing such changes is too easy.

When refactoring an architecture (yes, you have to do it bit by bit), focus on creating a structure optimized for high development speed, modifiability, and the fact that multiple teams will work in parallel in the same code base.

Dependencies on Process and Scheduling often cause delays where teams are not allowed to move on:

There is a lot that can be done in this area. Wasted time is often not visible because things are left lying around waiting for some condition to be fulfilled. Follow the flow of your deliveries and identify waiting times. Ask yourself, “Can we make this move along quicker?”

Identify and fix the harmful ones

Let every team in your organization create a dependency map to identify painful dependencies. Only those require attention. Dependencies a team doesn’t find troublesome don’t have to be fixed immediately.

A dependency map is created as follows:

1. Put your team in the center
2. Identify your external collaborators
   • Other teams
   • Receivers of our work
   • Customers & Users
   • Stakeholders
3. Rate each relation
   • Use a smiley
4. Work on improving the sad ones
   • Talk to them
   • Show your dependency map
   • Address the underlying reason that makes the dependency painful.

It’s essential to let the teams work on their most painful dependencies themselves, and it’s equally important that they have the backing and support from leadership when doing it. If management doesn’t support their teams in improving their most painful dependencies, they are not doing their job.

This bottom-up approach creates engagement and promises to address dependencies that matter to each team.

Is it a local optimization? Possibly, but that hasn’t proven to be an issue in my experience. What’s more important is starting to improve the situation. In one organization, several teams pointed to the same dependency as particularly problematic. With this knowledge, the problem could be addressed on an organizational level. 

Now, go and make some dependency maps with your teams 🙂

---

This is the second part of a blog series about speeding up your organization. Previously published parts are:

• Intro, Blog Series: What makes your organization slow and how to fix it
• Part 1: Don’t start at the wrong end