Blocker clustering – a topic which I’m working on for several years now, may not be missing in my new book Practical Kanban. In addition to a detailed explanation of how blocker clustering works and what you can achieve with it, there is also an interview with an intensive user in the book: Matt Philip, Director of Learning and Development at ThoughtWorks in St. Louis, Missouri. As an appetizer for the book, you can read the interview here in my blog. Have fun!

Klaus: In which context, do you use Blocker Clustering?
Matt: My organization develops customized software for our customers. That is why there are more than 30 small, cross-functional teams for various domains, from health care to retail, products for mobile apps, up to large system integrations.
Klaus: In real-world Kanban systems, there can be different perceptions defining a blockade. How have you defined it in your organization?
Matt: I recommend each team to find the definition which fits for their respective context. But, I also give the team a standard definition, which I borrowed from “Kanban From the Inside” (Burrows, 2014) by Mike Burrows: “A blockade is an abnormal condition, that prevents already committed work from moving forward.” This usually requires an answer to the question: “Where does our commitment point lie?” I, for instance, would not consider an item blocked when it is still sitting in backlog. One of the teams I worked with had, when they were just starting, put the stories as blocked each time they went to lunch. I pointed out to the team members, that lunch was not an abnormal condition.
Klaus: When blockade clusters form, which clusters pop-up the most?
Matt: Within the two large categories “internal and external blockades”, we often see clusters such as “dependent story”, “missing requirements”, “environment not available” and “product owner not available”. The first attempt from a team to identify the largest cluster had the description “unknown”. That was the incentive for the team to be somewhat more exact the next time they were writing down the blockades.
Klaus: Which methods have you embraced to work on the cause of blockades?
Matt: In one case, the cause of the largest blockade-cluster was an internal problem. We used the Fishbone technique to get to the root of the problem and found several possible solutions. In another case, the external cluster was attributed to a customer. The team made the customer aware of the cost of these blockades and asked if this was acceptable to the customer—the team gave the customer the information, so that the customer could make better decisions.
Klaus: What were your insights?
Matt: First and foremost, blocker clustering helps a team, above all else, to think about the ramifications of blockades. Many people see blockades simply as a nuisance, and not as a source for process improvements. Secondly, clustering emphasizes that blockades have a cost. In the case of a customer, whose product owner was never available, it wasn’t clear to all those involved that this caused large delays and the team did not repeatedly send reminders just for fun. Quantifying such blockades by number of days quickly creates a greater understanding of the impact to your own company. Many teams occupy themselves extensively with the high-value and large work items, but forget that, in the end, blockades will strongly influence delivery and predictability. Blocker clustering helps them to recognize systemically caused blockades and to take them into account, or completely avoid them, in the future.
Klaus: Which improvements have you observed?
Matt: As with any technique, blocker clustering can only show where the problem lies and help quantify it. It’s the team’s responsibility to use the information accordingly. One team, for example, was struggling with interdependent story blockades. As a result, the idea to select the work differently emerged, by placing WIP-limited feature swim lanes on the Kanban board. At the organizational level, blockades emerged, which sprawled over several teams involved with the stories, that were not finished for development. So, we started a discussion in management about team structure and whether or not new, or different, roles were needed within some teams. Blocker clustering can trigger improvements on many levels.

More material around Blocker Clustering:

• Using Blocker Clustering, Defect Clustering, and Prioritization for Process Improvement, InfoQ-Acticle by  Klaus Leopold and Troy Magennis
• Video Interview with Matt Philip about Blocker Clustering
• Talk of Klaus Leopold about Blocker Clustering