getKanban is a board game, which enables you to learn and practice Kanban in software development.
- Kanban is Japanese. “Kan” translates visual and “ban” means card
- Kanban is a process tool
- Kanban works as a pull mechanism (as opposite to a push mechanism)
- Kanban visualizes flow
- Kanban limits work-in-progress
- By limiting work-in-progress, bottlenecks in the flow will become visible
By visualizing bottlenecks, there’s an opportunity to improve the process flow (to remove the bottlenecks, to remove waste, and as a consequence, to better match capacity with demand in the different stages of the flow)
Kanban applies control by measuring lead and cycle times – by improving the flow you can improve those lead and cycle times, and therefore optimize the flow to get work at a higher rate through the flow.
Kanban originates from lean manufacturing. A kanban card is a message, it signals the depletion of goods (products, parts, inventory) to an upstream part of the process.
Conceptual diagram of a Kanban system; http://files.iquijada.webnode.es/200000139-034270535c/Kanban4.png
When received, the kanban card triggers the production requests of those goods. Therefore, the consumption of goods drives the demand for more production of the needed goods – so kanban enables a demand-driven system (a pull system). A demand-driven systems aims to minimize (or even eliminate) inventory; just-in-time production; higher flow throughput, and therefore aims companies to become more production efficient. Lean manufacturing specifies a number of forms of wastes and origins of waste.
Kanban itself comprises of set of very simple rules, but (by years of application in lean manufacturing and almost a decade in software development) it has demonstrated its powerful abilities to trigger self-reflection, collaboration and process improvements. It has its roots in lean. Lean thinking’s pillars are respect for people and Kaizen.
The game setup consists out of a board, a stack of cards (backlog items with a certain value and effort to complete for analysis, development and test), a number of works (analysts, developers, testers), and the necessary charts (financials, and Cumulative Flow Diagram).
When playing the game you quickly learn about the pull mechanism, the effect of limiting work-in-progress and use of the fast-track (expedite) lane and specific impediments (problems, interruptions …).
The start of the game is at day 9 of a project (the context is a web application development with a customer-subscription based revenue model) – so you enter the game with some items in progress. The game can be played in quick play (till day 15), standard mode (till day 21) and advanced mode (till day 24).
The initial state looks like this:
As you see, the work-in-progress limits are respected:
- Maximum 4 cards (items) in the ready column (stage of the flow)
- Maximum 2 cards in analysis
- Maximum 4 cards in development
- Maximum 3 cards in test
- No maximum in ready to deploy
- No maximum in deployed (which basically means “finished”)
Now it’s up to the team to evaluate the state of the board; the game is played as following:
Assign workers to the different phases (analysis, development, test) – the workers are represented by dice. The number you throw with the dice gives you the number of effort units you can do for a particular phase and you consume these on the items on that respective column on the board.
Items are pulled through the flow starting at the end of the flow (so from the far-right column: deployed). As you spent your effort points (dice points) on items you will subsequently pull items through the flow, but pay attention to respect the work-in-progress limits.
At the end of the day:
- Read the event card (the event may be positive or negative)
- Add the numbers of the Cumulative Flow Diagram (CFD)
- Tick off end of the day
Cumulative Flow Diagram
Cumulative Flow Diagram is a tool used in queuing theory. It shows the evolution of the flow in its different stages and the queue of items being built up before each stage. It shows the size of the queue (vertical line) and the lead time (horizontal line). Lead time indicates the time from request till delivery. Cycle time starts when actual work begins on the request and when the item is ready for delivery.
Every 3rth day (day 9, day 12 …) it’s billing time.
- You deploy read-to-deploy items
- You cash-in your newly earned user-subscriptions (newly deployed features attract new customers) (new subscriptions gained are written on the back of each card)
- You replenish the ready column with items from the backlog (respecting the work-in-progress limit) (because only every 3 days the product owner is available)
The expedite lane is used to fast-track an item to delivery.
- This lane has a work-in-progress limit of its own – an item in this lane does not count for the regular column work-in-progress limits.
- Only items with a fixed delivery date flow through this lane
- Delivering such an item too late results in a fine
!!! SPOILER ALERT !!!
You have several manipulations at hand:
- Assign the workers (dices) – for example you can decide to assign a work outside his speciality (e.g. a developer to analysis or test); as in real life, a person working outside his expertise will be less productive.
- Decide upon the number of items in the flow (the work-in-progress limit is an upper limit) (take care you cannot as such change the limit itself)
- Prioritize the items in the backlog
- Look at the effort required to complete of each item
- Look at your metrics and use this data
- And as such limit the work in progress, try to avoid bottlenecks, try to reduce lead times
- Decide to deliver any fixed-delivery date items or not, if yes, decide the right time to handle these
A blocker might occur (via an event card). Obviously this will influence the flow. For example, it might break the work-in-progress limit (because a team has decided to do so). It might black a specific item (in the form of a block that must be resolved first).
More reading (more spoilers): Playing getKanban with an experienced team
Game over 🙂
Our gratitude to @AgileConsortium for hosting this event and @PatrickSteyaert for guiding the game.