Agile Teams: Dependency Management and Visualization

No project is managed in a vacuum. Within a single project, dependencies occur – between people, steps, functions, or teams. In any situation where one thing must happen before another, a dependency exists:

• A piece of work must be reviewed before it can be delivered
• An article must be written before it can be edited
• A feature must go through QA before it can be released
• A blood sample must be taken before it can be analyzed

All these relationships between tasks are dependencies. Dependencies can be internal or external to the Agile teams or organizations doing the work.

Although in many contexts, the word “dependency” has a negative connotation – a dependency on an illicit substance, for example, is seen as unhealthy and damaging to the person with that dependency – dependencies in work processes are a neutral force. They’re neither inherently good nor bad, and in most cases they’re inevitable.

It’s the sequencing of tasks, work, steps, or processes that make dependencies manageable by Agile teams. Identifying dependencies and visualizing them allows everyone involved to better align and prioritize their portion of the work to optimize flow.

Agile teams often include dependencies in processes to reduce risk, such as when one person writes an article and another edits it, or one team member develops a feature and another tests it. There’s inherent risk in having one person responsible for both the “doing” and the “checking” in any process, so teams build dependencies into processes to mitigate that risk.

One thing all dependencies have in common is that they increase complexity in any system. And with more complexity often comes more waste. Passing work between people, or between teams, unless those people or teams are perfectly coordinated, usually involves some idle time (read: waste). Many Agile teams aim to reduce work in process in order to decrease idle time, but at the risk of creating a different form of waste: non-utilized talent.

A natural question to ask is, “Should dependencies exist at all?” If dependencies reduce agility, shouldn’t Agile organizations do away with them entirely?

Conceptually, yes – the ideal Agile organization would be organized into completely self-sufficient, self-sustaining, cross-functional Agile teams. These teams would be able to consistently deliver value from start to finish without any external dependencies. However, this isn’t realistic.

There is value to be gained from collaborating with other teams, functions, and individuals within the organization; most projects, even those most Agile in design, include some dependencies, within the team itself at the very least.

In addition to these types of process dependencies, there are also systemic dependencies, such as technical dependencies, which we’ll discuss later.

This doesn’t mean that all dependencies are created equal, or that they are inevitable, and Agile teams simply must work around them. Some dependencies are the result of poor or overly complex organizational design, and teams should work to eliminate them entirely. But others are essential for effective collaboration, risk management, or technical reasons. Ultimately, Agile teams need checks and balances (dependencies) to ensure they put forth the best possible solution.

So, the goal of any Agile organization isn’t to completely eliminate all dependencies, but to:

• Organize into cross-functional Agile teams, effectively “designing out” unnecessary dependencies
• Use dependency mapping to gain a better understanding of the dependencies between systems, processes, and teams
• Practice continuous improvement to eliminate unnecessary dependencies
• Analyze necessary dependencies to predict how they will affect deliverability
• Create better systems for dependency management that mitigate the disruption they cause

Dependency management is the process of recognizing, anticipating, and managing dependencies between tasks, people, processes, and systems. Effective dependency management helps to reduce process variability and increase predictability.

What exactly does dependency management involve? In its most basic form, it includes:

• Identifying relationships between work items
• Recognizing dependent activities
• Visualizing those dependencies
• Dependency mapping: Creating a living, detailed documentation of dependencies between systems, resources, and processes
• Leveraging the right technologies to build dependency management into workflow planning and execution

In any work process, there are several types of dependencies. To practice effective dependency management, it’s helpful to distinguish between them.

There are several factors Agile teams can use to categorize dependencies:

• whether internal or external
• whether mandatory or discretionary
• the nature of the dependencies

We’ll use examples from building a house to illustrate each of these factors.

Internal vs. External Dependencies

Mandatory vs. Discretionary Dependencies

Dependency Function

The type of dependency will impact how Agile teams visualize, map out, or otherwise handle it. The reason for the dependency is also important to know, because it can affect how the dependency is managed.

Reason for Dependency

Visualizing dependencies is the first step to practicing dependency management: Agile teams must understand where dependencies exist in order to manage them. Doing this consistently can help teams more effectively prevent upstream bottlenecks and avoid unintended consequences downstream.

Dependency mapping and visualization helps Agile teams understand:

• How work relates and correlates between teams and teams of teams (Agile Release Trains, or ARTs)
• Where dependencies exist
• Where patterns of dependencies exist

Dependency Mapping and Kanban

Agile teams already practicing Kanban may already be doing some dependency mapping, or at least dependency visualization: Some Kanban tools allow teams to build parent-child relationships between cards, for example, to visualize related work on the same board or distributed across several boards.

If their Kanban tool allows them to visualize relationships between tasks by connecting cards, Agile teams can use those connections to create a map of all the dependencies that exist on a single board.

In LeanKit, for example, Agile teams can use the Connections Map to see how cards on the board are related. This type of dependency mapping is sometimes called a “red string visualization,” because on physical Kanban boards, red string is often used to visualize these relationships.

In addition to connecting related cards, there are other ways to help teams visualize and communicate about how dependencies might impact delivery on a Kanban board.

For example, card icons can be used to reflect external dependencies. A “blocked” icon can show that a card cannot move forward due to an external dependency. If their Kanban tool allows Agile teams to provide a reason for why the card is blocked, this feature can help teams quickly communicate about external dependencies.

If certain types of work require a specific expertise that only one person on the team possesses, assigning cards to that person will help the team understand that person’s capacity. If the team member has several cards in their queue, the team can factor this into the timeline for new cards that are added to the board.

Many Agile teams use card assignments to designate only the “owner” of the work, which paints an incomplete picture of where people are spending their time. Assigning everyone involved in a piece of work to the card can help teams gain a more accurate understanding of capacity, which can also be helpful in increasing predictability.

Delivering more predictability is a goal of any Agile organization, and it cannot be achieved without a better way for identifying, visualizing, and managing dependencies.

Although dependencies are inherently anti-Agile in theory, it isn’t realistic to try to eliminate them completely. Some dependencies are necessary for effective collaboration, risk management, and technical reasons.

In the quest to become more Agile (both in the lowercase and uppercase definitions of the word), the goal of Agile teams shouldn’t be to eliminate dependencies entirely, but to reduce complexity, improve flow, and increase their ability to predict how dependencies will impact their ability to deliver work.

Visualizing connections between related work, and taking the time to assess the impact these dependencies will have, is critical for helping teams unlock greater levels of agility, by:

• Improving work sequencing to prevent roadblocks and reduce process waste
• Improving the flow of work, reducing context switching at every level
• Helping teams set more realistic expectations with internal and external stakeholders
• Reducing process variability, therefore increasing predictability
• Practicing more effective capacity planning and prioritization within, between, and across teams
• Improving cycle and lead times

Dependency management doesn’t have to start as an organization-wide initiative. It can begin with a single team committing to actively identifying and managing dependencies and grow from there. It’s an organizational competency like any other; the more Agile teams do it, the more skilled they become.