I have just heard of this for the first time today and I think it is such a good idea. I am a firm believer that metrics can be used to help and this is a great example of where focused metrics can show the true impact of what might otherwise be perceived as a minor problem.
I also don’t see this as limited to KanBan either, it would work just as well on a Scrum Board, and a moment or two identifying the impact of impediments is time well spent.
Can I also add that impediments are not limited to blockers: extra work, anything slowing you down, lack of tools or other resources etc also counts as an impediment.
I’ve been helping a team at Asynchrony improve using blocker clustering, a technique popularized by Klaus Leopold and Troy Magennis (presentation, blog post) that leverages a kanban system to identify and quantify the things that block work from flowing. It’s premised on the idea that blockers are not isolated events but have systematic causes, and that by clustering them by cause (and quantifying their cost), we can improve our work and make delivery more predictable.
The team recently concluded a four-week period in which they collected blocker data. At the outset of the experiment, here’s what I asked a couple of the team leaders to do:
- Talk with your teammates about the experiment
- Define “block” for your team
- Minimally instrument your kanban system to gather data, including the block reason and duration
The first two were relatively simple: The team was up for it, and they defined “blocker” as anything that prevented someone from doing…
View original post 427 more words
John Yorke 