Why You Have Dependencies, and How to Resolve Them

scaled-agile
Posted by Kunal

20 November 2015

In a world without cross-team dependencies, projects would exist in isolation, wouldn’t need help from an internal teams or outside vendors, wouldn’t be affected by business changes, and requirements would remain constant. If this were true, program managers would have a much easier life.

In reality, this isn’t true. PMs spend a lot time and energy dealing with complex dependencies. In this post, we’ll try to reduce that time by covering how to predict dependencies, tactics to reduce their impact, how to resolve them, and what features PMs should look for in a dependency management tool.

Why do cross-team dependencies matter?

We interviewed over ten program managers who lead a sizable number of teams in their organizations aiming to find out the top reasons programs fail. 80% of them included “dependency management” as important job at a high level to make the program successful. Missed or incomplete understanding of dependencies across teams and third parties is an important one. At the same time, dependencies also matter at team level. Dependencies may hurt agile team’s accountability of getting things done at the end of the sprint or iteration.

Why are dependencies hard to resolve?

The heterogeneity of teams

Teams are structured differently and many times follow different project management methods and principles. Unfortunately, what works for one team does not always work for others. And when separate teams follow their own highly proscribed schedules and cadences, it is more difficult and time-consuming for them to work together. Even in a framework where the teams spend a few days in advance of an iteration trying to talk through dependencies, they will end up spending a lot of time managing day-to-day work. Prescribed schedules, especially if there’s more than one at work, often result in managers spending more time in meetings to figure out process and scheduling, and less working on getting features released.

On the other hand, if teams are completely working asynchronously and autonomously, prioritization becomes a challenge. When it comes to dependencies across projects or programs, teams may be at different levels of completion. For example, let’s say that Team A raises a dependency on Team B. Team B (the resolving team) doesn’t need Team A’s information or input, but Team A cannot finish its work until it gets the data from Team B’s project. So Team A is hoping that their deadline is after Team B’s, not before. Additionally, teams are limited by their own unique priorities: they’re following their own mandates and tracking toward their own milestones, which certainly are high-priority for them.

Lack of end to end visibility

Traditionally, program managers have tried to identify dependencies beforehand. But no matter how hard they try, with software projects there’s always something that’s missed. Due to the ever-changing nature of software products, the majority of dependencies are identified during implementation. For program managers to effectively facilitate cross-team problem solving, the real challenge here is how to get real end-to-end visibility. This visibility should be not only for an individual project, but also across projects and across different roles so that all can help in prioritizing, scheduling, tracking and resolution of the dependencies.

How can dependencies be resolved?

As with any problem, keeping it from happening in the first place is ideal but not always possible. For dependencies, having self-sufficient teams or ensuring dependencies can be resolved within the team can be preventative measures, depending on the project. But if that’s not possible, teams should try and identify dependencies as soon as they can. Preferably, they will have the ability to raise dependencies across teams using a common mechanism which works to facilitate end-to-end visibility irrespective of individual team structures or the underlying methodologies used. While this is easier said than done, following are some best practices people have used to try and manage dependencies.

Minimise dependencies

The best way to resolve dependencies is not to have them! You can leverage some principles to minimize the cross-team dependencies, but you cannot avoid them completely. As Agile expert Mike Cottmeyer pointed out in a 2015 blog post, there are at least three ways to reduce the impact of the dependencies that do crop up.

Peer-to-peer collaboration between teams

While time-consuming, this is the best way to resolve dependencies. Project or program managers should build a cadence in which they meet all the project managers involved in their program. The structure of this meeting should be to talk about all the dependencies that are in progress, confirm that the dependencies they are working on are still priority, prioritize or re-prioritize new dependencies, and check how dependencies are adhering to the organization goals. This will also be a good time for every manager in the program to understand the amount of work the other teams have and then help each other out with resources or scope changes.

Full-stack feature teams

An easy way of removing dependencies is for “the team” to be made up of people with all the skills needed to complete the work needed. We often call these “full-stack” or “feature teams”. Teams that are building a product feature end-to-end reduce dependencies on external teams and individuals. They move quickly, add more value, and they reduce dependencies. If you can’t quite get to long-lived cross-functional feature teams, one very effective way to resolve dependencies is to have a person from the team on which you are most dependent “injected” into your team as a resource. This is often true for infrastructure, design and support teams but can be used in teams where one team is regularly dependent on another.

A visual representation of the product feature backlog

This technique requires all the product managers to provide a visual representation of their particular product feature backlog. Once that is done, the component project teams should only commit to in the following, in order of priority:

For special situations when something needs to be done outside these three cases, a special team of experts should be formed and tasked with completing it.

Get support from a tool

While all these are preventive ways to manage dependencies it may be helpful to find a software management tool with features that can help expose and resolve dependencies. For instance, some helpful features could be::

Conclusion

Although dependencies may be difficult to manage, they’re also inherent to larger, agile organizations with cross-functional teams. So if you look at it that way, in organisations where cross-team dependencies exist, having dependencies can be an indication that you don’t have silos and teams really are collaborating. The relationships between teams will dictate, to some extent, how well dependencies are resolved. So the more you can empower the teams, the more effectively teams can manage themselves. That said, it’s always best to anticipate dependencies when you can, and more importantly, see how dependencies may affect the delivery time and serving of business goals.


comments powered by Disqus