The Kanban, Flow and Cadence Simulation
I use a simulation when I have time in presentations on Kanban, Flow and Cadence, which I hope makes the ideas a bitter clearer and more concrete. I was asked if I could make the materials available, so here they are with an explanation. Its not perfect, and can be slow and time consuming, so I’d love any feedback on how to speed it up and make it a bit snapper.
The simulation uses an example work flow with 5 stages; Analysis, Design, Code, Test and Release, and a set of Minimal Marketable Features which require varying amounts of effort at each stage. The kanban board is set-up as below with WIP and Completed columns for each stage
An MMF progresses through the system by rolling a dice for each days work per stage and subtracting the appropriate effort from the relevant total. When a total reaches zero, the MMF can progress to the next stage.
This MMF requires 3 units of Analysis effort, 1 unit of Design effort, 4 units of Code effort etc. If the Analysis role throws a 2, then there is 1 unit of effort remaining. If they throw a 3 then there is 0 effort remaining and the MMF can proceed into Design. If they throw a 4, then there is 0 effort remaining, the MMF can proceed into Design, and 1 unit can be used on the next MMF.
The simulation proceeds by each role throwing a dice once per day, from Analysis to Release, and pushing work through the system. After each week (5 days) we can update the metrics spreadsheet with the current status. For each MMF, set its its status in the Column for week 2 (i.e. the beginning of week 2). In addition, to show how much work was started each week, set the status for all the new MMFs to Not Started in the Columns for week 1.
Continue for 3 or 4 weeks and you should start seeing a bottleneck. The effort numbers on the MMF cards are deliberately weighted so that Code requires more effort than the other stages. Hence in the CFD you can see that Test and Release are starved, while and Design is backing up. You can also see that Lead Time is going up, but that Throughput has settled at 4 MMFs per week.
If we continued to work this way we can predict that these trends would continue. Code would be a bottleneck, causing lead time to grow, and constraining throughput. However, at this point we can introduce kanban limits. I tend to set a single limit across both the stage and its completed column as I find this simpler. An alternative could be to have each column have a limit of 2. As we are implementing a kanban system we should also pull the work by rolling the dice from Release back to Analysis.
We can also re-focus our available effort to help Code be more productive. We do this by artificially weighting the dice. A normal dice has an average throw of 3.5. By reducing the average throw to 3 for Analysis and Test, we can increase the average throw for Code to 4. The following table shows how this works. For example, to get an average throw of 3, a roll of 5 or 6 translates to 4.
Running like this for another 3 or 4 weeks should clear the backlog, giving smoother flow and resulting in Lead Time coming back down. Throughput may also improve as we have made Code more productive. At this point further tweaks to the system may suggest themselves. Shifting the allocation of effort by further weighting the dice may is one option. Adjusting the limits is another. Run until all the MMFs have been completed and see how the graphs look.