Photo by Frank Zhang on Unsplash

Dependency Management Techniques

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.
• 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.
• 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

Dependency Management Considerations — Dependency Attributes

Before describing the impact of dependencies, and techniques for helping manage them, let’s start with some initial considerations, when it comes to our approach to dependency management:

• Dependency Direction. One-way, or bi-directional?
• Dependency Frequency. One-time, or on-going?
• Dependency Dynamics. Individual, or team?; working context of that individual or team

Dependency Direction

One important consideration when considering what to do about a dependency is the direction in which it flows. If it only flows in one direction (Team A has a dependency on Team B; Team B has no dependency on Team A), then that should inform which of the dependency management techniques, described later in this post, is most appropriate.

Dependency Frequency

Another important consideration is how often the dependency is manifested:

• If it’s a one-off dependency, where it is unlikely to occur again once a particular need has been addressed, a technique that constitutes a lighter lift is likely appropriate. For instance, it might be enough to show the impact of the dependency by simply having a conversation, and possibly sharing something like a Dependency Spider Diagram or an Oh By the Way Dependency Matrix during that conversation — see the Dependency Visualization Techniques section).
• If it’s a recurring dependency, and especially if it occurs frequently, different techniques might merit consideration. Take a look at the section Techniques for Mitigating the Impact of Cross-Team Dependencies for ideas.

Dependency Dynamics

Yet another consideration when it comes to dependency management has to do with the context within which the person(s) work:

• If it’s an individual, it’s helpful to know whether they are literally the only person who can address the dependency, or whether anybody else can assist

Whether it’s an individual or a team that we have a dependency on, it’s important to understand their context, by considering things like:

• Whom to reach out to initially, and also on an ongoing basis (for instance, if it’s a single person on a Scrum team, the etiquette is likely checking in with the Product Owner and/or Scrum Master on the team first, rather than going directly to the person who would potentially be doing the work to address the dependency)
• What approach they take to their work (e.g., Scrum team, Kanban team, some other approach)
• What cadence applies to their work (e.g, if a Scrum team, are they on the same Scrum cadence, or a different cadence?)

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.

• Ad Hoc Check-in. In situations where a team has a dependency on a group or individual, where that group/individual either is not on Agile team,or is part of a team practicing something like Kanban (which doesn’t have the same meeting cadence that Scrum does), it might be necessary to have an ad hoc conversation with that group or individual, initially to make sure that the nature of the dependency is fully understood, and subsequently, to check in on progress, on an as-needed basis.
• Scrum of Scrums. In cases where there are multiple groups/teams, where they’re all working on the same or related products, or where the nature of the dependencies dictates that they check-in with other groups or individuals on an as-needed basis, many organizations have a short (15-minute) meeting on a regular cadence, where dependencies are typically high on priority list of topics to touch on. It’s NOT necessary for all of the teams to be Scrum teams to be able to have this kind of conversation.
• Send a Daily Scrum representative. Let’s say that two Scrum 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.
• 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
• 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.
• 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:

• Team meetings (such as Daily Scrums, Sprint Planning, Sprint Retrospective)
• Cross-team meetings (such as Scrum of Scrums, Release Planning, Program Retrospectives)

To take this thought process a bit further, see Dependency Management Techniques: Part II.