“In everyday life, the Flaw of Averages ensures that plans based on average customer demand, average completion time, average interest rate, and other uncertainties are below projection, behind schedule, and beyond budget.” – Sam L. Savage, 2009 – The Flaw of Averages
“Variation is the hard reality, not a set of imperfect measures for a central tendency. Means and medians are the abstractions.” – Stephen Jay Gould, 1985 – “The Median Isn’t the Message”
“Essentially, all models are wrong, but some are useful” – George E. P. Box, “Empirical Model Building and Response Surfaces”, (1919 – 2013)
“Remember that a model is not the truth. It is a lie to help you get your point across.” – Sam L. Savage, “The Flaw of Averages”, 2009
“You are allowed to lie a little, but you must never mislead.” – Paul Halmos, mathematician, (1916 – 2006)
Last week I read an article about yet another tool showing the ability to produce CFDs (cumulative flow diagrams). Maybe you’re already a user of one of these tools that help you visualize your workflow, and generate them for you automatically (or “auto-magically”) as part of reports they provide. Or, perhaps like me, you still generate them mostly using MS-Excel. Either way, have you wondered just a little about how a CFD works?
As most do, this article displayed a line extending vertically between “stages” on the CFD (or workflow processes, as I often call them) and identified this distance as the WIP (work-in-progress) on a specific date for the respective stage (or stages) of interest. There was also a description of another distance, a line extending horizontally between stages of interest on the CFD and identifying it as the “average lead time” for the requests (workitems) arriving on a specific date. That is, the average time for a request (workitem) to “flow” through (arrive into and depart out of) one or more stages of interest. Lastly, there was a description of a sloped line, as a mean delivery rate of requests (workitems) flowing into or out of a stage (workflow process) depending on viewing the workflow upstream or downstream. Note: for more on the basics on reading a CFD, see this earlier post here.
A Difference Is Not An Average, Right?
It is easy to understand that WIP is simply a “difference” between two counts on the CFD and represents the number of requests (workitems) at a point in time. Similarly, seeing the slope as a simple rise over run calculation of a number of requests per unit of time (a rate over a period of time of interest) is not a complex concept to accept. But, what about the notion of the “average lead time” derived from the CFD? How is it a “difference” between two points in time read from the CFD (ex. calendar dates) can represent an “average” unit of time for a request (workitem) to flow through a stage (workflow process)? A “difference” that represents N numbers summed up and divided by N. Yes, really! But how can this be?
“Queues lie at the root of a large number of product development problems. They increase variability, risk, and cycle time. They decrease efficiency, quality, and motivation.”
“Large queues form when processes with variability are operated at high levels of capacity utilization. In reality, the misguided pursuit of efficiency creates enormous costs in the unmeasured invisible portion of the product development process, its queues.”
“Since high capacity utilization simultaneously raises efficiency and increases the cost of delay, we need to look at the combined impact of these two factors.”
“We have already pointed out that companies do not manage product development queues. What do they manage? Timelines...In contrast, when we emphasize flow, we focus on queues rather than timelines. Queues are a far better control variable than cycle time because, as you shall see, queues are leading indicators of future cycle-time problems. By controlling queue size, we automatically achieve control over timelines.”
– Don Reinertsen, 2009 – The Principle of Product Development Flow: Second Generation Lean Product Development
If you’re new to or rusty on CFDs, it would be helpful to review “Basics of Reading Cumulative Flow Diagrams” first. This earlier post covers basic definitions and the mechanics of reading WIP (work-in-progress), lead-time, and an average completion rate (throughput) from a CFD. It also includes links to external sources, one showing a basic example of how to create a CFD using MS-Excel, and another providing a quick overview of their use in the kanban method context. From this foundation I’d like to shift here toward a visual analysis perspective, exploring a few contexts where a bottleneck in our workflow is more or less present and see how it might appear on a CFD.
To be clear, I don’t think CFDs are the only way or “a best way” for spotting a bottleneck in your workflow. If you’re adequately visualizing your workflow on a board and diligently measuring and managing work items as they flow through your process, you’re well on the way to being able to identify where any bottleneck might be occurring. (Note: see my Kanban Board Design Primer under Resources/Nuggets here). That said, don’t under-estimate the value of using the CFD as well for learning about what happened, is happening, or will happen in your workflow. It can be a very effective tool for creating an easily accessible visual historical record and a trending perspective of a workflow in your context.
What is a Bottleneck?
Let us get a shared understanding of the term “bottleneck” by first looking at these selected Wikipedia definitions:
- Metaphorically a bottleneck is a section of a route with a carrying capacity substantially below that characterizing other sections of the same route. This is often a narrow part of a road, perhaps also with a smaller number of lanes, or a reduction of the number of tracks of a railway line.
- In engineering, a bottleneck is a phenomenon by which the performance or capacity of an entire system is severely limited by a single component.
- A bottleneck in project management is one process in a chain of processes, such that its limited capacity reduces the capacity of the whole chain.
As we continue our discussion, a key point from these definitions to keep in mind is the “singular” characteristic. Additionally, I’ll infer a “stationary” characteristic as well for the bottleneck throughout the time reflected by the example CFDs that follow. (more…)
Note: After reading this post, you may find these posts of interests as well:
“Bottlenecks – Revisiting the Reading of Cumulative Flow Diagrams” dated 11/27/2012
“Are You Just an Average CFD User?” dated 02/21/2014. Also, Dan Vacanti has also captured and expanded in greater detail on much of the topics touched on in this post, in his book titled “ActionableAgile.”
During our Agile Denver Kanban SIG’s September meeting, we revisited the previous month’s discussion on the “basics of reading cumulative flow diagrams.” I captured our initial questions and a brief summary of our discussion a few days later to post on our SIG’s LinkedIn site. However, I felt there was a bit more “food for thought” from our discussion to capture.
This post is the “expanded summary” inspired by our past two recent SIG meetings. If you’re relatively new to CFDs and still find the basics of reading them a bit puzzling, I hope these questions and the “walk-through style” responses help clear up a few things. If you see something that “smells” wrong or have an interesting insight, let me know that too!
First Things First!
If you’re completely new to CFDs, here are two links we used to “kick-off” our SIG’s discussions.
The first link is to a slideshare post by Zsolt Fabok, on the basics of kanban. Check out slide 27 in particular though for a high-level visual and description of a CFD first.
The second link is to a blog post by Håkan Forss, where he does a great job showing step-by-step how to create a simple CFD using MS-Excel. This should help you get started creating your own but more importantly, even if you don’t create your own going forward, seeing and understanding the basic mechanics of creating one should help your understanding of them.
Wait, one quick question first, what is lead time and what is cycle time and how do they differ?