Agile Teams: Dependency Management and Visualization

Dependencies are the relationships between work that determine the order in which the work items (features, stories, tasks) must be completed by Agile teams. Dependency management is the process of actively analyzing, measuring, and working to minimize the disruption caused by intra-team and / or cross-team dependencies.

In this article, we’ll discuss how to identify, map, and manage dependencies to increase agility and reduce waste inside Agile teams.

Agile teams make dependencies manageable by sequencing tasks, work, steps, and processes.

What are Dependencies in Agile Teams?

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.

Why Do Dependencies in Agile Teams Exist?

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

What is Dependency Management in Agile Teams?

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

Types of Dependencies in Agile Teams

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

Dependency Type	Explanation	Example
Internal	Dependency is within the team’s control and is based on the relationship between work activities.	A builder asks the drywaller on his team to begin work on the interior walls of the house.
External	Dependency is outside of the team’s control, and is based on the relationship between teams, functions, or organizations.	A builder has to wait on a shipment of tiles before they can be installed.

Mandatory vs. Discretionary Dependencies

Dependency Type	Explanation	Example
Mandatory	Involves hard logic; one step must be performed before another step.	Interior walls in a new house must be built before they can be painted.
Discretionary	Involves soft logic: It’s best to do one step before another, but not necessarily required. These dependencies are defined by Agile teams as best practices.	Interior walls of a house should be painted before furniture and decor are moved in.

Dependency Function

Dependency Type	Explanation	Example
Finish-to-start (FS)	Task 2 can’t start until task 1 is completed. This is the most common type of dependency.	Land must be purchased before building can begin.
Start-to-finish (SF)	Task 1 can’t finish until task 2 is started. This is the least common type of dependency.	To close on the land purchase, an appraisal and / or inspection must be completed.
Start-to-start (SS)	Task 2 can’t start until task 1 has started, but task 1 does not have to be completed before task 2 can begin.	Drywall installation must start before painting can begin, but not all walls have to be installed for painting to begin.
Finish-to-finish (FF)	Task 2 can’t finish until task 1 is completed. Tasks that have a start-to-start dependency can also have a finish-to-finish dependency.	Drywall installation must be completed for the painting of interior walls to be completed.

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

Reason for Dependency	Explanation	Example	Considerations
Requirement dependencies	Dependencies that exist due to the requirements of the project (epic, feature, or story, in Agile terms) being built.	A new house must meet all building codes and regulations.	During the planning process, Agile teams should seek to identify these dependencies so they can plan accordingly.
Expertise or SME (subject matter expert) dependencies	Dependencies that exist because the work requires the specific expertise of a subject matter expert and cannot be performed without the input of someone with this expertise.	Because a house is built on a steep slope, a civil engineer must help ensure that the house will withstand all weather conditions.	If the team includes someone with this expertise, the dependency is internal and easier to manage. If it is external and required often, the team should consider adding someone with this expertise.
Business process dependencies	One step must be performed before another in order to fulfill business requirements.	Before construction on the house begins, a loan must be procured to pay for building the home.	Business dependencies need to be considered in pre-planning to ensure that operational processes are not overlooked.
Technical dependencies	Dependencies that exist due to technical limitations or constraints.	Because the home is built on a slope, the home must utilize different trusses, drainage and architectural reinforcements.	May not be uncovered until work has started. As a failsafe, all work involving technical requirements should also be included in the pre-planning process.

What is Dependency Mapping and Visualization and How is it Useful to Agile Teams?

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.

Agile teams can build parent-child relationships between cards for visual access to card counts and status, such as started, not started, or finished.

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.

Agile teams can connect dependencies visually with string mapping to quickly understand associated work and tasks.

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.

What are the Benefits of Dependency Mapping and Visualization?

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.