How I would simulate time-boxed agile in the @getkanban kanban board game

At Agilesparks we’ve recently been using the Kanban Board Game developed by Russell Heally (@getkanban) quite extensively. We use it as part of Kanban courses, sessions for Scrum teams that want to learn about Kanban, Kanban teams that are already working and want to raise their game, as well as in Kaizen sessions for project management teams.

We love what the game does, and it has actually become a challenge to coordinate which of us has the game kits at any point in time, especially because in large events we need 4 kits so we need to borrow from one of our nice clients that has 2 kits as well…

One idea we’ve been toying with for some time, is that it would be great to use something like this game to accelerate learning of Scrum as well. At a minimum, one of the questions I’m adding to the debrief for Scrum teams, is how would Scrum look like in this game, and what would be the effects. It seems clear to teams that Scrum would reduce throughput due to the need to clean the board every sprint, which means less ability to take advantage of the speciality of the Analysts/Developers/Testers. It would also make the game run slower due to the overhead of planning…

I’ve been reading some ideas from David Anderson and Russell about this, which helped me along. I’ll provide my take on this, but first a brief overview of the game to those not familiar with it.

The game simulates a process workflow where there is a stack (backlog) of cards which represent stories for development. The cards are pulled into a READY area, then pulled into Analysis, Development, Testing and finally deployed. There are different types of cards representing different work types/classes of service – a normal business value card, a fixed date card, a quality card, and an expedite card. Each card specifies the amount of work required to process it in each station, which provides the variability between work items so typical of product development and other knowledge creation areas. Another form of variability is the fact that how much work you are able to do each day is decided by throwing dice. You have dice in different colors that represent specialists in each area (Analysts, Developers, Testers), and you as the team playing the board can decide where to use each dice each day. Either use it in the specialty area of that person and gain a multiplier, or use it elsewhere without a multiplier. The game is played in cycles of days – each day you decide your strategy, throw the dice, play the game, update visibility charts, and also handle an event that might throw you some additional curve balls… That should suffice as a quick intro to understand the rest of the post, or at least as a teaser to find the opportunity to play the game. It really is highly recommended to anyone interested in Agile / Kanban / Scrum / Games. Exceptional work by Russell.

If you noticed so far, the game indeed simulates kanban. No time-boxes or batches, just flow and flow and flow. The only area where you get some sort of sprint behaviour is towards the end of the game. If you are approaching the end of the game and the teams know its coming, they will start to prefer cleaning the board and deploying items, rather than maintaining flow. That makes sense. If you announce end of the game on day 24 for example, but finish it a few days early without telling the teams, you will get flow behavior all the way to the end. You can play with that, depending what you want the teams to experience, and whether you want to have the timebox behavior as a pattern to discuss in the debriefing.

In general, it shouldn’t be too hard to make the adaptation of the whole game to timeboxes/sprints. maybe the biggest challenge is to have teams see the name Kanban on their new shiny Scrum process training ;-)

But seriously, the main thing you need to take care of is the sprints. The concept of 3 day billing cycles in the game can be extended to portray a sprint. You would start the cycle with planning what cards you will work on in the cycle. This requires looking at your velocity in the last cycle, your capacity (cubes and statistics…) thinking about changes that were made in the environment (Carlos etc.), and the cards that are currently in the backlog. You would commit to what cards you plan to deliver.

Which gets us to the backlog… The trivial option is to make the READY area the backlog, and only pull into the READY area (into the board actually) cards that fit into the planning. This is not perfect though. For starters, how do we model the work that is done by the Product Owner? In addition, the whole flow from READY through analysis, development, testing might be a bit too long for a 3 day cycle.

That brings me to an alternative I’ve been thinking about – make the Analysis phase the work of a “Product Owner”. Use the analyst dice to represent the Product Owner, and the “Analysis Done” area the “Sprint Ready” backlog the teams can use for their planning.
This has the benefit of portraying the Product Owner work, it reduces the cycle time within a sprint which I think will provide a more reasonable simulation within a 3 days cycle, and can also bring about a discussion of the wastes of too much sprint ready backlog, versus a team that runs dry during a sprint. (Which is one of the common problems with Scrum teams, and a big benefit of doing this game with them I think)

So assuming the Analysis Done was the sprint candidate/ready backlog, the team does planning, pulls the planned stories into another queue between Analysis Done and Development in progress, which we can call – the Sprint Backlog

A sprint will be 3 days where the team works to finish and deploy all the cards in the Sprint Backlog – processing them through Development and Testing. Within this sprint the team also needs to take care to replenish the “Sprint Candidate/Ready Backlog”, because remember at the end of the cycle, there is another Sprint Planning, where they will need to have enough candidate cards that they can pull into the Sprint Backlog, to avoid starvation in the sprint. To properly simulate a real Scrum environment, it shouldn’t be allowed to pull cards within a sprint, because it is harder to plan within a sprint.

For advanced uses and for those Scrum people which are crying this is not fair, we can discuss a couple of options. One option is to allow pulling stories, while paying a fine for it to represent the cost of replanning. For example, you can put one of the dice on planning a story instead of executing it. Another option is to allow pulling quality cards during a sprint.

In general btw, we need to think how to portray the cost of planning. In a typical stable Scrum team, there is a cost of about 2-3 hours of planning per a 10 day sprint. This is about 4% which should be negligible in the game. Another option is to just compare the time it takes to do rounds of flow versus timeboxed rounds in the game and see what is the actual time it takes to run the game… I would expect flow to run much faster than the time-boxed version… but need to try it!

At the end of a sprint, what would happen is that you expect to have clean Sprint Backlog, Development and Testing stations, with all the cards deployed already. Any work that is not completed will probably be continued into the next timebox and should be included in the plans. I’m thinking a fine should be included here – every card that spills to another timebox should have a few points of work added to it (e.g. if there are 12 development points, the team finishes with 6 points of work left, in the new timebox there will be 6+3 points of work)

What would happen to Cycle Times? I’m quite sure cycle times will be much higher for a team doing timeboxes. The need to keep a queue of work ready for sprints will probably add about 2-4 days of cycle time, depending on how the team balances safety of having spare stories, versus the waste of having a story decay in the queue. Since the game doesn’t model a price for decaying stories, I assume teams will prefer more in the queue. The only thing that will stop them from doing that is limited amount of analysts… need to try it but I’m guessing there is a chance that the analyst will not be able to keep up, or at least we need to create scenarios that impede him from keeping up (e.g. blockers in analysis, reduced capacity of analysts, or taking stories that were analysed and cancelling them so now analysts have to rush to replenish the ready stories queue)

The event cards are another area which might need tweaking. For one, some events are unfair to introduce in the middle of a timebox because the team should know about them when planning. Need to look at them and align them with the timeboxes as necessary. Beyond that, some new kinds of events can be leveraged to spice up the timeboxes game (see above for example)

Will the effect of time-boxes be realistic enough? The concern is that if the time-box is too short, it will be hard to deliver stories and run an effective time-box. Similar to what teams experience when the story size is too large for the sprint. Basically, need to play around with it and see… I think that by removing the Analysis from the sprint itself I reduce the chance of this happening, but maybe its not enough. Worst case can play with multipliers on the cubes some to make the team capacity higher compared to the work, or strengthen the effect of the quality cards…

The WIP limits go away in this variant I think. The WIP limit is the Sprint Backlog which is time-based, not station based. An advanced team can decide to use WIP limits on the stations to work more effectively, or we can re-introduce the WIP limits as an event card during the game. While on this matter, a question I usually ask teams in debriefing is what would happen if there wasn’t a WIP limit. The answer I hear is that they would probably start more work than they can finish, and throughput and earnings will go down. QED :-)

I think this is enough for one post. Should give you ideas how to play with the Kanban game in a time-boxed manner. There are probably other aspects that need to be taken care of, but lets be agile about it folks…

I’m hoping to try this on my own, probably with the AgileSparks team, sometime soon, and report. In the meantime, any comments or ideas are welcome.

And again, thanks Russell for the great game, which probably deserves to be a platform, with endless options of what to do with it. If we could have this as a Lego kit that we can play around with, it would be amazing.