Unknown Dependencies

A friend of mine works for a company with $23 billion in yearly revenue, where Product Team X deployed a component that broke Team Y’s product. Now, Team Y’s customers have to fork out $5 million for the new Y part. This is on top of the $10 million that they just paid to buy a new X part because the old X part was at the end of its life and was no longer supported. The customers in this scenario used parts created by both the X and Y teams. Part Y needed part X to function correctly. The only way Team Y’s customers could get their needs met was to buy the new X part.

Now this company has a major public relations disaster on their hands. They are losing significant market share because the two product teams didn’t talk to each other. Team Y had zero visibility into Team X’s decision to release a new version of software that Team Y’s product was dependent on. The blame game, replete with finger pointing, begins and now a VP’s head is on the chopping block. It’s very expensive when teams are unaware of mutually critical information. This is the type of thing that happens when there are unknown dependencies.

Let’s define dependency. From my perspective, when we talk about dependencies, three types emerge:

If your manager is stuck in a meeting and thus you can’t get the go-ahead to register for the conference before the day is out, then you’ve got yourself a dependency. Another example would be waiting on a test environment or a database restore from production before you are able to move your work forward.

Tightly coupled software architecture is a victim of the big bully that is Thief Unknown Dependencies. When a decision to remove a table from a database negatively impacts another team, Thief Unknown Dependencies scores big time. This is an example of a software code dependency.

Specialized expert skill-sets are at risk of being hit by this big bully thief. A developer wonders, “Are there unknown vulnerabilities in this code?” while waiting on feedback from a security expert. But the security expert is busy discovering how someone hacked into their now unsecure database. A question waits on input from a database architect. “Is the data in the test environment wrong? Can they please check it out?” But the database architect is busy helping the security expert. When you are the only one on the team with a special skill set, you can be the bottleneck pulled in many directions. Expert skills in high demand are often unavailable when you need them. Thief Unknown Dependency snickers in delight.

A similar problem occurs for changes outside of your control in the form of third-party vendors. Major cloud providers, like Amazon EC2, Microsoft Azure, and Google Compute Engine, provide service-level agreement policies that guarantee their customers 99.95% uptime. This equates to twenty-two minutes of allowable downtime per month. When your cloud provider is down, you are down, and Thief Unknown Dependency laughs at you. Granted, your cloud provider is a known dependency, but do you always know it when they first strike? How much time does the team spend troubleshooting a problem before they realize it was the cloud provider who did it in the datacenter with the candlestick? But you still lose even if it’s the provider’s fault because you are constrained by contractual agreements. You may be compensated with time credits, but if a failure occurs, how much time is wiped out trying to recover lost data? If you totaled the hours a team troubleshoots an incident like this, how much time is really stolen?

Troy Magennis gave an enlightening talk on dependencies at the Agile 2015 Conference in Washington, D.C. Troy uses basic boolean logic (where all values are either true or false) to show that there is only ever one possible combination of inputs that result in an on-time delivery. Every time you remove one dependency, half of the total possible delay combinations are removed. If delivery requires every piece being complete, every dependency you remove doubles your chances of delivering on time.1

Take a look at this example. If there are two inputs needed to deliver something, then there is only one chance in four of delivering on time. One chance in 2^n is the formula that computes the total number of binary permutations.

Come on now—math is fun! You got this. A binary digit can only be a 0 or a 1. A permutation is a way in which a number of things can be arranged. A binary permutation, then, is an arrangement of binary numbers. 2n is 2 to the power of n. When the number of inputs is two, n = 2, and we have 2 × 2, which equals 4, or 2 2.

Let’s write them all down to see how it works. There are four ways to have two inputs.

If there are three inputs needed to ship, then there is only a one in eight chance of on-time delivery.

Just by removing the strict delivery dependency, you double the chances (from one in eight to one in four) of on-time delivery. There will always only be a single chance where everything is on time.

Imagine you have reservations for dinner with four people who travel independently to a fine dining restaurant and you’re told you won’t be seated until all four people arrive. There are sixteen possible outcomes.

That is to say, sixteen possible combinations for whether people arrive on time or not. If you chart that out, fifteen outcomes have at least one person arriving late and only one outcome where everyone arrives on time. Dependencies are asymmetrical in their impact. With four dependencies, it’s not a 25% probability you won’t be seated, it’s a 93% (15/16th) probability that you won’t be seated. There’s a much greater chance that fifteen out of sixteen times, someone will be late. Time to call it a night and hit up the burger joint.

Figure 3, a three dependency chart, helps to visualize this math for three dependencies where the probability is 12.5% of being seated on time. When you add one more dependency, the probability is just one in sixteen, or .06% probability. Unless, that is, they work in Operations—then they’ll never leave work early enough to arrive on time.

When the local pizza company delivers more than two pizzas to the same meeting room, pay attention. A two-pizza team is a team that can be fed with just two pizzas—about five to seven people depending on the size of the appetite. If three two-pizza teams need to have a joint meeting to discuss their dependencies on each other, then you have high coordination costs. Fifteen to twenty-one people bantering their point of view can consume a lot of time. When was the last time fifteen people agreed on anything? When coordination needs are high, people aren’t available when you need them to be.

Small teams can move fast. Nothing beats a small, cohesive group of people who communicate and collaborate effectively. The problem occurs when dependencies span across teams, causing things to break. When one team breaks another team’s functionality by creating incompatible changes, the impacts can be destructive, as mentioned in the opening of this section about my friend’s $23 billion company. When we attempt to increase the performance of individual teams by breaking them down into smaller groups, hidden dangers await if there are unknown dependencies.

Cross team communication is hard. When a bunch of two-pizza teams with lots of dependencies between them spend a lot of time coordinating to avoid stepping on each other’s code (due to the merging of the different teams’ code branches), the benefit of the small team diminishes. Smaller teams can increase integration costs. We like small teams because they can move fast. Just realize that by moving fast as an individual team, you may be paying the price of not moving very fast as a whole organization.

Lastly, remember the following common attributes from Thief Too Much WIP: costly context switching and expensive interruptions. Distraction is one of the biggest hurdles to high-quality knowledge work, costing almost one trillion dollars annually.2

KEY TAKEAWAYS

It’s expensive when teams are unaware of mutually critical information.
Architecture, expertise, and activities on hold are some of the common dependencies you might run into.
Every dependency increases the probability you will be late. If possible, reduce dependencies to save time and money and avoid other complications. Conversely, every dependency you can find and eliminate doubles your chances of delivering on time.
When coordination needs are high, people aren’t available when you need them. The same is true for experts—when demand for a skill is high, experts are unavailable.
When it comes to dependencies, individual team performance can increase to the detriment of company-wide performance.