This blog is in response to a number of requests about creating Agile games. I have spent the last two years creating a number of Agile games and whilst I certainly wouldn’t declare myself and expert next to the amazing machinations of @lukehohmann of Gamestorming I do try to make games that are fun, educational, simple and easily repeatable.
In today’s blog I want to describe the journey and thought processes that I took to build a game that I call “Kanuzzle”.
It started about two years ago when Russell Healy first introduced Kanban to me through his amazing getKanban game. Russell spent considerable time, effort and personal expense to produce this high quality, repeatable instructor toolkit. I enjoyed the game and found it quite educational but did have difficulty with the setup time and the time it took to instruct on how to play the game. Taking that aside I felt the participants in the room were able to pickup the concepts embedded within and the competition levels were high which increased the fun factor of the game.
When I returned to Australia I tried to find some interest for Russell’s game but there was a perception that the game costs were too high (for an instructor to purchase). I was personally less concerned with this as I understood the investment Russell had made, but was more concerned about the maintainability of the game once purchased.
As time went on the needs that I had for a Kanban game grew away from getKanban. I needed a game that was less software focused and was easily digestible to business specialists who were using Kanban outside of software development. I also needed a game that was quicker to kickoff and one that could be maintained an enhanced. Production costs were an issue and management ideally wanted games that costed little more than paper and pens.
So given these new constraints I went about building a new game. To overcome the production cost issue the board I created was printed on A3 and laminated. Tokens and any other artifacts went through a similar production method. This resulted in kits that cost a little more than a few dollars. Additionally I wanted to build in more “chance” to the game and brought in a design concept directly off Monopoly building in “wildcards”. When a wildcard was landed on it represented the real life occurrence of an event that was either positive or negative to the team’s ability to deliver. The set of board steps was also fixed as opposed to getKanban’s varying cost to deliver a story. Using colour themes similar to Monopoly’s “set of hotels” I had colours that represented a number of board steps for a particular non software role.
Teams were given preset WIP limits for their board which was setup to deliberately be dysfunctional. After a few two person practices, I released my new “Kanbanopoly” game for training. The first few sessions resulted in some instructional tweaks but overall the exercise went well – I cut the exercise time down from 2 hrs to a 45 minute game. The game was run in three rounds (split among theory). The first round was the dysfunctional one. The second round the team were able to change their WIP limits as they saw fit against an overall resource constraint, in the third round they could change the WIP limits again. Team’s rarely got the WIP limit right by the second go but always did by the third.
But a few things concerned me about this variant. Firstly it was still taking too long for people to understand the instructions, especially the Cummulative Flow Diagram. Secondly people were having trouble making the leap between the game and what they were doing on an Agile basis from day to day.
So I did what any good game designer needs to be open to and totally scrapped it. My new requirement was that the game be runable within 30 minutes with similar production costs and a five minute instruction time.
What I wanted was the ability to have a massive wall and for the team to stand at the wall to do the exercise, in this respect it would be more closely aligned to what they were used to. But the problem was that they couldn’t deliver software in the classroom and I didn’t want them to do a manufacturing based game as I wanted to highlight the knowledge work element strongly. So I toyed with the idea of a game within a game and created “Kadoku”, a Kanban Sudoku variant.
Children’s Sudoku puzzles (of varying difficulty) were printed and a value was attached to them. They were then cut up and placed on the wall with a pre-setup WIP limit. Roles were given out and metrics were kept. The WIP limits were setup for success but deliberate defects were put into the puzzles to force certain roles to hit their limit and cause a flow issue. The game went fairly well as far as the lessons learnt. The instruction time was certainly reduced and the costs were even lower. Additionally it felt more familiar and transposable to the participants. But there was a serious issue. Defects took too long to resolve and the Sudoku execution itself was taking longer than expected with each puzzle taking between 8-10 minutes to get out. Simpler puzzles took too short a time being doable in under one minute.
So that variant was re-adjusted. I scrapped the Sudoku puzzles due to their complexity and went with simple kids puzzles that should be achievable by 7-10 years olds. The game was renamed to “Kanuzzle” and re-run. This game has now been running for about eight training sessions without further issues and is now considered final. The cost is about 20 pieces of colour paper and blu-tack. The setup time is about fifteen minutes to cut out the puzzles, blu-tack them and setup the physical board. The instruction time is about 3 minutes and in game running time is about 15 minutes. The design intent from a learning perspective is to get a feel of the Kanban concepts with a particular focus on WIP limits, managing flow, pulling work and handling expedites. People won’t be experts by any stretch, but they will be informed enough to now give it a try and self-adjust.
So lets take a look now at the things that you need to consider when building your own Agile game:
- Who is the audience? What will they know? What won’t they know? What terms may be unfamiliar for them?
- How much time do they have to play a game?
- How much time do you have to run a game in the context of the rest of the training?
- How much time will it take for you to preset/reset the game? Is this something that you can afford?
- How much time will it take you to instruct in the game? Is this something that can fit into yours and your participants training time?
- How much time does the game and any post-retrospective debrief take? Is this something that you can fit into your and your participants training time?
- How much do the physical gaming materials cost? Are they re-usable?
- Is the game maintainable? Can you adjust it and re-run with adjustment costs being minimal?
- What key messages do you want to get across? What agile practice(s), principles or values are you trying to re-enforce?
- What would be nice to get across if you had time?
- Can participants easily relate this to their work?
Also keep in mind general game building considerations that all games should adhere to (for more information checkout my Gamification and Agile slideshow):
- There needs to be clear and defined goals or outcomes that have to be achieved
- There must be a set of rules in place to limit how you go about achieving that goal
- The environment must provide feedback to tell participants how they are going or whether the game is ended
- They must be voluntary
In the case of Kanuzzle the answers to these last four questions are:
- Achieve the most value. Two teams compete against each other. By default the puzzles are ordered according to sequence and not value, part of the design intent is to get them to spot that the backlog is not value prioritised and then to re-adjust it.
- Limits are enforced by WIP limits on the board and through rules for handling expedites and roles for the game. Roles are loosely set so ideally by the end of the game no one cares about their role, they are just focused on the flow. Additionally by forcing an error into the flow early it forces the team to deal with flow issues and understand what it feels like and the impacts that it has.
- Feedback is provided via timing each puzzle and through provision of graph tracking. Instructors also give feedback on game end time.
- They must want to learn and participate in training