In the first article in this Dependency Series, I discussed how shared dependencies are a critical factor that impact success when attempting agile at scale. In this second article I discuss the economic consequences of dependencies.
Dependencies Effect When Work Happens
If our team performs all the work, then we can more easily control when the work happens. If our team is dependent on other teams to get work done, then we quite likely do not control when all the work happens.
Being at the mercy of other teams to do work on our behalf has the potential to impact predictability, cycle time, and prioritization.
We might conclude before work even begins that dependencies will affect one of these variables. For example, if a team we depend on to do work cannot commit to doing the work when we need it, we might choose to work on another item of lower priority that does not suffer from this dependency constraint.
Or, even if the other team does commit to delivering what we need on a date that works for us, something can, and often does, happen that causes the other team to not get the work done by the promised date. This of course impacts predictability since we can’t deliver when we promised. It also affects cycle time – we might eventually finish and deliver, but it took longer than we had planned.
Let’s dive a bit deeper into the economics of these consequences.
Lifecycle Profits
Negatively impacting predictability, cycle time and prioritization can have real economic consequences on important proxy variables. For example, lack of predictable delivery to customers likely reduces customer satisfaction (an important proxy variable). Since there are many such proxy variables (e.g., quality, time to market, waste, etc.), I suggest we follow the advice of Reinertsen and represent the impact to these proxy variables in a normalized unit called lifecycle profit.
Lifecycle profit is the total profit potential of a product over its accounting lifetime. We are interested in determining the overall lifecycle profit consequences based on the sum of the individual proxy-variable consequences caused by dependency impacts on predictability, cycle time, and prioritization.
I know that all sounds complicated, but it is actually straightforward. For example, if our lack of predictably lowers customer satisfaction by 5%, we want to convert that 5% reduction into lifecycle profit. Let’s say by analyzing previous changes in customer satisfaction we determine that each 1% decrease in customer satisfaction equals a $1m reduction in lifecycle profit. Based on this analysis we now understand that if dependencies are affecting our predictability and that results in a 5% reduction in customer satisfaction, then lifecycle profit have been impacted by $5m.
So, to summarize, dependencies have economic consequences, and we want to communicate the sum of the consequences using a single unit called lifecycle profits.
Predictability
Predictability is the state of knowing when something will happen. For example, we can predict that the new feature will ship on June 30th. Having a high-level of predictability equates to being confident that we can deliver what we promised on the date we promised.
In a world with a lot of dependencies, making valid predictions (i.e., have good predictability) is very difficult. Every additional dependency will cut in half the probability that we can deliver as promised. If any (just one) of our dependent teams fails to meet its obligation when it said it could, our flow will be blocked, and we can easily miss our promised date of June 30th.
When our predictability decreases, then promises we made to stakeholders and customers are broken. The results are reduced customer satisfaction, possibly leading to customer attrition. Earlier I illustrated how reduced customer satisfaction can be converted into lifecycle profit. If there are any other consequences because of reduced predictability, then we should represent them by their impact on lifecycle profit. Overall, it is very likely that reduced predictability will reduce our lifecycle profits.
Cycle Time
Cycle time is the actual time spent working on producing an item or providing a service. Cycle time can be measured at multiple different points in the lifecycle of a feature. Important to our discussion is that we start measuring cycle time when the first relevant task begins and finalize the measurement when the last relevant task is completed.
I often use the analogy of click-to-click on a stopwatch. When we start working on something, click the stopwatch – time is now running. When we finish working on it, click the stopwatch again. The total elapsed time between the two clicks is the cycle time. Keep in mind the time on the stopwatch kept marching on regardless of whether we or another team were doing useful (value-adding) work or whether we were waiting. So, cycle time is the sum of time spent doing real work plus the time waiting for real work to take place.
Dependencies can have a significant impact on wait or blocked time. If our team needs to put work into the queue of another team, then the time our work sits waiting in that queue counts against cycle time. The more pieces of work we must put into queues of different teams means potentially greater and greater amounts of waiting time especially since there are more and more possibilities of getting blocked.
As cycle time increases, then important metrics like time to market (or more importantly, time to value) increase. When it takes longer to get features into the marketplace, we experience a cost of delay. For example, if we don’t deliver what we promised on June 30th, every month we are out of the market we will lose $500k in lifecycle profits.
Let’s make sure we’re clear. Even if everything goes 100% according to plan, we likely still experienced a significant cost of delay by having a lot of dependencies. The reason is that each dependent team must schedule or prioritize our work in their queues against all of the other completing requests they are receiving.
As such, we might be number 20 in a particular team’s queue, which means we may spend considerable time in a waiting/blocked state. So, even if the other team does our piece of work (which is the 20th item in its queue) exactly when it said it would, we still end up “predictably” later to the market than we could have been if we were able to eliminate this dependency.
In the presence of large numbers of dependencies, the work inventory sitting in the input queues of the servicing teams increases, which causes longer delay times. Simply stated, the bigger the queue, the longer we wait, and there is a real, measurable cost in lifecycle profits associated with that delay.
Prioritization
Given a team has finite capacity and potentially multiple competing requests to do work, prioritization is the ordering of these multiple competing requests. Alternatively, you can think of prioritization as scheduling the work.
Dependencies can impact prioritization. Let’s say our team wants to work on Feature A, but Feature A requires another team to do some work on our behalf. Furthermore, assume that the other team cannot do the work when we need it to. Since we are averse to starting work that we don’t finish (considered WIP), we might choose to work on Feature B (that is not dependent on the other team) instead of Feature A. For the sake of argument, what if Feature A delivers 10x the lifecycle profits of Feature B? If that were true, our dependencies are now materially impacting our lifecycle profits by forcing a clearly suboptimal prioritization.
This problem would be even worse if we thought we could get Feature A done and we didn't. Let’s say the other team committed to get done what we needed on the date we requested. So, we start working on Feature A and the other team (for any of an infinite number of reasons) determines it can't meet its commitment. Now we have the additional waste of the incomplete work (WIP) on Feature A that is delivering no value. There is also the additional cost-of-delay associated with Feature B since we delayed starting work on Feature B because we thought we could complete Feature A first (which we didn't do).
At least if we had known upfront that we would have been delayed on Feature A we could have knowingly reprioritized to work first on Feature B (suffering “only” the sub-optimal prioritization cost). Now, unfortunately, we are suffering not only the cost of working out of order, but many other costs including the additional frustration of not having fulfilled the commitment (delivering Feature A) we have made to ourselves and our customers.
It is clear the dependencies can have a meaningful, negative impact on how work gets prioritized.
Summary
Dependencies have a significant impact on lifecycle profits reducing predictability, increasing cycle time, and sub-optimizing prioritization. Given the magnitude of this problem, properly addressing dependencies is critical when adopting agile at scale.
To learn more about how to deal with dependencies at scale, you can attend my upcoming live online instructor-led course Dependencies Are Killing Your Agility: Learn to Fight Back on January 27-28, 2022.
The next article in this series is Agile Organizations Must Address Both Structural and Instantiated Dependencies.
Also, if you want to get notified when I published new articles, please sign-up for my periodic newsletter.