Kanban Metrics – CFD
Of course, you can use a lot of data due to the content of your business or your industry, but starting with basic Kanban metrics, in order to progress evolutionarily, that is, step by step, can be a very effective step in adapting to this new way of working.
As I tried to underline in my previous post, Kanban is an evolutionary change management approach that allows you to design a sustainable and predictable system that is completely suitable for your needs and always uses data while doing this. The biggest difficulty for teams or organizations to implement this approach is generally collecting data and taking the right actions with the inferences made. Evolution, which I tried to briefly mention in the definition, is the most important criterion that we should base on here. Of course, you can use a lot of data due to the content of your business or your industry, but starting with basic Kanban metrics, in order to progress evolutionarily, that is, step by step, can be a very effective step in adapting to this new way of working.
WIP (Work In Progress), i.e. the number of works we do in parallel, which is one of our basic Kanban metrics, is the data that can show you your current situation in the fastest and most effective way.
The reason why WIP limits are so critical is, As Little Law said, the direct ratio between the number of works we do in parallel and our delivery times. In other words, if you focus on starting new works rather than finishing the works at hand, and if you try to carry out a lot of work at the same time, the completion (delivery) times of the works at hand will increase. That’s why we use the Cumulative Flow Diagram, or CFD, which is a very powerful tool to see how the quantity of work we are working on – totally independent of their content – actually has an impact on the overall flow.
The CFD is created with two parameters as you can see below; time on the horizontal axis, the number of jobs on the vertical axis.
You can think of CFD as a reflection of your team board; the area at the top where the board is entered and the area at the bottom where the board is exited (I will mention these areas, which have common uses, as To Do – In Progress – Done in the rest of the article). Ideally, we expect these areas (lines) to run parallel to each other because in Kanban systems we try to optimize the flow of the system, and the parallelism in question here actually shows us the existence of an uninterrupted flow without bottlenecks. If there are contractions or openings, we can interpret them in many different ways.
For example, in an ideal flow we might expect CFD to be like this;
What makes this graph ideal is the parallelism in successive steps. When we look at the lines; the number of jobs in To-Do increases at the same rate as those In-Progress and Done, that is, the number of jobs being worked on goes proportional to the number of new jobs on the board and is completed at the same rate. This is a sign that the received work is being dissolved at the same speed, which indicates a balanced flow.
However, when we see a contracting CFD as below, we can understand that the jobs that are worked on or completed are dissolved much faster than the number of works received, that is, the works that are promised to be done are actually completed faster than expected here.
In such a table; there may be many root causes, such as the fact that less work is drawn to the To-Do part than the capacity, the speed of arrival of the job to the team is lower than the speed of the team,the WIP limit of In-Progress part of (ie the maximum number of jobs that can be taken) is above the team capacity, etc. The point that will make a difference for you here is to find these root cause(s) together with the team and turn them into the right actions. For instance; making decisions like talking through this graphic in retros, making WIP limit changes, updating the team’s getting job rules, etc. will play a very supportive role in your kaizen journey.
Similarly, the root causes of an expanding table like the one below can be very diverse because jobs received here are completed at a much slower rate as opposed to above. The WIP limits of the team may be high, there may be internal or external dependencies, the work may be over the capacity, etc… This should lead to the search for the answer to the question of “What can we do to widen this bottleneck?”
Since Kanban is an approach that is based on an evolutionary improvement and tries to reach a predictable and sustainable system by supporting it with continuous data, CFD acts as a compass on this path.
Although I try to explain the above visuals on the basis of a three-column board (To Do – In Progress – Done) so that it can be easily understood, if you want to get an effective efficiency from CFD, I recommend you to proceed by using a board that shows your work much more clearly. On a team board that reflects your workflow exactly, you can see the bottlenecks pinpointly and take the right action decisions much more easily. Most of the tools currently in use give this chart automatically (Jira, Kanbanize, Nave, SwiftKanban, etc.) After all, as the first principle of Kanban says; start where you are ?