Dependency Management Techniques: Part II
In an earlier post, I went into some detail about reasons that dependencies can act as strong headwinds for teams, along with descriptions of techniques that can help mitigate or reduce the impact of dependencies. To take the narrative further, let’s begin with a brief review of some concepts from that earlier post, and then see where we can go from there to dig deeper into dependencies.
Recap: Dependency Attributes
It can be helpful, when articulating the dependencies that a team has, to make sure we have the same understanding of some key terms:
Dependency Direction. Uni-directional, or bi-directional? It can make a big difference whether the dependency only flows in one direction, or in both directions, when it comes to considering mitigation strategies. A different way of articulating this difference, which can be helpful, looks like this:
- Get-from: Examples of services that are provided to us
- Give-to: Examples of services we provide to others
Dependency Frequency. Ad hoc (happens sporadically), or Ongoing? Dependencies that are relatively persistent in nature likely require different approaches from those that happen only on an occasional basis.
Dependency Dynamics. Individual, or team? Service requestor, or service provider? Whether we’re relying on a single person, or a group of people, tends to make a significant difference.
Inventory of Dependencies
Once we have a shared understanding of terms, we can move on to making a list of our dependencies.
To start with, brainstorm with the team to call out each of the dependencies that we can think of, along with descriptive information for each one.
Once we’ve got some raw material to work with, we can make a list of the dependencies, using a spreadsheet, a text editor, or whatever digital tool that we might prefer.
For each entry, ideally we’ll end up with fields that look something like this:
- Dependency with. Name of individual, team, or group.
- Dependency direction. Bi-directional, or uni-directional.
- Dependency frequency. Ad hoc, or ongoing.
- Dependency dynamics. Give-to, get-from, or both. See below for a sample description.
Sample Dependency Inventory
Let’s say that we’re a software feature team, and that we rely on a group composed of Data Scientists and Data Engineers. Thus the entries could look something like this:
- Dependency with: Site Reliability Engineering (SRE)
- Dependency direction: Uni-directional
- Dependency frequency: Ongoing
- Dependency dynamics: Get-from: The SRE team sets up alerts and other forms of instrumentation in the cloud infrastructure to support
the work of the <feature team>
Dependency Impact and Dependency Mitigation
Next, let’s consider the impact of the dependencies in the list that we’ve compiled.
Much as we did in our previous step, we can use whatever software we choose to add additional information, with a particular focus on the impact of the dependencies, along with potential dependency mitigation steps that we can take.
Dependency Impact
Let’s use the following working definitions of impact:
- High. Completely blocks <feature team> progress in one or more areas
- Medium. Slows down <feature team> progress in one or more areas
- Low. Has a mild impact on <feature team> progress (e.g., there is a work-around available)
Dependency Mitigation Techniques
Let’s take a moment to recap the dependency mitigation techniques from the previous blog post:
- 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 there are two Scrum teams, Team 1 and Team 2, that could benefit from
having a representative attend their respective Backlog Refinement or Sprint Planning sessions. For instance, a Product Owner or Business Analyst from Team 1 could attend Team 2’s Backlog Refinement, to provide context on upcoming work, or a Developer or Tech Lead from Team 2 could attend a portion of Team 1’s Sprint Planning, when Team 1 gets to the point where they’re figuring out the “how” aspect of the work they plan to do during the Sprint that is about to start. - 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.
Putting All of the Pieces Together
We can now supplement the information we compiled earlier, to include the impact, which might look something like this, where for this example, to keep things simple, we’ll only use “get-from” (single-direction) dependency dynamics, and we’ll assume that our <feature team> is a Scrum team, while the Data Science team is a Kanban team:
- Dependency with: SRE
- Dependency direction: Uni-directional
- Dependency frequency: Ongoing
- Dependency dynamics: Get-from: The SRE team sets up alerts and other forms of instrumentation in the cloud infrastructure to support
the work of the <feature team>. - Dependency impact: Medium
- Possible Dependency Management Techniques: Ad hoc check-in; Scrum of Scrums
Let’s also consider a different example, where we now have a dependency between two feature teams, <feature team 1> and <feature team 2>, which flows in both directions, and where both teams are Scrum teams:
- Dependency with: <feature team 2>
- Dependency direction: Bi-directional
- Dependency frequency: Ad hoc
- Dependency dynamics: Get-from: <feature team 1> needs a change to a UI component owned by <feature team 2>; <feature team 2> needs a change to an API owned by <feature team 1>
- Dependency impact: High
- Possible Dependency Management Techniques: Scrum of Scrums; Inner Sourcing; Temporary Pairing; Rotation; Send a Daily Scrum
Representative; Send a Planning Representative
Conclusion
It’s my hope that this blog post helps extend the concepts that I wrote about earlier, making it easier to take this approach for a test drive. As is typically the case, it cannot be overstated how important it is for us to consider our unique context when choosing a dependency mitigation approach. And furthermore, no matter which technique we might choose to use, we’ll need to inspect and adapt, possibly tweaking the technique, choosing a different technique, or mixing and matching, to help our teams achieve the results that they seek to achieve. Enjoy the journey!
