The open-source getKanban game is a great learning tool, but its affordability comes at a price. We still like it. Here’s how we are adapting it to better suit our objectives.
Andrew, Steven, and I have been using the open-source version 2 of getKanban in our new Agile Foundations course. Thanks to the heroic efforts of Mykaela back at the office, we’ve been able to travel with lightweight disposable game kits and have run it 20+ times across Seattle, London, and Budapest.
During our first sessions in London, Steven, who has played the game (and its successor versions) zillions of times, wanted to hack the rules; I, who had never played it before and am sensitive to the interconnected nature of game mechanics, insisted we must not tinker with it. I won the battle, but Steven won the war. Long after Steven had flown home for quality time with his new baby, Andrew and I ran the game many more times and grew frustrated with its limitations. It teaches the mechanics of Kanban well enough, but team after team taught themselves the wrong lessons about Lean! (See also: Underpants Gnomes.)
So, at last, we hacked the game.
What we hacked and why
We set up the games during a tea (it’s London) break, and I commandeered a flipchart for the hack and a few general tips, in roughly chronological gameplay order (see image):
1. Because teams consistently set aside the stories they’ve already accounted for in their finance charts every third day, and then lose track of them and screw up their Cumulative Flow Diagrams. Most teams improved upon this suggestion by making a Paid substate at the bottom of their Done column instead of to the right, which works better because it keeps them all inside the orange border where they can more easily be counted. About half the teams screwed up their CFDs anyway.
2. Just to make it easier to do the finance charts. It helped. NBD.
3. This is the big hack and requires further explanation below.
4. I originally wanted this to be “reduce, but not increase”; Andrew said I was making it too easy for them so we left it generically “alter”. Sure enough, every single team who changed their WIP initially raised it.
I also created a separate flip chart listing the seven Lean principles we taught the day before. I wrote Limit WIP in the brightest color and made it slightly larger than the other six. Andrew said I was making it too easy for them.
Learning objectives and how they are thwarted
You start getKanban on Day 9 with a board full of stories and some WIP limits, and you’re meant to discover that your cycle time is averaging 8-9 days, which is far too long. The economic model of the game punishes teams quite severely for long cycle times. This begins to dawn on the teams and there are a few things they can do to try to improve:
- Reprioritize stories (pop the most expensive ones to the top of their column to push them through faster)
- Reallocate personnel (designers, developers, and testers swarm to help clear blockages), represented by dice
Teams quickly gravitate to these two strategies, not realizing that they are only optimizing the speed at which items move from one column to another—not the speed of the whole system. As they expedite individual items, the cycle time for everything else in fact gets worse. What we really want them to understand, but which the game doesn’t offer any direct clues about, is to reduce cycle time systemically by:
- Limit Work in Process
We spent considerable time the day before teaching them how Little’s Law proves, using math!, that limiting WIP is a leading metric for cycle time. But it’s a new day, and they’ve all forgotten.
The trouble with Carlos
Firstly, there’s someone on our customer’s team called Carlos. He’s a delightful person and not at all deserving of the animus directed at getKanban’s evil test manager character Carlos. He attended our earlier, pre-hacked training course and handled the evil character with much grace. (If I were to keep playing with evil Carlos, I’d definitely want to Photoshop a goatee onto a picture of delightful Carlos…)
The worse problem with evil Carlos is that the appearance of his character and his evil rules is a distraction from the Lean principle we most want them to learn: that to reduce cycle time systemically, they need to lower WIP.
By the time Carlos appears, nearly all teams have begun to figure out that their Kanban boards are telling them bad news, and most teams are attacking this problem with a little bit of reprioritization (the game, awesomely, intentionally makes this difficult by presenting many competing but hard-to-compare incentives and risks) and a lot of reallocation of dice, I mean personnel, especially to the Test column, which by now has emerged as a bottleneck. Carlos’ evil rule is that personnel may not be allocated into or out of Test. It takes that tactic off the table for several days, enough for a massive queue to build up ahead of test, leading to uncontrolled congestion and blocking the rest of the team.
Unfortunately, nearly all teams want to attack this problem by increasing WIP in Test. Their devs and designers aren’t allowed to help clear the Test queue, and Carlos is pissing them off, so they see no option but to make it Carlos’ team’s problem. Just like life, isn’t it? They win the battle and lose the war. Their designer and dev dice are back up to full utilization, piling more work into the Test queue that’ll never be completed. By the time (spoiler alert) Carlos gets fired, even with the onboarding of a new tester die, the queue’s grown too gnarly to clear before the game ends.
Even though Carlos is supposed to take resource allocation off the table, in real gameplay it tends to cause teams to rathole on resource allocation and ignore WIP, or misuse it in frustration. They don’t learn what we want them to learn.
And so, hack #3. We killed Carlos. (The one with the goatee.)
(I made one error in the details: about half of our teams, heeding the instruction to “ignore Carlos”, ignored all instructions regarding Carlos, including the one where he [spoiler alert] gets fired, so they overlooked the good news therein about hiring another tester and thus never added their third tester die.)
A better way?
Our six teams started their hacked games the same as always, with Andrew leading them through Day 9 (the game’s starting day) step-by-step, prescribed-dice-roll-by-prescribed-dice-roll. This level-setting first day is quite helpful in managing large groups and multiple game boards. He had to use his Unruly Class Voice to be heard most of the time—teams engage with this game right away and they’re eager to get going.
As the teams started Day 10, trying to navigate the game’s confusing rule set on their own and handle their own now-random dice rolls, we strolled around, answered questions, and tried to catch errors. I dropped hints to the teams about the kinds of choices they should consider making:
“You’ve got the fixed-date audit story on the board, good. You started it on Day 9? Great.
“When’s it due if you want to avoid that big fine? Day 15?
“And what’s your cycle time right now? There on your Control Chart 9 days? So at that rate when’s it going to be done? Day 18? That won’t work, will it?
“Hmm, what can you do to move that story through faster? I see you’ve reprioritized it to the top of the Design column. That’ll help. What’s another way you can reduce your cycle time?”
After a few circuits around the room, I discovered that one team with whom I’d had this conversation, with a team member who’d seen the game played before, had raised their WIP limits.
That’s it. I’m not going to take this anymore.
A great big hint they cannot possibly miss…
I stomped up to the front of the training room.
“Andrew, I need to project that Little’s Law slide.”
“No way. You can’t just tell them. That’s too easy. They need to learn it for themselves.”
“But they’re not learning it for themselves. We’ve done this twelve times and they never have. I think we need to coach them to get it properly.”
“It’s too much.”
“Just enter your password and open that deck.”
(This is, by the way, a total role-reversal from our normal M.O. in consulting and we argue about that too.)
… which they missed
We were both wrong. The hint on the projector wasn’t too much, and it didn’t help them get it. I strolled around, I called teams’ attention to Little’s Law, I flat-out told them that limiting WIP is mathematically proven to reduce cycle time, and at one point I literally jumped up and down pointing at the screen.
None of the teams lowered their WIP.
A chance encounter
We told teams to self-organize their comfort breaks, so after several days of gameplay I happened to run into Fiona, a Product Manager, in the ladies’. She was quite bothered by the state of her team’s game board.
“I don’t know how to explain it. I know there must be several stories stuck on the board where we’re going to lose money because they won’t be done in time because our cycle time is too high. I feel like if I could just do the mental arithmetic, those stories would be flashing red at me, but I can’t do the math quickly enough, and I can’t explain it to my team! It’s so frustrating!”
Her team consisted of herself and two senior developers. I told her to find a notepad and do the math with a pencil and show it to them. They’re devs, I said. They respond to math.
“And while we’re on the subject of math, have I mentioned how Little’s Law proves mathematically that lowering WIP reduces cycle time?”
Fiona headed back to the training room in search of a pencil.
Show, don’t tell
In previous training classes during the game wrap-up discussion, Steven had told us that if you drop the game’s starting WIP limits from 6, 3, 5, and 3 to 3, 1, 1, and 1, you’ll get to where you can deliver multiple stories every day with an average cycle time between 1 and 3 days. No one ever believed him, because their gameplay had gone so differently and the image of goateed Carlos was fixed in their minds as the reason for it.
This day, Andrew and I realized: Mykaela packed us a spare, seventh game kit. I brought a quart of Chessex six-sided dice from home, so we had plenty. The teams are playing self-sufficiently enough, and since we know the rules quite well, it wouldn’t be hard for us to make up the head start they had on us time-wise. Why not crank out a game of our own with the WIP limits we want, and prove to the class how much better it works?
We hurried to set up the board and rushed through Day 9, honoring the game’s WIP limits at first so as to start Day 10 in roughly the same situation as our teams had done. Then we dropped them down, but not to 3, 1, 1, and 1. We picked 2 for the Ready queue, 1 for Design, 3 for Dev because the dev effort required on stories tended to be large, and 2 for Test because we still had a testing bottleneck and queues that we knew would take time to work through. We planned to drop WIP even further when things cleared out.
And that’s when things went not at all as I/we expected.
A difference of
We started deploying stories fast, and like everyone else we swarmed dice on Test to clear the queue there. But as I ran the Control Chart, our cycle time didn’t fall. Day after day, it in fact grew worse: from 8 up to a solid average of 11 and a high of 12. 12! Just like all the other teams, we were delivering plenty, but we started to lose subscribers and money because we couldn’t bring our cycle time down. Even with every single resource swarming Test, and halfway decent dice rolls, the queue remained stubbornly in place, and the Dev queue behind it wasn’t shrinking either.
We discovered Design’s WIP limit of 1 made it 50-50 on any given day whether we’d starve it, or congest it so we couldn’t start anything new. With Ready’s WIP limit of 2, if we got blocked by the limit in Design, we couldn’t introduce new stories onto the board at all, which meant we couldn’t reprioritize to get high-value stories through as their deadlines approached.
We survived the financial audit without a fine—just, and only because we’d put it into Ready on Day 9 when the WIP limit was still 6! You can see its little trough there on the control chart: we moved heaven and earth to push it through in 4 days, which as it does for every other team meant that the cycle time on the stories behind it went up for a while.
The end of the game approached and I couldn’t believe I was still plotting in the 10- and 11-day cycle time range!
Finally, as you see, things cleared out and our last two stories had the promised land: blazingly fast cycle times of 3 days each. And then we ran out of days!
We finished the game with about $15,300 on our finance chart, but I’m not sure this was so much because of WIP as because we knew which stories were the highest value, so we could game the economic model. (We also screwed up and forgot to apply the Blocked sticky at the proper time; we did it a day late. This gave us a small-but-cumulative financial advantage because at least one story deployed before it should have.)
We deployed nineteen stories. The only ones we managed to get onto the board ourselves were the same ones we flew through in 4 days, 3 days, and 3 days. All the others came out of the start-of-game queues.
So what happened?
You start getKanban on Day 9 with a board full of stories. 17 of them. The clock’s already started on their cycle time.
When you lower WIP on a column with items already in it, you don’t push the stories back in time: you just wait until you move them forward out of that column, and you decline to replace them, until you’re under your new limit. So those 17 stories are sitting in expensive queues, and no matter how early you lower WIP, the queues remain. And the queues kick your ass, even if you are a high-powered consultant who’s supposed to know what you are talking about with respect to cycle time.
We hypothesize now that our WIP limit choices may not have been ideal. We were guessing. Perhaps it would have been better to squeeze down WIP from the leftmost column first, gradually to the right as the queues moved along, rather than tightening the bottleneck at the end while there were already multiple queues behind it.
Maybe better dice rolls at better times would have saved us. (We think the dice have tiny goatees, and we are inclined to blame them for our problems.)
Meanwhile, our teams finished their games with a really similar frustration level but without blaming the evil Carlos. Most teams made a bit of money; about half lost the $2,200 to the auditor fine; about half reduced their WIP; only one of those really saw their cycle time start to drop before they ran out of game days.
Which team reported that lowering WIP really helped their cycle time, and had the Control Chart to prove it?
Not me and Andrew.
What have we learned?
I went into getKanban (repeatedly, on more than one continent) certain that the lesson I was teaching with it was that lowering WIP reduces cycle time.
I think I was wrong. At least partly.
I think the first lesson of getKanban, with or without evil Carlos, with or without lowering WIP, with or without evil dice, is that queues suck.
Another thing my very smart colleagues have proved, using math!, is that once a queue has formed, it’s impossible to get rid of by normal means alone; extraordinary effort is required. In the game, you swarm the dice and hope to roll a crit. In software development, you declare a bug bash or a stabilization sprint or a tiger team or some other special project effort to clear whatever your queue is: defects, untested code, disruptively innovative features, or technical debt. In-game and out, it’s expensive and it takes time.
The danger and stubbornness of queues is a powerful lesson indeed. Playing the game, more so than hacking it, helped us instructors understand that getKanban version 2 teaches this painfully well!
What about cycle time?
Fiona’s team saw modest-but-noticeable improvements in cycle time after they lowered their WIP. I think there’s hope for this lesson too!
- Rest in peace, evil Carlos. We’re keeping you dead.
- I still like giving teams hints.
- We’ve talked about extending the number of days in the game, to allow teams to see and feel the unwinding of the queues more effectively. This is potentially challenging only because new players can take a long time just to get through the days as written (and there’s always one team that falls behind and gives up entirely).
- Steven keeps telling us how the later (expensive, non-open-source, non-travel-disposable) versions of getKanban eliminated dice entirely in favor of standardized effort cards. No randomness means all variation in outcome can be traced to teams’ in-game choices, which makes the impacts clear and allows for meaningful comparison with other teams.
- We’re threatening to write a getKanban version 2 simulator to play through all the variations of WIP limits that we now want to try. (One of the many perks of leading the NWC Practices Team!)
Have your say
Have you learned, or taught, the value of lowering WIP or eliminating queues to shorten cycle time? What was your a-ha moment? What, if anything, persuaded you that it would work?