Kanban is a change method I have not had the opportunity to employ here. I wish I could though. The apparent simplicity appeals to me. That’s not to say that Kanban is going to make life simple. Deciding to use Kanban in your project should not be taken lightly. If you thought Scrum exposed issues in your process just wait.
Most of us have heard of Kanban. We’ve likely even heard that it comes from lean manufacturing efforts at Toyota. I’ve written about it briefly before here and here. Our own burn-down chart has a level of resemblance to a Kanban board. A different team here is trying to use it as a primary work process. Even with all that I think we miss the point here, and maybe you do too.
I need to preface this with a disclaimer. I write partly to learn. Kanban is an example of that. I don’t get to use it as a tool currently, but would like to. Before I can introduce new tools I need to be well-versed in them. For me that means reading, research, and writing.
A core idea in Kanban is reducing work in progress. The more things going on at any given time the longer it takes to get all of them done. Interestingly there has been a lot of research lately showing that humans in general are bad at doing more than one thing at a time. I’ll leave perusing articles on the topic to the reader here. A primary method Kanban uses to combat this is pulling work through instead of pushing it. When work is pushed through it tends to find a choke point and pile up.
Think of the classic development to QA over the wall toss. Developers keep throwing more code at the testing group as they struggle to keep up. Code gets stuck at testing and bug fixing ends up taking longer due to stale code. Kanban will expose that choke point by showing all the work in progress sitting there waiting for testing. How it gets fixed is outside the scope of Kanban, and this is what some people miss.
I know there is more to Kanban then just exposing WIP choke points, but I’m going to stop with this idea for today. Kanban is a tool with limits, just like Scrum. Both of these tools are great at showing a company what is happening. Neither of them has all the answers for properly fixing the problems. They will show where change should be implemented to foster faster, better delivery. It may not be news that you want to see. You may think the project managers are a blocker and discover the real problem lies in how your support group acquires new hardware for your developers. If your organization is not ready for change there is no tool, method, process, or magic that will help it become more Agile.
Where does Kanban fit? The same place as Scrum. In an organization that is willing to change in pursuit of delivering better value more often.