Dancing with GetKanban (Using POLCA)
Very recently POLCA got some attention on twitter. The potential and application of POLCA to knowledge work I explained in my blog ‘Squeeze more out of kanban with POLCA!‘ [Rij11] of 4 years ago.
In this blog the GetKanban [GetKanban] game is played by following the the initial ‘standard’ rules for handling Work in Progress (WiP) limits and by changing the rules of the game inspired by POLCA (See [POLCA]).
The results show an equal throughput between POLCA and non-overlapping WiP limits, with smaller inventory size in the case of POLCA way of approaching WiP limits.
First a short introduction to the GetKanban game is given and a description of the set-up together with the basic results.
Second a brief introduction to POLCA is given and the change of rules in the game is explained. Thirdly, the set-up of the game using POLCA and the results are discussed.
Finally, a few words are spent on the team’s utilization.
Simulation: GetKanban Game
The step-up with standard WiP limits is shown below. The focus is on a basic simulation of the complete 24 project days of only 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. Reason being to get a ‘clean’ simulation showing the effect of applying the WiP limits in a different manner.
Other policies 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
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) 10 items are in progress, (b) throughput is 25 items in 24 days, (c) median of 9 days for the lead time of items from Ready to Deployed.
Interesting is that the control chart (middle chart) shows the average lead time dropping to 5-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 in a new stable state with 5-6 as an average lead time compared to the 9 days at the beginning.
POLCA: New Rules
In POLCA (see [POLCA]) the essence is to make the WiP limit overlap. The ‘O’ of POLCA stands for ‘Overlapping’:
POLCA – Paired Overlapping Loops of Cards with Authorization
One of the characteristics differentiating POLCA from e.g. kanban based systems is that it is a combination of push & 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. E.g. 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. has fewer cards than the limit, b) the next, or overlapping loop, has 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 in ‘Ready’ because there is no capacity available in the blue loop (Rule 2)
Example2: Two items in ‘Test’ & two items in ‘Analysis – Done’
One item can be pulled in ‘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 6 days for all existing items to flow out of the system. The effect of the new rules (POLCA style WiP limits) are 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 enough to the through put 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 ‘One change at a time‘ [Rij15] getting feedback from improvements/changes that effect the flow of the system take some time before the system settles in the new stable state.
With POLCA it is expected that this learning cycle can 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 rules 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 when possible. The results are shown int he 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 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, … this 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 game specialists in 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 speciality, it can also be spent in other specialities 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 speciality, 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 happened during the game: on average a utilization of 80%.
In this blog I have shown how POLCA style of setting WiP limits work, how overlapping loops of limits help in pulling work fast through the system, and the positive effect on the team’s learning cycle.
In summary, POLCA allows for
- Shorter lead times
- Lower work in progress, enabling a faster learning cycle
Tuning of 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.
[GetKanban] GetKanban Game: http://getkanban.com
[Rij11] Blog: Squeeze more out of kanban with POLCA!
[Rij15] Blog: One change at a time
[POLCA] POLCA: http://www.business-improvement.eu/qrm/polca_eng.php