In this article I want to focus on the distinction between structural and instantiated dependencies. Most of the dependency management recommendations that you encounter deal with instantiated dependencies. However, the larger return on investment will be achieved by addressing...

In this article I want to focus on the distinction between structural and instantiated dependencies. Most of the dependency management recommendations that you encounter deal with instantiated dependencies. However, the larger return on investment will be achieved by addressing structural dependencies.

Note: This is the third article in the Dependency Series. The previous article is on The Economic Consequences of Dependencies.

Defining The Terms

Let me begin by defining my terms. A structural dependency is a linkage between two distinct organizational entities (e.g., teams) whose existence causes an instantiated dependency to be created when there is planned work or work in progress that requires the coordination of the two entities. An instantiated dependency is a specific instance of a structural dependency that is created because of planned work or work in progress.

Let me illustrate the difference between these two types of dependencies.

Structural Dependencies

Imagine you draw a picture of our organization’s structure with an emphasize on which teams or organizations have a dependency on one another.  Below is a typical example:

In this picture we can see (thick line) that Team B has a (structural) dependency on the Legal team. In other words, given the way that this organization has chosen to structure itself, if Team B needs legal work done (e.g., some legal text written or approved), it must engage with (depend on) the Legal team to perform the work.

This structural dependency is woven into the fabric of the organization. The only way to avoid this specific structural dependency is to either restructure to achieve a different flow of work or to focus our techniques on the existing structural relationship to better ensure the structural dependency is less likely to lead to instantiated dependencies that become blockers.

Instantiated Dependencies

When an actual work item for Team B appears that requires the Legal Team to do work (e.g., review the text of the new sign-up screen), an instantiated dependency comes into existence. See the image below for an example.

If the difference between structural and instantiated dependencies is not yet clear, then perhaps an analogy will help. In object-oriented development, there are classes and there are instances of classes. The classes define the structure of all the instances. In our example, structural dependencies are like the classes, and obviously, the instantiated dependency are the instances.

Addressing Dependencies

To fight back against dependencies at scale, we must address both structural and instantiated dependencies. At the start of this article, I mentioned that many of the dependency-management techniques that are frequently discussed address instantiated dependencies. Such techniques include:

How to groom/refine a backlog to reduce the number of dependencies (i.e., the “I” in the INVEST acronym) Using Scrum of Scrums to coordinate dependencies across collaborating Scrum teams Having a well-defined definition of ready that accounts for dependencies The Program Board in SAFe to capture and visualize cross-team dependencies The multiple techniques for designing Kanban tickets and boards to include dependency information

All of these techniques are used to manage instantiated dependencies that have come into existence due to planned or actual work in progress.

These techniques, however, are not applicable to address structural dependencies. Dealing with structural dependencies can provide a much higher return on investment.

The primary example of an often-discussed technique for addressing structural dependencies is to organize into feature teams. This technique is very effective at reducing the number of structural dependencies. However, there are several impediments that prevent this technique from becoming the sole solution to reduce structural dependencies (e.g., might require too many specialists to be on one feature team).

Other techniques for addressing structural dependencies include:

Organize into coordinated ecosystems Architect for “build using” (self service) Establish team-to-team working agreements Balancing system/portfolio-level WIP

What is important to remember is that an improvement at the structural-dependency level means either the elimination of all future instantiated dependencies associated with that structural-dependency improvement or a substantial reduction in the chance that an instantiated dependency associated with the structural dependency will become a blocker.

Summary

When examining an organization’s dependencies, it is helpful to distinguish between structural dependencies and instantiated dependencies. Both dependency types are important and need to be addressed. Most common techniques (except “organize into feature teams”) are focused on instantiated dependencies. There is substantial value to be derived by addressing the structural dependencies, and these are frequently not considered.

To learn more about the techniques for dealing with structural and instantiated dependencies you can attend my upcoming live online instructor-led course Dependencies Are Killing Your Agility: Learn to Fight Back on January 27-28, 2022.

Also, if you want to get notified when I published new articles, please sign-up for my periodic newsletter.

---

View Entire Post