An infinite queue is a column on the Kanban board somewhere between the Queue and Live columns, one that doesn’t have a WIP limit and into which one can put many work items as one wants. A column without a WIP limit sounds like a bad practice, because if there is no WIP limit what will ensure that the work items are moving - being pulled - forward? Nothing really, so having infinite queues may not be a good idea after all. However, there are situations when we need them, because they have an important purpose: they connect flows. It was said before that an infinite queue cuts the flow into two pieces, but I argue that it connects the two pieces rather than cuts them.
Wait a minute. Until now in the previous kanban related posts, I have been talking about the flow (singular), and now I’m talking about flows (plural). What has changed? Nothing has changed, but until now, I’ve been talking about the flow on the meta level - it was easier, don’t hold it against me -, however that meta flow may consist of other sub-flows. It is not ideal, but this is how it is in the real world. One goal of the Kanban method is to find these sub-flows, merge them, and then optimize the whole by using incremental and evolutionary change.
It is easy to find the contact point of two flows. The first contact point is where the work items are handed over. Do you remember the times when the developers had to hand over the features to the test team so that they could do the testing? Of course you do. In this case we were talking about the development flow and the test flow. We don’t talk about handovers between developers and testers any more, but this doesn’t mean that we don’t have this phenomenon: we still hand over work between departments within an organisation. The problem is that the work items tend to disappear during these handovers. Actually, they don’t disappear, they end up in a hidden inventory, which is actually an invisible infinite queue. In this case, the first step is to make that queue (inventory) visible.
The second contact point is where the expectations are changing. For example, most of the teams I know are expected to deliver features continuously, but the customers or release managers expect the deliveries to happen on demand or periodically. In this case we are talking about the development flow and deployment flow. This setup is common in the software domain, for example one can observe the same phenomenon between design and development. In both cases the queue is visible, which is good, but the problem of how the work items are getting out it is still unsolved.
The ultimate and best solution is to introduce the WIP limit, because it makes sure that the work items are moving forward (it is not that simple, but good enough for now). However, it is a large step (kaikaku) and we believe in small continuous - evolutionary - steps (kaizen). One can ask “why is the WIP limit a large step in the context of infinite queues?” Before answering the question, let me share a story with you. Quite recently, we had a WIP limit of 2 on our deploy column, but our process didn’t allow us to deploy continuously, so we had to wait until it was allowed. Because of the WIP limit the work stopped after several days, which we couldn’t afford, so we increased the WIP limit. We could increase the WIP limit every day until the date of the deploy, so having it became pointless, and eventually we removed it from the column completely. Our deploy column became a visible infinite queue. The mistake we made was that we applied a WIP limit on a flow that we didn’t fully understand and wasn’t under our control. The conclusion here is that one cannot control (set a WIP limit on) something that one doesn’t understand and has no control over. Answering the question above: understanding and controlling the flow is clearly not a small step, therefore we cannot use it in this context.
We know so far that an infinite queue doesn’t have a WIP limit, so it is not clear what is actually going to happen to the work items in there and how they are getting out. If the flows have different owners, the absence of the WIP limit is not a big problem: the work must come from somewhere so the people working with the next flow pull from it. The work flows, but there is some uncertainty concerning relevance, importance and effectiveness. On the other hand, when the two flows have the same owner, the work can actually stop. It is a counter-intuitive statement, but think about it. Developers love to develop code, and they feed the work items into the limitless infinite queue of deployment, but they don’t bother emptying it, so the work items are staying in a “ready to deploy” state until somebody tells them to do the deployment and empty the queue.
If the WIP limit isn’t the best choice to get work items out of the infinite queue, what is? For example, we can use the 4th practice of the Kanban method: make process policies explicit. If you think about it, it can solve both situations from above. It is more effective to set a policy than a hard limit. Let’s say that the policy states that the queue must be inspected once a month or emptied every two weeks. Sure, these policies are less strict, but in contrast to the WIP limit, they are achievable, and more importantly, they can be improved step by step. Don’t forget that we are in the context of infinite queues - at the connection point of two different flows -, and we have to understand this context step by step (kaizen over kaikaku). So, for example, now we empty the deploy column every two weeks, and when we know more about the process, we’ll improve it, and we’ll use a one week policy.
This is exactly what we did with our deploy column if you still remember the example from above. We have a date instead of the WIP limit and we empty the column (the infinite queue) on the specified day (see the image above). We agreed that next time we’d have a closer date and when we have full understanding and control over the two flows (development and deployment) we’d re-introduce the WIP limit, and that time it would work properly. As you can see the infinite queue is actually helping us understand our process and get control over our flow. And that feels good.
comments powered by Disqus