A Kanban system is just so friendly and shows us where problems arise. Combined with WIP limits it is even friendlier and even tells us  that we should solve the problem NOW before starting new work. Wonderful! And this is precisely what many companies do – they solve problems. I try to convince companies that they should do even more: solve what causes the problems. One makes the first step in this direction by not throwing away blocker tickets from the Kanban board but by collecting them, for example, on a flipchart.

Evaluating blockers

When I was invited by a client to a retrospective, we took a closer look at the collection of blockers. We searched for identical or similar blocker tickets and made groups out of them. First of all we built two large groups: internal and external. Internal blockers are caused by ourselves and can be solved autonomously. For example, we are waiting until a server is configured, discovered a dependency on another work item without which we cannot continue working etc. External blockers are outside our sphere of influence. For example, we are waiting for a supplier or for data from a client, etc.
This first rough clustering was completed quickly but – which is of little surprise – did not help us much. So we decided to zoom in on the two clusters. In the case of the external blockers, it became apparent very quickly that only the categories of client and supplier exist.  In the case of internal blockers, the picture was much more diverse: we identified the following clusters: server, other more important issues, Michael, tickets and something else. I found the clusters Michael and  other more important issues  rather amusing: They described work which on account of the call of the project leader or Michael – the company owner – was interrupted because something else was more important at that particular moment.  These were usually opportunities which were made use of. All blockers landed in the cluster something else which only appeared once and thus could not be grouped.

What do blockers cost?

Then we carried out an analysis of how much the corresponding blockers cost in terms of lead time. The start and end times of each blocker were recorded which made this a very simple task. This resulted in the following picture:

It turned out that many blockers cost little in terms of lead time. However, it also became apparent immediately that the waiting time for customers accounted for a really big chunk  – namely 130 days. One should know at this point that this customer started Kanban just six weeks before! Immediate consensus was reached that something had to be done: 130 days waiting time in a period of only six weeks is anything but small. No sooner said than done! We fetched Michael (the owner) along to our retrospective and showed him the image. We did not have to explain a lot. Alone the sight of the blocker cluster resulted in a creative discussion on how these waiting times could be reduced. The result was new rules on how to handle these blockers; when, how, who passes on the information as well as escalation rules. It also turned out that a lot of blockers were caused because the client did not deliver the required material. However, it also turned out that the client often did not know when to deliver what. The result was a tiny modification in a process step: inform client about deliveries. Nobody was forced to work harder, better, faster, stronger – it’s just a very simple change in the way how we work. Life can be so easy if only allow it to be easy…

Blocks are not isolated events

It always turned out that blockers are not isolated events but have a systematic cause. That is why I strongly recommend keeping records of blocker tickets and analysing them regularly. In some cases,  a small system change is all that is needed to attain really major improvements. The system changes are often so trivial as, “We should ask Karl from the OPs team to attend our daily standup“. No individual works differently or faster on account of this change yet the work is completed earlier. Deming sends his regards!
The example is a specific point. Normally, I recommend first to focus on the internal blocker cluster since cleaning up one‘s own house usually works much more easily. However, in this particular case it was not really appropriate as our analysis has shown  maximum potential savings of about 30 days in the case of internal blocks – if ALL would eliminated in the internal clusters. This is disproportionate to optimizing a delay of 130 days in the case of just ONE external cluster of 130 days.