I got a question the other day from Enea Zuliani and Michele Degrassi. It was particularly heartwarming to read as they just read Kanban In Action and now have started to use. Kanban. In action.
They now had a question and I asked if I could share that question and my answer here on the blog. They kindly obliged.
Here’s the question (I’ve edited it a bit):
Dear Markus, let me get back to you with a question. If an agent has to choose between different kanbans (cards) which one to work on, and all the kanbans have the same characteristics (dimensions, etc.) and he can actually decide to work on every one of them, is there any “rule” you might suggest in order to pick a kanban - everything else being equal?
Kanbans or not kanbans
First of all - excellent use of the word kanban (that literally means visual card). This is exactly how lean workplaces are referring and using the term. We have confused it a bit, in the IT-industry, with not only a method to improve processes, sometimes referred to as the process itself but also sometimes the board.
All of this leads to this, the pretty confusing, but correct sentence can be said to an initiated audience:
The purpose of kanban is to limit the number of kanbans so that each kanban flows fast over the kanban
Phew… Luckily that was not the question.
Here’s my answer to the question, in short:
How would someone know what to pick next?
Well not really any rules - but there are a few simple heuristics that you can use.
First of all - Stop starting! Start finishing. Meaning; first, see if there is any work on the board that you can help to finish. Yes - even the work that you are not in charge of (“I cannot test that - I am not a tester”, is a common excuse for example). Our customers don´t really care who does what as long as the value is created.
A simple way to get this principle implemented is to start from the right of the board and walking to the left. Point to each sticky (kanban) and ask “Can I help finish this one?”. If you find anything you can help finish - do that by all means. It’s a great way of making sure your work flows fast and smooth and that the work in process limit (WIP) not is increased.
If you reach the end, see if the WIP limits allow you to pull more work. If so, I would pull the smallest tickets first. Because that would be finished fast and we would learn faster.
Or the most valuable one first. But, how do you know the value? If you don’t know the value - how can you know if it is a good ticket to pull?
Check out the prioritization algorithm known as WSJF (weighted shorted job first) for more information about this thinking.
If the WIP limits don’t allow you to pull new work; do whatever you find useful to help us move faster in the future. Only; make sure it’s something that you can drop should we need you to finish more work later.
I hope that made sense - its the simple rules I use. It’s summed up with the simple mantra
Stop starting - start finishing
It’s not often that people write the summary for me, but before I could publish this, Enea and Michelle responded with this. I’ll leave this as a summary:
Together we came up with a simple rule while implementing a kanban in a team: all things being equal, start reading the kanbans from right to left. This means preferring doing things that are closer to the finish line, in order to deliver value to the client as soon as possible, quite in line with your idea of “start finishing” which I love.
Perfect! They get it!
I hope you too found this useful, dear reader.
If you liked this post ... here's more for you:
Published byon Last updated