Blockades in work, like insufficient information, unclear requirements or having to wait for tools or systems to become available can have a systematic cause. It could be the case that similar problems that block the team keep happening until the underlying causes are addressed. You can use your blockades as treasures of improvement to sustainably improve the way work is done.
In the blog post blocker clusters: problems are not isolated events Klaus Leopold described how he analyzed blockades in a retrospective to solve the causes. They collected blockades and clustered them as internal (caused by the team and can be solved autonomously) or external (outside the team's sphere of influence) blocker. Inside these clusters they divided the blockades into categories and analyzed the lead time due to them. It turned out that the waiting time for customers was significantly long, so the team decided to define new rules for handling such blockades in the future to reduce lead time.
Klaus explains what they learned from analyzing blockers in the retrospective:
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 analyzing 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!
At the Lean Kanban Central Europe 2014 Conference Klaus Leopold and Troy Magennis will talk about how blockades can be used as treasures of improvement. Their presentation will show how to harvest these treasures to sustainably improve the working system, supported with a model to discover which blockages need to be removed to achieve the greatest possible leverage.
InfoQ interviewed Klaus and Troy about how you can investigate blockades and decide which ones to address, and about doing sustainable improvement.
InfoQ: What made you decide to investigate blockades?
Klaus: When I was visiting companies for a Kanban review the same scene happened quite often again: Work items on their board were blocked with blocker tickets saying something like “test environment not ready”, “waiting for information”, etc. I was asking how long these tickets were already blocked. They didn’t have data but the gut feeling was a couple of days, sometimes it could be even weeks. When I asked about how often these blockers occur I usually got the answer, “it happens again and again.” I thought that’s pretty much like touching the hot stove over and over again – there’s a learning loop missing!
So we started to collect data on how long each blocker is active, i.e. how much delay it causes for the blocked work item. Furthermore, we also decided not to throw away the blocker tickets after they were solved but collected them on a flip chart paper next to the board. After a while we saw clusters of similar blockers emerge. In fact, the majority of blockers were not singular events but they popped-up again and again. Also having data about delay was quite astonishing for everybody. We suddenly could make statements like, “if we wouldn’t wait for the test environment all the time, we could safe 25 days of lead time in only 4 weeks.” This was the missing piece of information to get people to the “let’s do something about it” mode.
Troy: I think Kanban has a history of showing impediments clearly for all to see. It seemed natural to want to rectify all of them, but that’s impossible. You fix some and others emerge. For me I wanted to know which ones have the biggest value to resolve, and which ones are rare and can be ignored for the moment.
InfoQ: I see similarities with root cause analysis in the way that you cluster and analyze blockades. Where does your approach differ? Why?
Troy: For me, it’s about understanding which blockers can be economically resolved, and which ones are causing the most impact. For example, a blocker impacting the constrained resource of your team has a much greater impact than those that impact freely available resources – even though those blockers might be more plentiful and easier to fix. By clustering you get a sense of the value for resolving each blocker cluster, not just the warm fuzzy feeling from finding the root cause of every blocker.
Klaus: I think the blocker cluster is a lot about defining the problem – it answers the question, “what is causing problems?” If I know that e.g. waiting for the test environment causes 25 days of lead time delay, I can ask the question, “why the hell is the test environment not ready when we need it?” This question could be answered with the root cause analysis or any other problem solving method.
I think the blocker cluster addresses a very big malaise in today’s management, which is installing solutions without understanding the problem. There are so many solutions out there in form of recipes, methodologies, and frameworks, which potentially really solve a lot of problems. However, too often a solution is picked because it’s trendy or the next best thing and not because we understand our problem and this or that method is the perfect solution to our problem. Blocker clustering helps you understand the problems in your work system and based on this understanding you can chose the best solutions for your problems.
InfoQ: At the Lean Kanban Central Europe conference you will present a with a model to discover which blockages need to be removed to achieve the greatest possible leverage. Can you describe this model?
Troy: There are a variety of ways to assess impact and benefit from fixing defects, and we show a few. The key point is you must balance the cost of resolving blockers against the impact those blockers cause.
The simplest way is to handle blocker resolution like risk analysis – create a 3x3 matrix of resolution cost (L/M/H) and current impact (L/M/H) and then start fixing the Lowest cost to fix, highest impacting first.
We are going to show more complex analysis based on simulation. By simulating the blockers in a software tool that hypothetically completed a project 1000’s of times, we can see the calendar and cost impact with and without each blocker. This gives us a list of blockers and their cost of NOT fixing. We should fix ALL blockers where their impact is greater than the cost to fix. Some blockers are not worth solving.
InfoQ: Can you explain why it is important to have sustainable improvement?
Troy: Complex system evolve. New types of technologies and work types become more common. You may well have a great system for delivery yesterday’s problems. By having a way to inspect what is causing today's issues, you can allocate the right resources to resolving those that have economic value.
InfoQ: What can you do to make improvement sustainable?
Klaus: That’s a very big question! It’s actually so big that Sigi Kaltenecker and I wrote a book about it ;-) (Kanban in der IT) The short answer could be:
- Understand the problem. Understanding is essential when it comes to improvements. How can I possibly improve something without understanding the problem?
- Find your own way. Improvement is not so much about what you are doing it’s much more about how you are doing it. We all know the good old stories about Toyota where they freely granted access to their factories and visitors went home, implemented the same practices but weren’t nearly as successful as Toyota. It’s totally not about best practices. It’s about understanding what you are doing and improving your particular situation by finding out your own best practice – which remains best until you become smarter again, and again, and again…
- Involve people. Even if you understand the problem, it’s not wise to install a solution like a mechanic. Organizations are living social systems and thus, they can’t be managed like controlling a machine. People are not passengers on organizational improvement journeys – they are the essential drivers of improvements! (see Kanban change and organizational models)