Dancing with getKanban (Using POLCA)
Companies that produce many different or customer-specific products can use a variant of Kanban called POLCA, which stands for “paired-cell overlapping loops of cards with authorization.” A few years back, POLCA got some attention on Twitter and I explained its potential application to knowledge work on my blog in a post titled, “Squeeze More Out of Kanban with POLCA.”
In this post, we play the getKanban Board Game, initially using the standard rules for work in progress (WIP) limits, then, inspired by POLCA, we change the rules. The results show an equal throughput between POLCA and non-overlapping WIP limits, with a smaller inventory size in the case of the POLCA version.
First, I provide a short introduction to the getKanban Board Game with a description of the set-up and basic results. Then I provide a brief introduction to POLCA and explain the change of the rules in the game and its set-up using it, then discuss the results. Finally, a few words are spent on the team’s utilization.
Simulation: getKanban Game
The step-up with standard WIP limits is shown below–a basic simulation of the complete 24 project days, focused only on the regular work items. The expedite, fixed delivery date, and intangibles are left out. In addition, the events described on the event cards are ignored. This provides a clean simulation showing the effect of applying the WIP limits in a different manner.
Other policies are taken from the game: a billing cycle of 3 days, replenishment of the “ready” column is allowed only at the end of project days 9, 12, 15, 18, and 21.
The result of running the game at the end of day 24 is Kanban.
The picture shows the state of the board, lead time distribution diagram, control chart, and cumulative flow diagram.
From these, it can be inferred that:
(a) There are 10 items in progress
(b) Throughput is 25 items in 24 days
(c) Median lead time of items from “ready” to “deployed” is 9 days
Interesting to note is that the control chart (middle chart) shows the average lead time dropping to 5 to 6 days in the last three days of the simulation. Since the game starts at day 9, this shows that it takes 12 days before the system settles into a new stable state, with 5-6 as an average lead time compared to the 9 days in the beginning.
POLCA: New Rules
In POLCA, the “O” stands for “overlapping,” so the essence is to make the WIP limit overlap.
POLCA – Paired Overlapping Loops of Cards with Authorization
One of the characteristics differentiating POLCA from Kanban-based systems is that it is a combination of push and pull; push when you know you can pull.
Setting WIP limits to support pushing work when you know it can subsequently be pulled. The set-up in the game for POLCA is as follows:
For clarity, the loops are indicated in the “expedite” row.
How do the limits work? Two additional rules are introduced:
In the columns associated with each loop, a limit on the number of work items is set. For example, the columns “development – done” and “test” can only accommodate for a maximum of 3 cards. Likewise, the columns underneath the blue and red loops have a limit of 4 and 4 respectively.
Work can only be pulled if:
a) the loop has capacity, i.e. fewer cards than the limit
b) the next, or overlapping loop, has a capacity.
These are illustrated with a number of examples that typically occur during the game:
Example 1: Four items in the “development – done” column
No items are allowed to be pulled into “ready” because there is no capacity available in the blue loop (Rule 2)
Example 2: Two items in “test” and two items in “analysis – done”
One item can be pulled into “development – in progress” (Rule 1 and Rule2).
Results for POLCA
The main results for running the game for 24 days with the above rules is shown in the charts below.
The control chart shows that it takes roughly six days for all existing items to flow out of the system. The effect of the new rules (POLCA style WIP limits) is seen starting from day 15.
On average the charts show a lead time of 3 days, starting from day 18. This is also clearly visible on the lead time distribution chart and on the narrow cumulative flow diagram.
The number of items produced by the project is 24 items in 24 days. This is equal to the throughput as measured using the standard set of rules.
Work In Progress
The total number of items in progress in only 3 to 4 items. This is less than half of the items as seen in the simulation run using the standard set of rules.
Note: The cumulative flow diagram clearly shows the 3-day billing day and replenishment (step-wise increments of black and purple lines).
As described in my blog post, “One Change at a Time,” getting feedback from improvements/changes that affect the flow of the system takes some time, because it takes some time before the system settles into the new stable state.
With POLCA, you can expect the learning cycle to be shortened. In running the game, the control charts show that it takes approximately 12 days before the system reaches the stable state, whereas with the POLCA set of rule this is reached in half the time.
Results for POLCA – Continuous Replenishment
As described above, until now we have adhered to the billing cycle of 3 days, which also allows for replenishment every 3 days.
What happens if replenishment is allowed whenever possible? The results are shown in the charts below.
The cumulative flow diagram shows the same throughput, namely 24 items over a period of 24 days. Work in progress is larger because it is pulled in earlier instead of at the end of every third day.
What is interesting is that the control chart shows a large variation in lead time: from 3 to 6 days. What I noted during playing the game is that at regular times 3 to 4 items are allowed to be pulled into “ready.” These would sit for some time in “ready” and then suddenly be completed all the way to “ready for deployment.” Then another bunch of 3 to 4 items are pulled into “ready.”
This behavior is corroborated by the control chart (staircase pattern). The larger variation is shown in the lead time distribution chart.
What is the reason for this? My guess is that the limit of 4 on the red loop is too large. When replenishment was only allowed at days 9, 12, 15, it basically meant a lower limit for the red loop. Tuning the limits is important for establishing a certain cadence. Luckily this behavior can be seen in the control chart.
In the getKanban Board Game, specialists on the team are represented by colored dices: green for testers, blue for developers, and red for analysts. Effort spent is simulated by throwing the dices. Besides spending the available effort in their own specialty, it can also be spent in other specialties, in which case, the effort to spend is reduced.
During the game, it may happen that utilization is less than 100%:
- Not spending effort in the specialty, e.g. assigning developers to do test work.
- No work item to spend the effort on because of WIP limits (not allowed to pull work).
The picture below depicts the utilization as it happened during the game: on average a utilization of 80%.
Companies can use POLCA to shorten lead times, reduce work in progress, and enable a faster learning cycle. Tuning the loop limits seems to be important for establishing a regular cadence. A “staircase” pattern in the control chart is a strong indication that loop limits are not optimal.