CFDs – What does "Good" look like?


Is the Cumulative Flow Diagram the most unloved and misunderstood tool in the Lean-Agile Toolbox? Despite its decorative colours and inherent simplicity, I think it might be.

I too often see struggling Developers and Agile Coaches not even noticing that the shape of their CFD is visibly describing to them the effects of team and organisational dysfunction. I'm left to conclude that they don't have a mental model of what "Good" might look like.

So let me take you on a little tour, a simplified '3-bin' (3-state) version of the ideal CFD, and help you see what I can see...

NB: In these two examples, I shall assume it to be a Stable System; that the Backlog Items are of equally small size; that the capacity and efficiency of the team remains constant; and that there is a steady, FIFO demand for work the team performs.

Defining the 3 states:

  • "New" – Items waiting in the Product Backlog.
  • "Active" – Items being worked upon by the Development Team.
  • "Done" – Finished items.

Example 3-bin-Kanban Board


Where, in this example, WIP Limit = 3 Items

Example 3-bin-Kanban CFD

In a CFD (Cumulative Flow Diagram), the height of each coloured band represents the State Distribution (i.e. the number of Backlog Items in the respective Columns) over a period of Time.

Key takeaways:

  • The WIP (the Work In Process) is held to a set value.
  • As a result of the constant WIP:
    • The average Cycle Time (the time it takes to finish the Work In Process - i.e. in this example, the time it takes to move from "Active" to "Done") remains constant.
    • The average Throughput (the rate at which work gets finished) remains constant.
    • The average Lead Time (the total Time the Customer/Stakeholder waits for the work to pass through the System - i.e. in this example, the overall Time it takes to move from "New"-> "Active" -> "Done") remains constant and is entirely predictable!

Beginner mistakes:

  • Most new Kanban Teams do not set and respect WIP Limits. (They merely "Push" from the left, rather than "Pull" from the right.) As a direct result:
    • The amount of WIP in the System grows.
    • The Cycle Times and Lead Times balloon.
    • Management responds by "expediting" items (creating a vicious circle of more WIP).

Example (Pre-2011 'Batch') Scrum

Where, in this example, Sprint Backlog count = 3 Items

Example (Pre-2011 'Batch') Scrum CFD

For a broader discussion of the change in the Sprint Backlog from "Committed work" to "Forecasted work", see here.

Key takeaways:

  • The Sprint Backlog is conventional Scrum's natural way of Limiting WIP.
  • All the work committed to each Sprint is completed (and – in this instance – satisfies the Sprint Goal).
  • The regular and consistent Sprint Event gives a very predictable 'Step Shape' to the CFD. (There is no gap between the end of one Sprint and the start of the next.)
  • Due to Backlog Refinement (where the Development Teams helps the Product Owner prepare enough "Ready" Items), at the point of Sprint Planning, there is a recommended buffer of around 2 Sprints' worth of Product Backlog Items – but there should not be much more than this!
  • The Throughput is constant and so an equal amount of Backlog Items are finished each day.
  • In Sprint Planning, the Team pulls in the highest priority items first and then, during the Sprint, "Swarms" to complete the highest priority Sprint-Backlog Items first.
  • A particular Backlog Item's Lead Time might depend pretty heavily upon the Sprint into which the Item is Pulled.

Beginner mistakes

  • "Underflow" – not having enough "Ready" Backlog Items prepared in time for Sprint Planning. [Product Management issues.]
  • "Overflow" – dragging Developers away from doing useful work to prepare more Backlog Items than they need or can consume. [Product Management issues.]
  • "Carry Over" – the Team does not complete all the Items in the Sprint Backlog, meaning that work is dragged from Sprint to Sprint. This typically is a symptom of one or more of the following:
    • Pulling far too much work into the Sprint Backlog. [Poor estimation / Siloed-thinking / Waterfall-Mindset.]
    • Not finishing Items of work at regular intervals (with all the testing and bug-fixing activities, etc. left until the end of the Sprint). [Poor sizing of Items / Lack of Teamwork / Waterfall-Mindset.]
    • High numbers of Defects. [Development issues.]
    • External interruptions / not respecting the Sprint Backlog + Sprint Goal. [Organisational issues.]
    • Poorly defined Backlog Items, leading to mistakes & unanswered questions. [Product Management issues.]
    • Phase-Gating / Sign-Off Process / Dependencies upon key figures outside the Team. [Management / Procedural issues.]

Makes sense?

How does the CFD of your Team compare? (Feel free to write in the comments section below.)

But what about Continuous Improvement / Kaizen?

With a steady Throughput, halving the WIP halves the average Cycle Time. (This is why "Single-Piece Flow" through the System, i.e. reducing WIP to 1 item, is considered the ultimate!)

But, for simplicity's sake, I neglected the effects of Continuous Improvement; I leave the reader to imagine the visual result of Kaizen upon a Team's CFD...

Hint: For a given WIP, what would happen to the Cycle Time and resulting Throughput if efficiency were to improve over time?

Location: England, UK

Comments

Post a Comment

Popular posts from this blog

Little's shopping basket

Image
We've all been there. Waiting. Waiting. Looking at the queue ahead of us. Waiting. Glancing at our watches. Wondering when we're going to get our turn... In the 1960s, Dr. John Little famously provided the Mathematical proof for the following helpful formula (which later became known as Little's Law). L = ⅄W Where, in this instance: L is the average number of customers at the checkout. W is the average time the customer waits. ⅄   is the average rate of new arrivals. Now, crucially, in a stable system - where no customers are created or destroyed on their way through the checkout process(!) - the Departure rate will equal the Arrival rate. Therefore, in a stable system, we can happily equate these to queuing theory terms. Such that: L ≡ average W.I.P. (Work in Process) W ≡ average Cycle time ⅄ ≡ average Throughput E.g. if there are 5 of us queuing at the checkout, 4 people ahead of us, and the cashier is processing on average 1 person every 2 min...
Read more

Inconvenient Metrics – Part 1 – The 5 Psychological Coping Mechanisms

Image
In a Lean-Agile environment, we're continuously trying to improve the product development and delivery processes, and, to that end, as William Edwards  Deming once famously quipped: "Without data, you're just another person with an opinion." So, one might imagine that most fair-minded people would be only too happy to inform their judgement by means of empirical evidence (especially since Lean-Agile provides us with so much of it!). But, in truth, when sub-par statistics, metrics or KPIs are presented to an uninitiated audience, the resulting levels of ' Cognitive Dissonance ' and ' Mental Gymnastics ' can sometimes be quite surprising! I n my experience - ignoring complete  'non-sequiturs' - t here is usually a retort which takes the form of 1 of  5 Psychological 'Coping Mechanisms': A claim of Inaccuracy A claim of Unrepresentativeness . A claim of External fault . A claim of Irrelevance . Or a claim of Sheer hopelessne...
Read more