The benefits of continuous blocker clustering

If you manage your work by using some kind of visualization, the chances are high that you also visualize your blockages.

One of the most common visualizations is some kind of task board that represents the subsequent stages work items go through. Assuming you have such a board it can be quite helpful to visually mark which of those work items are currently blocked. This enables the whole team or organization (depending on the scope of your board) to see where work is stuck and to do something about it.

Usually (in the physical world ) these markers had the form of post-it notes in a different color and denoting the reason for the blockage. If you add just a little bit additional information, these blockers can be utilized to identify typical hindrances in the flow. Information you might want to gather are a reference to the original work item this blocker was attached to, the time(stamp) the blockage occurred and the time(stamp) it was solved.

In the Kanban community there is a practice known as “blocker clustering” where all involved parties come together at specific points in time and cluster these blockers according to things that stand out once you try to sort them and categorize them.

Blocker clusters can be either things like “Waiting for department «X»” or “Problems with system «Y»” or something completely different like “discovered missing information from phase «Z»” – that really very much depends on your individual environment. And usually these blocker clusters change over time. And so the should.

Now, here’s an idea: why only do this at certain intervals? Just as pair-programming in software development could also be called continuous code-review, the practice of blocker clustering could be done each time a blocker is resolved.

Granted, this wouldn’t make the big blocker clustering superfluous. After all that is where all concerned parties can decide whether they want to treat the resulting blocker clusters as special case variation –where one-off events caused the blockage– or common cause variation, where the blockage is caused by things that happen “all the time”.

The distinction between these two kinds of variation in the flow is important. One of them, the special case variation, hast to be handled on a case by case basis, whereas the other one is a great opportunity for structural improvements in the way you work.

And this is where continuous blocker clustering really can make a difference. Instead of waiting for the big blocker clustering, people come together and decide into which blocker cluster the blocker goes as soon as it is finished. This doesn’t have to happen in a separate meeting.

After all, the blocker (and the way it got solved) would be announced in the next board walk anyway. Which is also a good place to have this discussion.

And once you do continuous blocker clustering, you can have additional agreements like for example: If there are more than five new blockers in a category you can immediately (or at least very shortly afterwards) come together to discuss whether you want to treat this as a new common cause variation and whether you see a chance to improve your way of working together to address this new common cause. The number five is just an arbitraty number, depending on things like number of people involved, throughput etc. your numbers will differ.

You could also have an agreement to hold such a meeting whenever you have collected five blockers that you couldn’t categorize into a blocker cluster in less than 2 minutes and were therefore grouped under “uncategorized”. (Another working agreement.) The opportunities for demand driven improvements through this approach are vast.

The same basic idea is behind the concept of signal-based Kaizen meetings, that happen whenever specific –agreed upon– circumstances trigger the need for improvement and invoke a spontaneous get-together of the involved parties. Opposed to having only improvement meetings at fixed intervals this makes for much tighter feedback loops and thus enables quicker improvement.

till next time
  Michael Mahlberg

(Special note for people who rely solely on jira: It is a bit hard to implement this is an easy way in jira, but it is possible. And also helpful. But it does include some creative use of fieldvalues, some JQL-Fu and some dedicated Jira-boards. Keep in mind that Jira-Boards are nothing more, and nothing less, than a visualized database query. There’s a lot of power in that, once you start moving beyond the pre-packed solutions.)