Dependency Management Techniques
By: Philip Rogers
Tags: Books, Software Development, Agile, Scrum, Coaching

In an ideal world, Agile teams are set up to minimize the number of external dependencies, and if possible, remove external dependencies altogether. This post describes the impact of dependencies, and techniques related to dependency management.

The Impact of Dependencies

Agile practitioner Troy Magennis has written and spoken extensively about dependencies and their impact. Let’s take a look at some highlights from this document that is available from the Focused Objective GitHub repo.

The potential impacts from dependencies vary; here are some of the most common impacts:

Reduced ordering options. Suppose the highest-priority thing in the backlog has a dependency on something else before it can start; this forces the team to work on something that is lower in priority.

Suppose the highest-priority thing in the backlog has a dependency on something else before it can start; this forces the team to work on something that is lower in priority. Increased lead time and risk of delay. Let’s say that multiple teams are working on the same product/project, and they have dependencies on each other. With the addition of each dependency, we double the chance of being late. Lead time, a measure of how long it takes from the time a customer request is made, to the fulfillment of that request, is adversely impacted by dependencies.

Let’s say that multiple teams are working on the same product/project, and they have dependencies on each other. With the addition of each dependency, we double the chance of being late. Lead time, a measure of how long it takes from the time a customer request is made, to the fulfillment of that request, is adversely impacted by dependencies. The potential for cross-team friction. When different teams need to rely on each other to finish work, the reality is that each of those teams tend to have their own sets of priorities and motivations.

Now let’s take a look at what the impact of dependencies looks like, from a quantitative perspective, referring once again to Troy’s document, referenced above.

Reduced Ordering Options (each dependency halves options)

The simplest way to articulate the impact of dependencies in quantitative terms is simply to say that with each dependency that we add, we cut our options in half when it comes to when we can start work, as shown in Figure 1.

Figure 1: Reduced ordering options (each dependency halves the options)

Increased Lead Time and Risk of Delay

Another painful reality about dependencies is that for each dependency we add, in a cross-team context, we’re doubling the likelihood of being late, for each team that delivers late on something where a dependency exists, as shown in Figure 2.

Figure 2: Increased Lead Time and Risk of Delay

Techniques for Mitigating the Impact of Cross-Team Dependencies

Below is a summary of techniques that can help improve inter-team communication and coordination, and reduce the impact of any cross-team dependencies that exist. The techniques are listed in ascending order, based on how “easy” they are to employ, where “easy” is informed by the relative time commitment involved, and thus the first of them in the list requires the smallest amount of time.

Send a Daily Scrum representative . Let’s say that two teams have dependencies on one another, Team 1 and Team 2. Each team sends a representative to the other team’s Daily Scrum. For instance, if a Team 1 representative goes to Team 2’s Daily Scrum — they could: 1). Report back to Team 1 on any important information from Team 2’s Daily Scrum, like when they think they’ll be done with something Team 1 needs; 2). At the end of Team 1’s Daily Scrum (during the “Parking Lot”), the Team 1 representative shares information with them that they might need to know about Team 2 blockers, expected completion timeframes, etc.

. Let’s say that two teams have dependencies on one another, Team 1 and Team 2. Each team sends a representative to the other team’s Daily Scrum. For instance, if a Team 1 representative goes to Team 2’s Daily Scrum — they could: 1). Report back to Team 1 on any important information from Team 2’s Daily Scrum, like when they think they’ll be done with something Team 1 needs; 2). At the end of Team 1’s Daily Scrum (during the “Parking Lot”), the Team 1 representative shares information with them that they might need to know about Team 2 blockers, expected completion timeframes, etc. Send a planning representative . There could also be situations where Team 1 and Team 2 could benefit from having a representative attend their respective Backlog Refinement or Sprint Planning sessions. For instance, a Product Owner from Team 1 could attend Team 2’s Backlog Refinement, to provide context on upcoming work, or a Developer from Team 2 could attend a portion of Team 1’s Sprint Planning.

. There could also be situations where Team 1 and Team 2 could benefit from having a representative attend their respective Backlog Refinement or Sprint Planning sessions. For instance, a Product Owner from Team 1 could attend Team 2’s Backlog Refinement, to provide context on upcoming work, or a Developer from Team 2 could attend a portion of Team 1’s Sprint Planning. Temporary pairing . Pair Programming is an eXtreme Programming (XP) technical practice. There are many forms of pairing which can be beneficial. For instance, if we see a dependency between Team 1 and Team 2, we could create a “temporary pair,” such that a member of Team 1 works closely with a member of Team 2, on a temporary basis (for example, for a few days), to mitigate, and ideally eventually eliminate, the dependency

. Pair Programming is an eXtreme Programming (XP) technical practice. There are many forms of pairing which can be beneficial. For instance, if we see a dependency between Team 1 and Team 2, we could create a “temporary pair,” such that a member of Team 1 works closely with a member of Team 2, on a temporary basis (for example, for a few days), to mitigate, and ideally eventually eliminate, the dependency Inner sourcing . With inner sourcing, we are leveraging another one of the technical practices from XP, called Collective Code Ownership. As an example, Team 1 needs Team 2 to make changes. Team 2 has other priorities and Team 1 is blocked. In this case, we can have Team 1 make changes to Team 2’s code and submit a pull request.

. With inner sourcing, we are leveraging another one of the technical practices from XP, called Collective Code Ownership. As an example, Team 1 needs Team 2 to make changes. Team 2 has other priorities and Team 1 is blocked. In this case, we can have Team 1 make changes to Team 2’s code and submit a pull request. Rotation. With rotation, on a regular cadence (e.g., quarterly), a team member from Team 1 rotates to Team 2, and a team member from Team 2 rotates to Team 1 (or some variation on that pattern). Rotating team members can lead not only to a greater awareness of the big picture, it can also improve the depth of each person’s skill set, which can benefit them personally (greater exposure to more tools or techniques), and can benefit the team (more opportunities for multiple team members to complete various types of work).

Dependency Visualization Techniques

Visualization techniques exist that are particularly well-suited to dependency management. Here are two such techniques:

Dependency Spider

Oh By the Way Dependency Matrix

Dependency Spider

The Dependency Spider diagram is described in Agile Coach Jimmy Janlen’s eBook Toolbox for the Agile Coach.

Purpose: Identify the dependencies that a team has, using a diagram.

(See Figure 3, below)

Steps:

1. In a virtual document or diagramming application, start by drawing your team in the center.

2. Add a node on the periphery of the diagram, where each node represents a dependency source–that is, any entity that you interact with that blocks progress or forces wait time to occur.

3. Add notes to the legs of the spider diagram to provide details whenever a blockage or a wait time occurs that is associated with that dependency source (example dependency sources are listed on the left side of Figure 3).

4. (optional) Any time a dependency is removed, move it to a “Resolved” area adjacent to the diagram.

5. (optional) For bonus points, during a retrospective, pick one of the dependency sources and talk about what you as a team can do to mitigate or remove that dependency.

Figure 3: Dependency Spider

Oh By the Way Dependency Matrix

Author and speaker Dominica DeGrandis describes the Oh By the Way Dependency Matrix in her book Making Work Visible: Exposing Time Theft to Optimize Work & Flow.

Purpose: Identify the dependencies that a team has, using a spreadsheet.

(See Figure 4, below)

Steps:

In a spreadsheet or another application, start by creating a grid as shown in Figure 4, where:

Impactees (individuals or groups that are impacted by a dependency) are listed in rows

Impactors (individuals or groups own a dependency that impact others) are listed in columns

Place an “X” in the appropriate cell, and provide a callout or other visual descriptor that describes the nature of the dependency.

Variations:

Add a column that describes the impact of each dependency

Add a column that describes any actions that can be taken to remove the dependency, and who owns those actions

Rather than listing individuals or groups, list software components (or other technical areas of interest)

Figure 4: Oh By the Way Dependency Matrix

Conclusion

To minimize the impact of dependencies, and to help ensure that the techniques described in this document make a significant difference, consider leveraging the information associated with these techniques in settings such as the following: