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.