“In order to shorten the time to market of development work, we need to decrease the amount of work in progress (WIP).”
The principles of Kanban such as limiting work-in-progress can seem counter-intuitive at first.
This basic idea of maximising the flow of work in Lean and in Kanban is deceptively simple. So deceptively simple that in fact it is hard to believe. That is because it is counter-intuitive and also counter to traditional beliefs in software development and project management.
How can we then illustrate this idea to people in our organisations who hold the traditional beliefs of project thinking?
Concrete experience is key
I’ve found out that there is no shortcut or a perfect argument to turn people’s heads. Instead, they have to have an experience that gives them an understanding of the theoretic concept in a concrete level. Ideally, they would have this kind of experience in their everyday work, but that can take too long.
So I’ve found another way: a game!
Understanding limiting WIP through a game
In my Kanban workshops and trainings, I facilitate a game called “How long does it to write a name” by Henrik Kniberg to illustrate the difference in flow thinking and project thinking. One result of the game is a hand-drawn graph showing the difference in time to market between batch-based working and limiting work-in-progress.
This leads to conversation about which type of diagram would the participants draw from the work in their everyday context. At this point I see the “Aha!” light spark in the participants’ eyes.
Why does this approach work?
Changing thinking and assumptions is not easy. There is a resistance in our minds for this kind of change and it is for a very good reason: Otherwise, we would be very easily convinced by people skilled in doing so, even gullible.
In order for my thinking to change, I need to be able to experience something new and be able to anchor this new experience to my previous experiences and assumptions in order to form a new working theory on how things work. For this to happen, I need to be in a receptive state. Staying in this kind of receptive state is not easy: it demands a safe situation, one that allows me to consider new information and experience in peace, and not feel pressured to make a judgment call on its worth or accurateness.
Games provide concrete experience, distancing safety and the possibility to reflect together to facilitate learning.
Games and play facilitate this process in three ways: first, they offer a concrete context to experience an example of how theory works. Second, they distance the experience from your everyday context and from your earlier assumptions on the subject by giving you a fictional play context. This fictional play context also provides a safe environment for exploring new ideas and theories.
Finally, reflecting together about the play experience allows for generalising the experience to form an understanding about the theory behind the game. Reflecting on the game as metaphor of your everyday context, meaning work, allows you to anchor the playing experience and the insights gained from that to your thinking about how work works.
How to use games for learning Kanban
So, to use playing games to facilitate learning of Kanban principles, you need to:
1. Use a game that gives an experience of some part of Kanban principles in action
As I mentioned above, I use “How long does it to write a name” by Henrik Kniberg to demonstrate flow thinking and the effects of limiting work-in-progress. The other game I use regularly is the Ball Flow Game by Karl Scotland. I use that to demonstrate collaborative improvement and the need to visualise workflow and to make process policies explicit. There are many other games out there, but these I’ve found to work myself.
2. Help participants distance themselves from their work context.
The choice of game is important here. Many trainers and coaches like to do workshops with the actual work that teams do, which is great for many things, but lacks in this respect. Abstract games, games with fictional backstories and silly games work well in this respect.
“How long does it take to write a name?” game goes in the fictional and silly categories. The idea of a developer with the special skill of writing attracting multiple customers needing him to write their names is silly and distancing enough for most people. The major drawback of this game is also its silliness: some people refuse to find similarities with this kind of silly premise to their own work. But those have remained a very small majority in my sessions.
Another thing that helps is to start with playing the game and not the theory part. That enables the participants to be open about what their experience in the game rather than play out the conflict between their existing assumptions and new theories they just have heard about whilst playing.
3. Facilitate the participants to reflect how and in what ways the playing experience mirrors their experiences at work
To learn about Kanban principles in isolation can help. But if the participants cannot anchor their new knowledge into their existing knowledge and assumptions about their work, the new knowledge has little chance of surviving in long term. That is why it helps if the coach facilitates the participants to reflect on the similarities and dissimilarities between their playing experience and their past experiences at work.
After “How long does it take to write a name?” game I ask the players to look at the different lead time charts produced by the multitasking and limiting WIP working modes. Then I ask them: if you would draw a lead time chart from your own work, which of these would it resemble more. This leads to interesting conversations and reflection between the players, the “Aha!” moment I described earlier.
4. Facilitate the participants to reflect together how their playing experience ties in with Kanban principles
A game can make the effects of multitasking more concrete than a mere diagram does. Source data for the diagram: Gerald Weinberg: Quality Software Management, vol.1: Systems Thinking.
Just playing the game is not enough to facilitate learning. A good coach helps the players reflect what happened in the game with powerful questions to let them see how their experience relates to Kanban principles that the game demonstrates.
In “How long does it take to write a name?” game debrief, after reflecting the experience in general and anchoring it to the players’ own experiences, I introduce some facts on the effects of multitasking and then introduce Little’s Law. We discuss these and come back to the playing experience regularly to give us shared examples.
Now it’s your turn
The above 4 points should help you maximise the effectiveness of your learning games at Kanban workshops and trainings. Now it is your turn to experiment. You could run a full-blown Kanban workshop, or you could use these games like my Flowa fellow Ari-Pekka used to: use the game as a catalyst for discussion on the subject in your organisation.
Please let me know how it went in the comments!
By the way, I’m hosting two workshops on Understanding Kanban through Games at Tampere Goes Agile 2014 this Saturday (October 25th). See you there if you are coming, too!
Antti Kirjavainen is an experienced coach and a linchpin. Antti is full of energy and has many interests – he is a knowledge work management thinker, product development coach, a Licensed Management 3.0 facilitator well as an active member of Agile Finland Ry, Agile4HR Finland and Agile Lean Europe network.