5.2.5: The Kanban Pizza Game and Choosing the Right Flow Approach

Before You Start: Materials and Setup

The game works best with small teams of four to six people, each team running its own version of the exercise in parallel. In an in-person classroom, each team needs a shared table and a simple set of pizza-making materials. Over Zoom, the same structure works with digital substitutes, and the debrief conversation matters even more since students can't see each other's tables directly.

Assign each team member a station before the game begins: base preparation, sauce, toppings, and quality inspection are the typical four stations. Over Zoom, this simply means each participant owns one draggable stage on the shared board rather than one physical spot at a table.

Round 1: No WIP Limits

In the first round, let the teams loose with no constraints at all. Students typically start many pizzas at once, right from the opening whistle. One person cuts bases, another adds sauce, another adds toppings, and another inspects quality, but because there are no limits on how much work can sit at any station, everyone tries to stay busy by starting as much as possible.

This almost always produces the same predictable problems, and that predictability is exactly the point. Too many pizzas get started at once. Work piles up between stations faster than it can move forward. Some people become badly overloaded while others sit waiting for input. Quality drops as people rush. Partially finished pizzas clutter the workspace, whether that's a physical table or a crowded digital board. The team feels busy the entire time but finishes far less than anyone expected once the timer runs out. This is precisely what happens in real teams that start too much work at once: everyone stays occupied, but not enough work actually crosses the finish line.

Run this debrief before moving on to Round 2, since the frustration from Round 1 is what makes the contrast in Round 2 land. Give each team two or three minutes to discuss these questions among themselves before opening it up to the wider class.

Round 2: Add a Board and WIP Limits

In the second round, introduce visualization and constraints together. Each pizza order becomes visible on a shared board, whether that's sticky notes moving across a physical whiteboard or cards dragged across a Miro board in a breakout room. Each step in the process gets its own column, and a WIP limit gets attached to each one, capping how many pizzas can sit at any station at once.

Work is now pulled forward only when there's genuine capacity to receive it. This often feels slower at first, since people are no longer allowed to start everything they'd like to. But teams usually begin to notice better flow taking shape as the round continues. Work finishes more predictably. Bottlenecks that were invisible in Round 1 suddenly become obvious, since a WIP-limited column that's completely full is impossible to miss. People start collaborating across stations rather than working in isolation, and quality tends to improve as a result.

Encourage each team to compare their Round 1 and Round 2 completed-pizza counts directly. Seeing that number improve, even though the round felt more constrained, is usually the moment the lesson clicks for students who were skeptical about WIP limits going in.

Round 3: Improve the System

In the third round, let each team redesign its own process. Teams might rearrange their table layout, reduce unnecessary movement, remove tools nobody actually uses, clarify who owns which decision, adjust their WIP limits based on what they learned in Round 2, standardize how each step gets done, or add a lightweight quality check before a pizza counts as finished.

This is where Lean enters the game directly. If the pizza table is cluttered with unnecessary tools, too many toppings nobody ordered, an unclear layout, or people constantly reaching across each other to grab something, that's waste sitting in plain sight. Even a tool nobody is actively using can create clutter and slow the whole team down simply by taking up space and attention.

Give teams five to ten minutes to redesign their process using this lens before running a short final round. The goal of Round 3 isn't to produce a perfect system. It's to give students direct, hands-on practice with the idea that small, deliberate changes to layout and workflow can meaningfully improve flow, even without adding more people or more effort.

Whether running this in person or over Zoom, the game teaches the same core lesson either way: the goal is not to make every person busy. The goal is to make value flow. A facilitator running this over Zoom should watch each breakout room's shared board during the round and be ready to prompt a team gently if their WIP limit isn't being enforced, since it's easy for that discipline to slip when no one is physically blocking a full station.

Connecting the Game to Real Teams

Once the rounds are finished, spend real time connecting the game back to the students' own work. In a software team, pizzas become stories, bugs, features, incidents, designs, or reports. The pizza stations become analysis, development, review, testing, security, approval, or deployment. Partially finished pizzas become partially done work sitting in a backlog. The overloaded topping station becomes a familiar bottleneck, like a testing queue or an approval step. The messy table becomes a cluttered workflow full of unnecessary tools, unclear ownership, and duplicated effort.

The game helps students remember that flow is a property of the whole system, not of any one person's effort. If one part of the system is overloaded, the whole system slows down regardless of how hard everyone else is working. This is exactly why Kanban teaches teams to visualize work, limit WIP, manage flow, make policies explicit, and improve collaboratively rather than simply asking individuals to work harder or faster.

Scrum, Kanban, Lean, and Scrumban

With the game fresh in mind, it's a good moment to revisit how Scrum, Kanban, Lean, and Scrumban relate to each other, since they're closely related but built to solve different problems. Use Scrum when the team needs an iteration rhythm, regular stakeholder feedback, Sprint Goals, Sprint Reviews, Retrospectives, and a timeboxed way of delivering increments. Use Kanban when work arrives continuously, priorities shift often, interruptions are common, and the team's real challenge is controlling flow rather than planning fixed iterations. Use Lean when the main problem is waste, delay, handoffs, rework, excess inventory, overprocessing, or poor system design more broadly. Use Scrumban when the team genuinely needs both cadence and flow at once, keeping Scrum events such as Sprint Planning, Reviews, and Retrospectives while also running a Kanban board with WIP limits and flow metrics underneath.

The method should always fit the work rather than the other way around. A production support team probably won't benefit from forcing every incoming ticket into a two-week Sprint. A product team building a new feature from scratch may genuinely benefit from Scrum's regular rhythm and feedback loops. A platform team juggling planned work alongside urgent interrupts may find Scrumban fits best. A process improvement team might reasonably start with Lean waste reduction before adopting any particular framework at all.

For PMI-ACP, the strongest answer is rarely "use Scrum because Scrum is popular." The better answer almost always involves understanding the nature of the work first, then choosing whichever approach actually improves value delivery for that specific situation.

The pizza game makes this last point vivid in a way that lecture slides rarely manage. Round 2 wasn't easier than Round 1 just because it had a board and some limits attached to it. It required teams to actually talk to each other, watch their WIP limits honestly, and resist the urge to keep starting new pizzas just to look productive, which is exactly the discipline Kanban asks of a real team every single day.