3 approaches to dependency management – which one is best for you?

Ever been a scrum master, product owner, or project manager working in an organization with more than one delivery team? Chances are you’ve had to tackle dependency management at some point.

You’ve also felt the frustration of trying to resolve that dependency, especially when the other team has conflicting priorities. They might have a critical release coming up, a shortfall of capacity, or completely different success criteria that prevents you from even opening a dialogue in the first place.

In this article we’ll explore three approaches to dependency management that could help ease that frustration. And we’ll assess the pros and cons for each.

Smart dependency management starts with a system analysis

Before we look at solutions, we first need to understand the problem.

If you work in Jira, you can create dependencies by linking issues. Different link types such as “blocks”, “is blocked by”, and “relates to” help to accurately represent the nature of each dependency.

However, in standard Jira there’s no way of tracking or managing them. In Jira Premium, there is, but the dependency views are basic and limited.

So we’ve used the Atlassian Marketplace add-on, Dependency Mapper for Jira, to visualize the existing dependencies between all our Jira teams.

What you can see in the image above is a draggable, zoomable view of all recorded dependencies arranged in a circle and grouped together in colored arcs which represent each project. If you click on an individual dependency, the issue will open in a new tab so you can investigate it further. Alternatively, click on a colored arc and you’ll bring up all issues with dependencies within that project.

Using this information you can not only identify where clusters of dependencies lie, but also which teams share common sets of dependencies. What insights can you derive from the above chart?

Your analysis can also help inform a strategy for resolving dependencies. Let’s look at the three possible approaches you could take when defining that strategy.

The DIY approach to dependency management

The first instinct a team may have is to both own and resolve the dependency themselves, e.g. with a simple spreadsheet. After all, if you’re consuming an asset or service then surely you have the right to contribute to it, right?

The DIY approach is good for helping teams understand their system of work. It also helps build relationships between teams by forcing conversations between them, increasing trust. Importantly, teams get an understanding of the cost of dependency management and how much can be gained from optimizing the process with an automated solution like Dependency Mapper for Jira.

However, while this approach is good-intentioned, it can be fraught with difficulties. These include but are not limited to:

• Conflict of expertise – Depending on the nature of work you may disrupt the flow of work for the other team by introducing quality issues in their space. This could cause potential conflict and debate that would cost more in the long run, as opposed to letting the other team prioritise the dependency in their own backlog.

• Conflict of practice – The service or asset owned by the other team may be run in an entirely different way to what your team does. This could be a difference in operating rhythm (e.g. scrum vs waterfall), deployment method (DevOps vs. non-DevOps), or even expectations around maintenance and aftercare.

• Conflict of ownership – Leaning more towards the cultural side of many organizations, there could be a preconceived notion that any attempts to adjust another team’s asset or service could be deemed invasive. This could further complicate the trust and relationship built up to this point.

The DIY approach is manageable only when you have a handful of dependencies. When you add in more dependencies and more teams, the complexity increases exponentially and different approaches need to be explored.

The diplomatic approach to dependency management

A grouped dependencies chart in Dependency Mapper for Jira, with each bar showing all the dependencies raised and received between two teams

A more tactical approach, especially in scaled organizations, may be to focus on striking up a trusted working relationship with the team/s you have the most dependencies on. That way you can work together to resolve your dependencies in a timely manner.

Often teams start with this approach in mind, but forget to consider the other side of the equation. By requesting something from the other team, what’s in it for them? If you can find a mutual benefit for both teams, this can create further opportunities later with regards to cross-skilling and knowledge-sharing.

However, if a mutually beneficial scenario can’t be identified, all is not lost. In some cases it can be possible to sit down with your dependent teams and create a type of ‘contract’. Similar to a social contract in the agile world, this would lay out the terms and conditions of the services provided by the responding team.

The contract could include:

• a service-level expectation (SLE) of when the team can expect the dependency to be resolved

• an agreement on how both teams can communicate with each other, namely the medium (e.g. email, Slack) and the operating hours

• a clause that dictates how often requests are prioritized by the dependent party

The systemic approach to dependency management 

 

A dependency board in Dependency Mapper for Jira; this is a digital version of the board generated as part of a Program Increment (PI) planning event and shows dependencies between Jira issues sorted by project and date

The third approach is the most difficult, but also the most rewarding: finding a way to reorganize the structure of all teams within the system to deliver a fully realized value stream of work.

We acknowledge that eliminating all cross-team dependencies within a scaled organization is practically impossible. However, there are usually many opportunities to optimize teams away from ‘horizontal’ or ‘component’-owned assets and services and towards ‘vertical’ end-to-end delivery mechanisms.

Our best advice would be to establish a team-of-teams organizational design aligned with the Team Topologies model. This model has four fundamental kinds of teams:

• stream-aligned teams dedicated to building and delivering customer value quickly and independently

• enabling teams who help stream-aligned teams to overcome obstacles and look for missing capabilities

• complicated subsystem teams who have significant necessary technical/mathematical expertise

• platform teams who provide a compelling internal product to accelerate delivery by stream-aligned teams

There are only three ways in which these teams should interact according to the model:

1. Collaboration: two or more teams work together over a defined period to discover new things

2. X-as-a-service: one team provides something as a service, which another team consumes

3. Facilitation: one team mentors and supports another team

Aligning teams towards collaboration and delivery of real customer value can also have effects on workplace culture, enabling discussions around shifting from key performance indicators (KPIs) towards objectives and key results (OKRs).

To summarise (TL;DR)

• Dependency management is a critical skill for any scrum master, product owner, or project manager to master.

• There are various techniques to address dependencies, and which, depending on the context of your work, may yield positive or negative results. 

• Unless you have a small handful of dependencies to manage, trying to perform dependency management in isolation may overwhelm your team.

• If you share multiple dependencies with a team, it may be beneficial to strike a deal with them to make your dependency management efforts easier.

• Aligning work around value streams can yield benefits beyond the systemic elimination of dependencies.

• Ultimately these conversations should lend themselves towards delivering customer value more frequently and consistently. It’s not just about managing a process.

• If you work in Jira and you’re involved in dependency management, then you might want to consider Dependency Mapper for Jira. This Atlassian Marketplace add-on visualizes the relationships between tasks, stories, epics, and projects in Jira in a detailed or bird’s eye view across various visual models. You can use it to quickly identify critical paths, bottlenecks, and potential risks to make faster and better decisions. Ultimately it improves relationships between teams as well as the speed and consistency of your project delivery.

If you want to be in full control of all your project dependencies, try Dependency Mapper for Jira free for a month. 

And if you have any questions about how best to approach dependencies in your organisation, we’d love to hear from you.