The last five or six times that I have facilitated the getKanban game (version 2) I have played with some modified rules.
Multi tasking
When attending the inaugural charter member meeting of the Lean-Kanban University Accredited Kanban Training program in Soestduinen, Netherlands we discussed a suggestion from a class attendee that I really liked.
The suggestions was that work should be done on all stories in the doing column instead of focusing the work on a single story at a time. I really liked this as it better represents how work is really done in the real world. It better simulates the multitasking done in most processes.
So how do the new rule apply in the game?
Below is three standard stories in the testing column as we are about to start playing day 9. I have taken stricken out six testing points on story S1 so the facilitators guide will more or less still work for day nine.
We role a four on the orange die for test and we shall strike eight points off the stories. So we start striking off one on S1, then one on S2 and then on S3. We have five more points to strike off so we start over on S1 then S2 and S3. We keep doing this until we run out of work to distribute. We pull work just as before up to work-in-process limits.
As a very positive side effect I have found that players will discuss the value of focusing your work and lowering the work-in-process much more.
Work-in-process limits
The Kanban method is all about evolutionary improve your process. But version 2 of the getKanban game had very few real process improvement points. So I have introduced the option to change the work-in-process(WIP) limits once every game day at the daily stand-up meeting. I give the teams full freedom to lower and raise the WIP limits as long as they pull up to the limits and clear out stories over the limit asap.
I usually coach the teams not to make any big changes as this very easily can totally destabilize the process. Make small evolutionary changes.
I have found that allowing the teams to adjust the WIP limits and questioning the reasons for why they made the change is a great learning opportunity.
Real Options/Class of Service
For the last two games I have facilitated I have made changes to how you play the intangibles and fixed delivery stories.
Now I let the teams decide how much work they want to spend on intangibles and fixed delivery stories when they are in doing columns. Combining this with the Multi tasking rule a situation could look something like this:
There are two standard stories and one intangible on the development column. We roll a six on the blue die. We now have twelve points of development work to spend. We decide that we want to prioritize standard stories but not neglecting the intangible. So we decide to only spend work on the intangible story every other pass of applying the twelve development points.
I have found that allowing the teams to use this rule makes it much easier to teach the value of keeping some options active in the system. It is also easier to explain different class of service.
End note
I have had the opportunity to play the pre-production version of version 3 of the getKanban game and it looks like some of the rule changes describe here will make it into the version 3 game.
Let’s go out and play getKanban!
