I did my second demonstration of Kanban yesterday, this time with my own team. As before, I used the getKanban game to give teams hands-on experience with a sample Kanban-driven workflow.

Unlike the first time with our sister team, this time I had remote team members to consider. Having forgotten my tripod at home, I ended up making a makeshift webcam stand out of common office equipment. It generated some interest from passers-by as I experimented with it at my desk. Satisfied with the picture quality, we used meeting software so the remote team members could follow along.

Gameplay

The team took to the exercise well. In the game, players portray a software delivery team creating features that attract service subscribers.

I don’t want to give away the events in the game, so I’ll speak generally. During the first few simulated days, the team decided to take turns with the various game roles. This did lead to good cross-training, but it also led to longer turn times and some mistakes in the cumulative flow diagram.

I was keenly interested to hear my team discuss the challenges that arise during the game and to watch them learn the concepts the game is designed to promote: how Kanban helps identify bottlenecks, swarming resources to relieve bottlenecks, classes of service, WIP limits and their effects, and the like.

For example, there’s a situation where players are exposed to a fixed-date deliverable. There was a spirited debate about the return on investment of completing the feature. Some players thought the penalty for not completing the feature would be offset by concentrating on revenue-producing work. Having played this game a half-dozen times or so, I hadn’t seen any team take that option.

The game also introduces intangible class work items, ones that do not lead to direct subscriber gain. The team saw some intrinsic value in them (upgrade database, refactor problem area of code), but they agonized over when – or even whether – to start them. They kept lamenting, “if only we knew what the benefit of working these is.” I smiled as I told them, those indirect benefits are why they are intangible.

The team turned to our real product owner, one of the remote team members watching by webcam. He helped them intersperse the intangibles with standard work items. In the end, though, the team discovered the benefit of working those intangibles too late for them to make a financial impact. Nevertheless, the team did very well at generating revenue for the simulated company.

Conclusion

I recommend the game to any trainers who are introducing a Kanban flow. The company has a copy of version 2 of the game, which is what I used. I’ve played version 3, and while it does have some interesting options, version 2 is quite effective. Better yet, if you are interested, the makers of the game have made the print files available on their web site, so you can make your setup.

If you have an option, I’d recommend gathering enough people to do two teams. The competition would have accelerated game play and made it seem more like a game than an exercise. That having been said, it was effective with a single team.

My boss attended the demo. He has some experience with Kanban already, and he remarked how effective the game is at making the Kanban approach concrete. Many times, when describing Kanban, he’s found people get the idea that it’s intellectual and theoretical, whereas Kanban is the opposite. It’s a very practical tool, forming a window into whatever process you currently use. To my delight, he also became more dubious of a purely digital Kanban board as he saw the team connect with the physical game pieces. With remote team members, though, it may not be avoidable.

I consider the exercise a great success. The team went from tepid to excited to implement a Kanban board alongside the scrum tracking we already do. My boss has asked me to facilitate a session with his development management peers, and the PMO group is interested in one as well.