Select Page









A Difference Is Not An Average, Right?


In a previous post here I provide a reference for the best starting point I’ve found so far to explore further what allows CFDs, and in a related manner Little’s Law, to work. I’ll tell you now it is not magic! However, in this short blog post I can only briefly summarize what I learned from that reference and since then related references by saying CFDs (and similarly Little’s Law) are very robust, and applicable in wide variety of domains and contexts.

However, a key point here is using CFDs effectively requires understanding the assumptions they are based on and in particular the nuances in different contexts. This is even more important in my opinion, when using a tool that “auto-magically” creates them for you. Consider that as you deviate more and more from these assumptions and nuances specific to your context, any “average” lead time you read from your CFD becomes a “grimier approximation” (less meaningful, less useful) and will likely not reflect the actual average lead time of those requests completing.

But Remember An Average Is Just An Average

Even if you’re fully convinced the CFD you have in hand is giving you a good approximation of the average lead time for requests (workitems), it is only an “average.” Is this also important to understand? Yes! Especially when considering how you might use it to make decisions about next steps to improve your workflow processes, or to communicate to others when a request (workitem) might be completed, or when a set of requests (workitems that make up say a feature, MMF, MVP, or epic) will be done.

Am I suggesting that a CFD is not useful? In fact, it is quite the opposite. I found studying how they work to be extremely helpful in more deeply understanding principles of flow and concepts of pull scheduling. In particular, in understanding how “everyday rules” (polices), those written down explicitly, if any, and especially those unwritten ones, maybe even “unspoken” ones, like “who screams loudest wins”, impact the performance and predictability of workflows.

However, a second point I’m making is that I would not stop with looking only at the “averages” read from the CFD, especially that average lead time. As with any other average used in analysis, they should be considered in light of the distribution of the data used to create them. Visualizing the data with simple tools like scatter plots and histograms help go beyond the initial information found on the CFD. Add to that also a close inspection of the workflow context that produced the data used to create the CFD (or any average), and especially the “everyday rules” (polices).


In summary, I’m recommending these three things: learn more about the assumptions and nuances for specific contexts that that allow CFDs to work; go beyond just looking at the average lead time read from a CFD by inspecting the scatter and shape of the data used to create the CFD; and look closely at the policies governing how requests (workitems) enter, move through, and exit your workflow processes.

In particular they’ll help you learn a lot more about the variation (“the hard reality”) of your workflow process; the hard reality likely contributing in a much greater way to long lead times (duration) for individual requests (workitems). That is, influences negatively effecting lead times in ways that are often much greater than those contributed from the “complexity” of the requests (workitems) arriving into your workflow, or the “level of effort” (direct hands-on time) needed for completing a request (workitem). This deeper understanding I believe is essential for creating more predictable workflows. So, I hope you’ll give them a try and not be just an average CFD user!

Take care,