Understanding the Impact of Dependencies
To understand how to best deal with dependencies in a system, we first need to understand the impact of these dependencies. Here we are going to look at what happens when certain configurations of dependencies exist in an organization. How do these affect the likelihood of our most important work getting done? We will in particular look at three different configurations -
- Dependencies are explored, known, and managed upfront.
- Dependencies are allowed to emerge and managed just in time.
- Dependencies have been eliminated from the system.
For most folks, it would be obvious that the last configuration (no dependencies) is the ideal one. The question we want to explore is — How much better is it than the next best system? How well does it allow us to deliver our highest priorities in comparison to dependency-laden systems?
Any time we talk about understanding such systems without being able to observe real teams work in these ways, we turn to our old friend Monte Carlo simulations. For those not familiar with Monte Carlo simulations, as used to predict future states of a system, please take a look at the video below:
Most folks who are familiar with Monte Carlo simulations know that most of the time we are taking the data from one system and using that same data to project out future states of the system. The ‘system’ here most of the time refers to a single team. What if we had six teams, all working separately? Well, in that case, we have six different systems, the data from whom should be used separately to predict the future for those six teams. Now, if there are dependencies between these six teams, we have a larger system with six components. We can use the data from these six component systems and the knowledge of the dependencies to run Monte Carlo for this larger system.
Organization Monte Carlo
Running Monte Carlo for the entire organization is very similar to the way we run it for teams. We simply use the data from the past to figure out what could happen across the organization on day 1. We use Team 1’s data for Team 1, Team 2’s data for Team 2, and so on. We do the same thing for day 2, day 3… till the last day that we are interested in. In typical Monte Carlo fashion, we repeat this thousands of times to see what the results are across the organization.
As we keep moving forward in any single simulation, we will encounter dependencies across the teams. Based on our dependency management strategy we do whatever we need to at that point. We pause progress on a feature if a dependency arises. We do not start progress on a feature if we already know an unfulfilled dependency exists. Each team makes progress on their work and handles dependencies as needed.
In summation for ‘Organization Monte Carlo’ we are simulating all the upcoming days for the entire org using the data from the constituent teams. This gives a single set of resulting future states of the teams and as a consequence the entire organization.
Simulation Setup
We are going to run these simulations for an organization with six teams. Six is just a randomly selected number and of no particular significance. Each of these teams has a list of 10 features in priority order that they will work through. The size of the features could be anywhere between 1 and 20 stories. The sizes are randomly assigned. For the sake of simplicity, we are also assuming they follow similar throughput patterns. Which means the rate at which they get work done is very similar. The simulations for all these teams will run in parallel, simulating one day at a time for the entire organization. The entire simulation will run for 30 days.
We change the feature sizes and priorities after each simulation run to make sure we cover as many scenarios as possible. A sample of the feature setup is shown below.
The three scenarios that we will be simulating are — Dependencies exist and are managed upfront, Dependencies are not managed but allowed to emerge, and Dependencies have been removed from the system. In the cases where Dependencies exist, we will assume that every feature has a 70% chance of being dependent on a feature on another team. The standard dependency type is Finish to Finish, for example, Team A cannot finish Feature 1 unless Team B finishes the feature that Feature 1 is dependent on. All our dependencies are internal, i.e. where a feature on a team can only be dependent on a feature on another team in the system.
Teams work in priority order of features and only work on one feature at a time. They start with priority number 1 and move to priority 2 when priority 1 is done, then to 3, and so on. The only time this order might be thrown off is when we encounter dependencies.
In the cases where dependencies are managed upfront. The team with the dependent feature will not start the feature till the dependent feature has been completed. The team would instead skip over the feature to pick up the next one in priority order. As soon as the feature is no longer blocked by the dependency, it becomes available for the team to pick up.
In the cases where dependencies emerge and are not managed upfront, we do something slightly different. The team will start work on the dependent feature but will have to abandon it halfway if the feature we are dependent on has not yet been completed. The feature will have to be paused halfway (with the cycle time clock still running) and picked up again when the dependency is fulfilled.
In both cases, our teams still follow the rule that they finish a feature before picking another one up, regardless of a higher priority feature becoming available. The dependencies can be on any random feature on any random team (except for the team itself) in the 6-team organization.
Simulation Results
The tables below summarize the results of the simulations in the three scenarios that were described earlier.
No Dependencies
Let us take a look at these results one at a time. Taking the simplest scenario first, there are no dependencies in our system. As we will do in all of our setups, we ran 10,000 simulations for six teams trying to finish 10 features in 30 days. The table below shows the completion percentages for features depending on where they were in the priority order for the team that was working on them.
As can be expected, since the teams work in priority order, our highest-priority features have the greatest chances of getting done. The first two features have a 95%+ probability of getting done. For the 6 teams in the simulation, we are as certain as we can be that the highest priority feature of each team will get done.
The chances decrease as we go further down the priority order. Priority 4 for the teams and below have less than a 50% chance of getting done and the chances dwindle to under 10% by the time we get to priority no. 6. On average a given feature has a 34.11% chance of getting done. BTW, that overall average is a horrible way to summarize this data, as it leads to terrible decisions. It is included because it gives us a good comparison point for the different scenarios.
Managed Dependencies
Again, we use the same team and feature setups, this time with dependencies added. This is the case where we spend time understanding and mapping dependencies ahead of time. We have added a column to the results here. Aside from the overall percentage chance that a feature has for completion, we have also included the average percentage chance the feature has when it has a dependency.
A similar pattern as before shows up. Higher-priority features have a greater chance of getting done. There are a few major differences though. The completion percentages are much lower than before for our highest-priority features. The top 4 priority features are less likely to get done when dependencies are managed. The top two features are as much as 60% less likely to get done when dependencies exist. This is across the board, for all 6 teams in the simulation. For this organization, on average the chances of getting the two highest priority features for every team done have fallen by 60% each. With the highest priority feature being about 40% likely, the probability of each team getting their highest priority feature done is virtually Zero(0.4 * 0.4 * 0.4 * 0.4 * 0.4 * 0.4 = 0.004096 or 0.4096%).
The decrease in the chances of getting work done is much more gradual in this case when compared to the case with no dependencies. As a result, Features 5 through 10 have a greater chance of getting done when dependencies exist. This is primarily because we are “stealing” certainty from higher-priority features and giving it to lower-priority features. The overall average has dropped to 28.32%. This means any randomly selected feature has a 28.32% chance (about 6% less than the No Dependencies scenario) of getting done.
The Completion When Dependent column has much more stark numbers. These are for features that had a dependency in our simulations. Remember, this is the case where these dependencies are managed upfront. Our overall average is a fourth of the situation where there are no dependencies. This means the introduction of a dependency reduces the chances of a random feature finishing by one-fourth. Our highest priority features are only 13–14% likely to get done when they have dependencies. This is in comparison to the 96–100% likelihood in a system without dependencies.
Emergent Dependencies
One more change to our setup. Instead of trying to map out all dependencies ahead of time, we let them emerge. When a dependency shows up, we stop working on the feature till it is resolved. We move on to the next feature.
Though it might seem like it, this is not a copy-paste issue. The results for a system that allows dependencies to emerge are remarkably similar to the system where dependencies are managed. We have about a 40% chance of getting the top two priorities done. The chances decrease steadily from there.
In the top third of the table, the completion percentages for our top priorities are marginally higher than in the case where we had managed dependencies. After that (priority no. 4 onwards) the probabilities for the managed dependency case are better. This is true for both the summary Completion Percentage numbers and Completion When Dependent percentages.
The Overall Averages also show no significant difference. A random feature in the Managed Dependencies scenario is 0.25% more likely to get done than in the Emergent Dependencies scenario. On the other hand, our top priority feature for any given team is about 1% more likely in the Emergent Dependencies scenario. These differences are so small that they can be safely ignored.
Conclusions
Aggressively Remove Dependencies
Probably the most stark conclusion is, that for our most important features, in the system described here, simply adding dependencies caused a 60% drop-off in the likelihood of our top-priority features getting done. Would your stakeholders/customers prefer a 99% chance of their top priority getting done or a 39% chance? The answer is obvious. When a system has dependencies, we get a great payoff by removing dependencies. Aggressively do this, even if the cost is reworking the structure of the organization. The predictability and delivery gains will almost always outstrip the costs of reorganization and of breaking management or team-size norms.
Do Not Manage Dependencies
This result surprised me. There is no difference in the completion percentages whether we manage dependencies or just let them emerge. The same math applies in both cases. The possibility of getting all the top features for our teams done is less than 1%(0.4 * 0.4 * 0.4 * 0.4 * 0.4 * 0.4 = 0.004096 or 0.4096%). The results are so similar that we can safely say — The change between the two scenarios makes no difference.
In other words, upfront dependency planning and mapping make no difference to the final result. What is worse is that all the time we are spending mapping and managing these dependencies incurs huge costs. It is not just a one-time cost either. You have to pay the cost every time you do planning, and then repeatedly through the planning period following up on these dependencies.
In setups where there are a lot of inter-team dependencies, trying to manage the dependencies makes no difference, but removing them can more than double your chances of finishing your top priorities. The money we are currently spending on managing these dependencies is much better spent eliminating them. Not only will this increase our confidence in the system, but will also avoid the repeating cost of managing dependencies.
A lot of project management and agile frameworks advise people to do the exact opposite. When it comes to dealing with dependencies at scale, almost all the literature out there focuses on managing them. There are fancy methods, 2–3 day long planning meetings, old school red strings, and Gantt charts, all with managing dependencies as the focal point. On the other hand, most advice at scale should focus on eliminating dependencies. That is where the real positive outcomes are.
So, save your money. Take the bold step of eliminating dependencies instead of being satisfied with the middle-of-the-road advice of managing them. In fact, even if you do not eliminate dependencies, you would be better off not doing any dependency management and letting the dependencies emerge.
