If your team is using Jira then at some point you’re going to want to look at some flow metrics to see how you can improve. You’ll very quickly discover that Jira only provides two charts out of the box and that neither one is terribly useful. The cumulative flow chart has known bugs and the control chart is both difficult to read and has problems of it’s own.
Interruptions can be a significant source of waste. By their nature, interruptions cause a context switch as we lose track of what we had been working on to focus on the interruption. There is a significant cost to that context switch as it takes time and effort away from the task at hand. There is also a real impact on quality as mistakes are far more likely to happen when we’re distracted.
About once a year I run across a team that has at least ten times as many items on the board as there are people on the team. The worst I’ve ever seen was a team of ten people with 227 items in progress.
In Kanban we often talk about flowing value through the system and yet that’s somewhat misleading. The reality is that we can’t know whether a work item is valuable until we’ve actually finished the work and made it available to our customers.
Many Kanban teams use classes of service to help model their workflow. We’re going to talk about how they work, where they are valuable and why you should avoid them wherever you can.
I sometimes run across teams that say “we tried kanban and it didn’t work”. When I hear this, I’m always genuinely curious and ask for more details about what they’d done and what specifically didn’t work for them.
One of the more subtle forms of waste is psychological distress. When we are afraid or anxious, our sympathetic nervous system activates to prepare us for one of fight, flight or freeze. All good responses in a survival situation.
In Kanban, we are always trying to optimize for efficiency, effectiveness and predictability. Waste in the system is something that hurts all three of these objectives and is something we want to remove or reduce wherever possible.
Over the past 15 years of working with various agile techniques, practices, frameworks, and strategies I’ve found that there is one thread that ties them all together. They are all focused on improving our ability to learn and to apply that learning to our future work.
This post is aimed at a fairly niche audience so if you aren’t trying to make sense of poor data out of some ticketing system then you might want to skip this one.