Dependency Map Analysis

If you’re not up to speed on the concept of dependency mapping, then I’d suggest taking a look at my previous post where I talked through how to go about building a dependency map.

So what happens now? You’ve gone through the workshop and now have a bunch of data that’s telling you what? Something about your system? I’m going to run through some of the actions I take when attempting to understand a dependency map.

Assess the aggregate dependencies

Our first step is to get a clearer aggregate picture of the data so we can assess each team against the others.

We do this by counting the inbound and outbound dependencies for each team and then tallying them. For our simple example above, the output would be a table like the one below. I’ve previously described inbound and outbound dependencies here.

We can now apply some sort of order. When we come to begin resolving dependencies, we want to maximise the complexity we can eliminate while being careful to minimise disruption. A tough ask, but one we can work towards if we remember to maximise outbound and minimise inbound.

Categorise each team from your dependency map

Looking at the above table, we can see that the range is 3 for inbound and 4 for outbound. This then provides a midpoint of 2 for each.

We’re going to categorise each team into a 2×2 matrix depending on their count of inbound and outbound dependencies. We’ll use the mid-point as an inclusive boundary. Anything higher than the midpoint will be in the appropriate high category.

Apply the appropriate strategy

For each category in your dependency map, there is an appropriate strategy to be applied. It’s worth remembering that this is just a guide, there is likely to be an enormous amount of context that isn’t shown here.

High Inbound / Low Outbound

Think networking, these are teams that everyone needs something from, but rarely need to go outside their own team to get something done. If you’re familiar with team topologies, these are classic platform teams. Teams in this situation may find it incredibly difficult to manage their work effectively as they often don’t fully understand how much of a dependency they are on others. They may often find themselves constantly juggling priorities instead of doing value work.

WIP limits cannot safely be applied here without crippling the estate.

The goal here is to help these teams produce self-service tooling and high-quality documentation to minimise the volume of dependencies. It’s likely that these teams have specialist knowledge that doesn’t make sense building in every team. Track the incoming requests in order to look for patterns that show where we should be targeting our efforts.

High Inbound / High Outbound

This one is simple, don’t touch. Yet. While it may be tempting to starting isolating dependencies within your most tangled team, you’ll likely end up crippling another part of the system should you do so.

The impact of this type of team is often felt across the entire estate and requires a significant coordination cost.

We don’t have one in our example but imagine if we had a team called ‘Spaghetti’, which had 5 inbound and 6 outbound dependencies. We like the look of removing some complexity and start to apply practices to isolate that team. While they may now love their additional capacity or skills, the teams which were previously dependent have now become orphaned.

For these teams, we will look to help alleviate their tangled nature by removing complexity from around them first. Work with them to apply good Agile and Lean practices in order to maximise their internal efficiency.

Don’t apply WIP limits here as it will have a similar effect to isolating the team, instead look to apply WIP limits at the boundaries.

Low Inbound / Low Outbound

These teams are generally pretty independent to start with. They should be able to demonstrate good predictability, so applying WIP limits to help manage flow would be a great step. These teams may already be benefitting from Agile and Lean practices.

Look for opportunities to help these teams become the vanguard of change. It is also worth assessing their service to see if they could offer more to customers.

Low Inbound / High Outbound

This is what we’re looking for, teams that we can begin to ring-fence without crippling the surrounding estate. These are teams that often need external expertise, but would not impact the wider business if we started to help them build capability internally.

The key things to look for here are the reasons why.

• Are they lacking the skills required to execute on their work?
• Do they need access to specific people outside the team?
• Is there a technology or policy preventing them from becoming more autonomous?

These are the teams to begin working with as we reduce complexity while building capability.

I ran this in a large financial enterprise and we demonstrated that by isolating a single team from amongst the 30 or so that were present, we could actually reduce overall complexity by a massive 28% across the whole of IT.

Conclusion

For now, this is where my series on building a dependency map will end. We’ve introduced the concept and some new terminology, built one, and then performed some initial analysis.

It is my hope that you are now able to start looking at your system in a new way, pursuing evolutionary change through the reduction of complexity.

I have now run this program in a wide variety of organisations and have seen astonishing results during and after my time there.

If you have any questions, then please get in touch on the right. And if you end up running this, definitely let me know. I’d love to hear how it went.

I work at DevOpsGroup, helping our clients solve complex problems relating to Agile, Lean, culture, organisational design and data-driven business.