Whose dependency is it anyway?
This relationship is ‘complicated’
If you’ve ever worked in an organisation with more than one delivery team, chances are you’ve had to manage a dependency or two at some point in your career.
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 maybe even completely different success criteria that prevents you from even opening a dialog in the first place.
Let’s explore a few different methods that can be applied to tackle the problem of dependency management, and assess the pros and cons for each.
First, start by analysing your system of dependencies
Before we start creating solutions, we must first seek to understand the problems. Here we’ve used the Dependency Mapper for Jira app to visualise all existing dependencies between teams.
Using this information we 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 picture?
It can also help inform a strategy for resolving these issues; could it be better to try and fix the problem ourselves? Do we maybe need to create some kind of contract or agreement to resolve multiple dependencies? The approach depends on what insights you derive from your analysis.
The DIY approach - Resolve the dependency yourself
The first instinct a team may have is to both own and resolve the dependency yourself, after all if you’re consuming an asset or service then surely you have the right to contribute to it also right?
Unfortunately despite having good intentions, this approach can be frought with issues including, but 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 said other team prioritise the dependency in their own backlog
- Conflict of Practice - Similarly, 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 rhythym (e.g. Scrum vs. Waterfall), deployment method (DevOps vs. non-DevOps), or even expectactions around maintenance and aftercare that could arise further complications
- Conflict of Ownership - Leaning more towards the cultural side of many organisations, 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 diplomatic approach - Create a contract between teams
A more tactical approach, especially in scaled organisations, may be to focus on striking up a trusted working relationship with the team/s you have the most dependencies on in order to resolve your issues in a timely manner.
Quite 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 scenario that ends in a mutual benefit to both teams then this can create further opportunities later in time with regards to cross-skilling and knowledge-sharing.
However, if a mutually scenario can’t be identified not all is lost. In some cases it can be possible to sit down with your dependant teams and create a type of ‘contract’ (similar to a social contract in the Agile world) that lays out the terms and conditions of the services provided by the responding team. This 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 prioritised by the dependent party
Re-organise around value streams - The system approach
Last, and perhaps most difficult but rewarding, is the option of exploring opportunities to re-organise the structure of all teams within the system to deliver a fully realised value stream of work.
Despite the fact that eliminating all cross-team dependencies within a scaled organisation is practically impossible, there are quite often many opportunities to optimise teams away from ‘horizontal’ or ‘component’-owned assets and services and more towards ‘vertical’ end-to-end delivery mechanisms.
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) and towards Objectives and Key Results (OKRs).
Conclusion
In closing, 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 depending on the context of your work may yield positive or negative results. Ultimately these conversations should lend themselves towards delivering frequent customer value, not just managing process.
How have you managed your dependencies in your organisation? I’d love to hear more about how your team currently operates! Feel free to contact me to start a discussion!
Want to enhance your agile reporting?
Are you a Jira user? Check out these apps that focus on themes like dependency management, scaled backlog views and WIP management to help your teams navigate and understand their complex environments!
Check out my Dependency Mapper app for Jira!