I have less time for coding nowadays, because I have to take care of more organizational and coaching activities. Additionally, I really like to investigate small details and check how they can help improve certain situations. So here is yet another post about Kanban and Kanban boards.
A couple of weeks back, I was writing about internal done columns. I still think that an internal done column is a very useful element of a Kanban board, but there are cases when a different approach is much more suitable. If you or your team has lots of traffic between the parking lot and the column it belongs to, then an internal queue column is a better idea than an internal done column.
Have a look at the following Kanban board:
This Kanban board is completely fine: everybody is working on the most important items, the WIP limits are kept, and it is clear which the next item to continue with will be (‘B’). Items ‘C’ and ‘F’ are in a parking lot, because the team cannot work on them due to an external impediment.
Again, it is very important: if an item is blocked, but the team is able to solve that blocking issue on its own (solving another item, escalating etc.), then that item shouldn’t be placed in a parking lot! Parking lots are there only for externally blocked items.
Let’s see what is going to happen once items ‘C’ and ‘F’ are no longer blocked:
Let’s examine what the situation with the Kanban board is at the moment:
-
Items ‘C’ and ‘F’ are no longer blocked, meaning that they have been moved back to the column, but nobody is working on them. They became abandoned
-
There are 5 items in ‘Phase 1’, although the WIP limit is 3
-
The prioritization may not be right. If ‘C’ had been more important than ‘D’ before it was put in the parking lot, then a fair question can be asked: “How to continue? Shall we stop working on ‘D’ and continue with ‘C’?”
To sum up, this change ruined the previously completely fine Kanban board.
If the scenario above happens only once or twice, then the team still can continue with the internal done columns. A quick fix for the listed items above: call a “right on the spot” meeting, discuss the priorities and continue with the approach that best suits the team and the current situation.
If it happens multiple times, for example a team has a lot of dependencies on other teams or organizations, whose response time is not appropriate for the team (they are solving items slower than how the team works), then the team needs a change, not a quick fix. If I were a team member in the team that the Kanban board above belongs to, I would suggest to have internal queue (or ready for) columns instead of done columns, like this:
Let’s see what happens with item ‘C’ in this setup:
-
Item ‘C’ gets blocked
-
Move it in the parking lot (the arrow pointing down)
-
Item ‘C’ is no longer blocked
-
Item ends up in the queue (the arrow pointing up)
-
Prioritize the queue if necessary
Similarly to the Queue on the left, the internal queue is prioritized, and nobody owns any items in it until they can start working on one of them. With this approach, there is no way that an item becomes abandoned, because someone has to start working on it. This similarity solves the first and the third problem from above. Concerning the WIP limit, there are two options: either have the internal queue under the WIP limit or not. I favour having it under the WIP limit, because this will assure that the items will “flow” from left to right and won’t pile up in front of a column. I’ll be honest: the WIP limit will be compromised in this case, but I feel it is fine if the queue is filled from the parking lot. The WIP limit will ensure that nothing enters the queue from the left - finished items from the previous column - until enough more important items are finished in the current column.
For clarification: the sources for an internal queue are
-
Finished tasks from the left (this is pretty straightforward)
-
Unblocked items from the parking lot
What shall happen if the cycle happens with items staging in ‘Phase 1’? Shall the team put items back to the Queue on the left? These are very good questions. Similar to the case a couple of paragraphs above: if this happens once or twice, I would say that the team can put the items back - it really hurts saying this - into the Queue, but if this happens multiple times, the team should seriously consider stopping working and evaluating the whole value stream, because something is really really wrong if items become blocked in the first phase. This seems like a huge external impediment, which must be solved immediately.
comments powered by Disqus