This is the fourth post about Dan Vacanti’s book Actionable Agile Metrics for Predictability, An Introduction and how it relates to TameFlow. The most interesting points found in chapter 3 were:
- You really need to understand Little’s Law and when it is applicable.
- In order to get work done faster, you need to work on less stuff.
- Little’s Law is exact between any two time points when WIP is zero.
- Little’s Law can be applied exactly between the start and end points of a Minimum Marketable Release (MMR).
- In a continuous flow process, care must be taken to guarantee conservation of flow and to keep the process in a stable state.
- One can consider the assumptions of Little’s Law as process policies
- When process policies warrant the assumptions of Little’s Law, the entire process becomes more predictable.
- Process policies ultimately determine the performance of your process.
- Use Little’s Law and the underlying assumptions as guidance as to how to design and govern your process.
- Even with segmentation and categorizations of work in progress (WIP), Little’s Law still applies, both for the segments as well as for the aggregate of WIP.
- Work items do NOT have to be of the same size in order for Little’s Law to apply.
- Little’s Law describes the past, and it should not be used to predict the future.
- Predictability is more about having a system that performs according to expectation, rather than making exact forecasts.
Now we will look at what Dan has to teach with regards to Cumulative Flow Diagrams, which he describes in chapters 4, 5 and 6.
Chapter 4 Introduction to Cumulative Flow Diagrams
According to Dan it is crucial to truly understand what a Cumulative Flow Diagrams (Cumulative Flow Diagram) really is, especially since there is a lot of misleading or wrong information about them. In essence, a Cumulative Flow Diagram depicts only arrivals to, and departures from, the process and its constituent states. A Cumulative Flow Diagram provides both quantitative and qualitative information about the process’s performance. Dan dissects and explains the Cumulative Flow Diagram in detail talking about: reporting interval, time lines, counting of work items, bands of work states, significance of top and bottom band.
One interesting aspect is Dan’s advice to explicitly represent a “Done” state between any two work states. By representing the “Done” states, the waiting time between any successive steps of the process is captured and portrayed in the Cumulative Flow Diagram. This is a good advice that is entirely embraced by TameFlow too.
With such a distinction between active work times and wait times, Flow Efficiency can be calculated more accurately.
The Cumulative Flow Diagram is a visual representation of how the variables of Little’s Law interrelate. Any violation of the assumption of Little’s Law will become visible on the Cumulative Flow Diagram. Knowing how to identify the anomalies will help improve the process. Yet, for these visual clues to be significant, the Cumulative Flow Diagram must be a proper Cumulative Flow Diagram. For instance a Cumulative Flow Diagram showing decreasing lines is incorrect, as there is a violation of conservation of flow.
Therefore, in order to spot the visual clues, the Cumulative Flow Diagram must be constructed correctly.
A simplistic way to build a Cumulative Flow Diagram is to plot the chart by counting the work items in the process; but there is a better way to collect the data needed to build a Cumulative Flow Diagram. You must keep track of the times of arrivals and departures of the single work items into and out of each state of the process. By recording the times, it becomes much easier to compute all metrics and do deeper analytics. If you just keep counts you risk violating conservation of flow, especially when there are flow anomalies (like abandonment, back flows, etc.). Tracking times allows you to record the events properly.
Dan strongly criticizes Cumulative Flow Diagrams that display a backlog. Such an image gives the erroneous impression that the backlog items have been prioritized and committed to, while in reality they are still options. Commitment should be based on capacity an explicit pull policies (that warrant the assumptions of Little’s Law). Prioritization should be done only at the time of commitment. A related critique is about drawing projections on a Cumulative Flow Diagram — projections need a backlog to set a target, and they are future looking (while a Cumulative Flow Diagram is only showing the past). You must avoid depicting backlogs and projections on a Cumulative Flow Diagram.
The TameFlow Approach uses Minimum Marketable Releases (MMRs) and typically displays the scope of the MMR as a (target) line on the Cumulative Flow Diagram. That line is legitimate on the Cumulative Flow Diagram, since it shows the arrival of a batch of work items into the process, at the moment that the MMR is started. A MMR is different from a backlog. A MMR is a work package that has been truly committed to. You really intend to deliver all of the MMR, with no second thought. Therefore, you really want to draw attention to the commitment by including the whole scope of the MMR in the Cumulative Flow Diagram.
Obviously, WIP is considered zero before the MMR starts, and after it ends. Dan warns that in these cases there are further effects to take into account. One effect is that starting and ending with zero WIP, the Cumulative Flow Diagram will have a different shape. With an MMR, the Cumulative Flow Diagram will look like an S-Curve, due to work being started from zero at the beginning, and then going back to zero at the end. The Cumulative Flow Diagram of a continuous flow process is more linear. The flat parts at the beginning and end of the S-Curve obviously add inefficiencies and have an impact on predictability.
The initial and ending flatter segments of the S-Curve are like the acceleration of a car before reaching cruising speed, and the deceleration from cruising speed to a stop. Predicting how far a car will travel is easier if it just keeps the cruising speed, without any changes in speed. Since the phenomenon is known, one can exercise pull policies that mitigate it. For instance, one could prefer to pull “smaller” work items at the very beginning of the MMR — that would be akin to have the car accelerate faster in order to reach cruising speed sooner. The important thing is to know that this is happening, and that you can act on it.
A second effect is due to the fact that the whole lot of work items in the MMR enter the work process at the start of the MMR. With MMRs you must take into account that the average Cycle Time will be skewed because of the initial batch transfer. In TameFlow this can me managed explicitly, by keeping track of two Cycle Times for each work item: one is the Cycle Time of the item alone (just as described in Dan’s book), and the other is the Cycle Time of the item when the scope of the MRM is included. The former is used in the same way as described by Dan. The latter has a very important function in driving the organization to favor smaller MMRs, and hence have more frequent releases. Decreasing the scope of MMRs will give dramatic improvements in flow efficiency, when the flow efficiency is computed with the latter Cycle Time. (Though this might be worth a separate post to fully explain).
Dan advises about not representing work that has not been committed. This advice is most welcome from the TameFlow perspective. It highlights the difference that there is between backlogs and MMRs. It also provides the key to how you can best manage Cumulative Flow Diagrams that represent an MMR, by keeping in mind the S-Curve effect and the skewing of the Cycle Time. The notions of Cycle Time skewing and of the S-Curve effect need to be fully understood and considered if you are using MMRs. Further, if it is possible to perform the work you do in a continuous flow manner, then Dan’s arguments reinforce the idea to decrease the size of MMRs to the point you can abandon them entirely and adopt the continuous flow paradigm.
Note however that there are some additional reasons that might make you prefer having MMRs. They relate to aspects of psychological flow. Humans are naturally governed by cycles. MMRs give the natural start/stop moments when teams can celebrate their achievements and recharge before the next challenge. At times it is better to stop and restart with renewed energy, rather than continue indefinitely at a taxing pace. Yet, the beauty of using actionable agile metrics is that you do not need to decide if you are better off with MMRs or with continuous flow on the basis of opinions or feelings. With actionable agile metrics, you can run experiments with your process and see what gives the best measured outcome in your context.
Chapter 5 Flow Metrics and Cumulative Flow Diagrams
In this chapter Dan describes how to read the fundamental flow metrics off a Cumulative Flow Diagram, like Work in Progress, Cycle Time and Throughput. The vertical distance between any two lines is the total Work in Progress (between the two states represented by those lines). The slope of any line between two time points is the Exact Average Arrival Rate into the state succeeding that line. In particular Dan underlines how the horizontal difference between any two lines represent the Approximate Average Cycle Time (for the items flowing between those two lines). Notice that this is an approximate average. This is so important that it is worth repeating: The horizontal difference between any two lines represents the Approximate Average Cycle Time. This approximation is better the more the assumptions of Little’s Law are guaranteed.
These techniques for reading the metrics off a Cumulative Flow Diagram are entirely applicable to TameFlow.
Chapter 6 Interpreting Cumulative Flow Diagrams
In this interesting chapter, Dan reveals how to detect problems “at a glance,” just by looking at a Cumulative Flow Diagram. Typical patterns and shapes that may develop on a Cumulative Flow Diagram reveal common flow problems and process dysfunctions. The caveat, though, is that any interpretation must be done with consideration to the context it represents.
The purpose of a Cumulative Flow Diagram is not to find a shortcut to diagnose hypothetical process problems. The purpose of a Cumulative Flow Diagram is to trigger the right questions about the process, trigger them sooner, and suggest improvement actions.
To have an idea of what to look for, Dan presents and describes some specific shapes and patterns:
- Mismatched arrivals and departures
- Flat lines
- Stair steps
- Bulging bands
- Disappearing bands
- S-Curves
- “Boring” Cumulative Flow Diagrams
Finally Dan expresses concerns about using Cumulative Flow Diagrams to identify bottlenecks in the process. Cumulative Flow Diagrams should not be used to identify bottlenecks. Dan claims that the best use of Cumulative Flow Diagrams is simply to trigger the right questions.
This critique, about not using Cumulative Flow Diagrams to identify bottlenecks, is absolutely shared with TameFlow. In fact, TameFlow offers another means in order to identify the constraint of a (stable) process: by examining the average Cycle Time per work state. The work state that has the largest average Cycle Time is (most likely) the constraint of the process.
All in all, Dan’s description of Cumulative Flow Diagrams is superb and a should be considered as fundamental knowledge for effectively dealing with the Operational Flow of TameFlow.
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.