This is the sixth post about Dan Vacanti’s book Actionable Agile Metrics for Predictability, An Introduction. In the previous post we learned about Conservation of Flow. The key points were:
- If items enter into a process faster than they exit, the process will become overloaded and collapse.
- In order not to overload the process you simply need to control how much work is allowed to enter it across the arrival point.
- The average arrival rate should be approximately equal to the average departure rate.
- When the process is balanced, the top and bottom lines on the Cumulative Flow Diagram become parallel.
- Getting a balanced process is the single most important step towards predictability; and how WIP is limited is less important than actually doing it.
- In advanced applications of Tameflow, the amount of work that is allowed to enter into the process is limited to the amount of work that can be handled by the constraint.
- The arrival point is the point where work is effectively committed to.
- After stepping across the point of commitment, there is no returning back.
- Any backlog maintenance work, which is typically done in Agile methods, can be considered as waste and be discarded entirely.
- All and any prioritization is done only when capacity is available and only to the extent that can be handled by that capacity.
- There is a commitment to conserving flow.
- The commitment to conservation of flow allows you to express expected Cycle Time for delivery as ranges with a probability distribution.
- Flow disruptions should always be taken as an opportunity to ask: Why did it happen?
- Items that are prematurely discarded from the process, should never be removed from the data.
- The state of the process should be taken into consideration when making prioritization and pull decisions.
In this installment we will examine one of the most interesting chapters of Dan Vacanti’s book. It is about the very useful idea about understanding, detecting and acting on Flow Debt.
Chapter 9 Flow Debt
Dan revisits the Cumulative Flow Diagram. The fact that the horizontal distance between any two lines is an Approximate Average Cycle Time has far reaching consequences.
This cannot be stressed enough. The length of a horizontal line on a Cumulative Flow Diagram is not an exact time. It is not even an exact average time. It is an APPROXIMATE average time.
The idea of an approximate average can be confusing, and it is easy to dismiss such a number as entirely useless. However, if one recalls Little’s Law assumption that the average age of all Work in Progress should be constant, then it is interesting to relate the approximate average to the actual average.
Dan teaches that you can compare the Approximate Average Cycle Time read off the diagram to the Exact Average Cycle Time calculated from the collected data (up to that time point). This will give an indication as to how the Average Cycle Time is trending.
Dan reminds to keeping in mind Little’s Law assumption, because then it becomes easier to understand why it is good to know whether the Average Cycle Time is increasing, decreasing or constant over time. If the Average Cycle Time is not constant over time then predictability is at risk.
Naturally, there are three cases to consider:
When the approximate average is greater than the exact average.
When the approximate average is equal to the exact average.
When the approximate average is less than the exact average.
Watch out for when the Approximate Average Cycle time becomes greater than the actual average Cycle Time: you are incurring in Flow Debt. The meaning of this is that a significant amount of work-items are staying inside the process more than what you would expect. They are aging more than what you would anticipate based on Little’s Law. Obviously this is valid only provided you are in the conditions required to have a predictable process (i.e. the assumptions of Little’s Law are maintained).
How can a significant amount of work-items be aging more than expected? There might be many causes. One of the most common is that some work-items are receiving preferential treatment. Commonly this is what happens when you are expediting work through the process, at the expense of other work that is kept up.
Flow Debt is what you will incur and have to pay off later whenever you decide to expedite work.
Dan underlines that any Flow Debt that is incurred must be repaid, either as longer Cycle Times for the other items or the abandonment of those other items with consequential waste of time and effort.
More generally, Flow Debt happens whenever work-items age artificially because of some interference in their natural flow through the process.
Such interference can be due to explicit policies (like expediting or using Classes of Service), or implicit (like when some work-items age because blocked by some event, or worse because nobody is truly accountable for taking care of them).
Interferences on flow always introduce instability in the process, and severely impact predictability. The degree to which interferences have a negative impact on predictability depend on their frequency of occurrence and on their handling policies.
According to Dan, typically interferences happen with policies that are simply badly conceived of because their impact on flow is not fully assessed or understood. At other times flow is badly affected when reasonable polices are misused or abused. For example, when the only work that is moving along is expedited work, which then causes all normal work to remain blocked indefinitely.
Beware: Even well intended polices might cause Flow Debt!
The case of when the Approximate Average Cycle Time is less than the Exact Average Cycle Time should also be handled with care. While it indicates that you are actually paying off Flow Debt — and it is obviously good to do so — it is still a clear symptom that the process is instable.
Beware again: Paying off Flow Debt will also damage predictability!
Naturally, you should strive to pay back as much Flow Debt as possible in order to restore process stability and predictability.
The ideal case is when the Approximate Average Cycle Time is roughly equal to the Exact Average Cycle Time. Then the process is stable and predictable. Therefore, a useful diagnostic tool to assess the process’s health is to monitor the difference between the Approximate Average Cycle Time and the Exact Average Cycle Time: if it becomes too large, you need to take action.
Flow Debt and the TameFlow Approach
Any flow-based approach cares deeply about keeping the process stable and predictable. In the TameFlow Approach, however, explicit attention is generally not given to Flow Debt. Why so? Because a typical TameFlow implementation (TameFlow Kanban) will be using Minimum Marketable Releases (MMR). With MMRs, TameFlow presents some natural antidotes that counter the effects of accumulating Flow Debt.
The first antidote against Flow Debt is the very nature of a MMR. A MMR is a pre-defined scope of work, and work-items are simply not allowed to live for-ever as Work in Progress. All the work-items in a MMR must be finished before any further work may be started on the next MMR.
The second antidote against Flow Debt is the use of Buffer Management. If work-items are allowed or induced to artificially age inside the process, sooner or later there will be a buffer signal that will trigger investigation and remedial actions.
The third antidote against Flow Debt is that TameFlow is very conservative as to how any extra work should be handled. Work in Progress in a MMR is interrupted as little as possible. If there is any extra emergency work that needs to be taken care of, that work is triaged to see if it can be eliminated, postponed to the next MMR or actually added as an emergency item. Even if an emergency item is added, insofar as possible, it will not get precedence over other items in flight. It might be put on the top of replenishment queue so it will be the next item that is started, but without interrupting work on current items. If preferential treatment is called for and interrupting current work is deemed necessary, then precedence will only be granted based on economic factors (such as Cost of Delay or Throughput Octane), or if it is really a matter of life-or-death.
Naturally, if a TameFlow implementation evolves to a continuous flow process (like TameFlow Scrum), then the formalization of the concept of Flow Debt in order to detect slow moving or even stale work-items becomes prominent.
Here Dan’s contribution of formalizing the notion of Flow Debt and explaining how to use the Approximate Average Cycle Time read off a Cumulative Flow Diagram and compare it to the Exact Average Cycle Time to detect if Flow Debt is being incurred, becomes a very valuable and actionable advice. The technique can be fully incorporated in TameFlow when transitioning to continuous flow.
Links:
- Dan Vacanti’s book is Actionable Agile Metrics for Predictability, An Introduction.
- For more information about TameFlow, read the book Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban; or
- Check the site https://tameflow.com.