What Making Pizzas Taught Me About Agile
The first time I ran Kanban Pizza with a class, every group did the same thing in round one: they made far more bases and toppings than the oven could handle. By the time the timer ran out, there were completed pizzas sitting on the bench that never got baked, and a backlog of half-assembled ones that never got finished. Nobody had thought about the oven. Everyone had been heads-down producing.
That is not a failure of the activity. That is the activity working.
The debrief after round one tends to run itself. Why did we build six bases when the oven holds three? Who was supposed to watch the bake timer? Why did we assemble pizzas nobody had time to cook? The students are answering those questions before I’ve asked them — and they’re describing WIP limits, bottlenecks, and pull systems without knowing the vocabulary yet.
This is the premise behind Kanban Pizza, a free, open-source multiplayer web app I built to teach Kanban and Agile principles through a simulated pizza kitchen. It runs in the browser, requires no installation, and supports up to five players per room across three progressively more demanding rounds.
Why a Pizza Kitchen
The analogy is not arbitrary. The Toyota Production System — which gave birth to the kanban card concept in the late 1940s — was partly inspired by American supermarkets, where shelves were restocked based on what customers actually took, not what a central planner predicted. Taiichi Ohno described this pull model in Toyota Production System: Beyond Large-Scale Production (translated and published in English by Productivity Press, 1988). The kanban card was the mechanism that made pull work on the factory floor: a physical signal that triggered upstream production only when downstream capacity existed.
A pizza kitchen makes that logic immediate. There is no point prepping twelve bases if the oven holds three. There is no point assembling a pizza if the oven is already full. Work that doesn’t get pulled through to completion is inventory — and inventory has costs.
Three Rounds, Three Lessons
Each round introduces one new layer of complexity. The debrief between rounds is where the learning consolidates.
Round 1 is a production line. Each player preps their own ingredients, builds their own pizza — one base, one sauce, either four ham pieces or two ham and two pineapple — moves it into the shared oven, manages the bake timer, and collects completions. The oven holds three pizzas maximum. Bake under 30 seconds or over 45 and the pizza is wasted.
The constraints are tight enough to surface problems quickly. Students who batch-prepare lots of ingredients before building anything end up sitting on a pile of raw pizza ingredients for the whole round. Students who ignore the oven timer lose entire batches. Almost every group ends up with the same post-round picture: built pizzas that never reached the oven, ingredients that went unused, a score that reflects both waste and unsold stock.
This is David Anderson’s first Kanban principle in action: visualise the workflow and limit work in progress. Anderson’s 2010 book Kanban: Successful Evolutionary Change for Your Technology Business describes WIP limits as the mechanism through which Kanban exposes problems rather than hiding them under a pile of half-finished work. The oven limit does exactly that.
Round 2 is where something more interesting tends to happen. Players can no longer just work on their own pizza — ingredients are prepared collectively and fed into a shared build queue. In practice, what I’ve seen is that groups quickly realise they need someone watching the oven full-time, telling everyone else when to stop making pizza. That role emerges without prompting. Nobody assigns it; someone just takes it, because the alternative is chaos.
That’s the second cluster of Kanban principles — manage flow, make process policies explicit — arriving not from a slide but from the students’ own problem-solving. It also maps directly onto the Agile Manifesto’s emphasis on individuals and interactions over processes and tools. The coordination isn’t optional. You can’t do it alone.
Round 3 shifts from production efficiency to demand-driven delivery. Customer orders arrive as kanban cards throughout the round — up to fifteen of them, not all the same pizza. Fulfilling a correct order scores 20 points. Building a pizza that matches no order costs minus 10. Leaving orders unfulfilled at the end costs 15 each.
The scoring structure penalises speculation. Groups that enter round 3 trying to keep the oven full — the strategy that worked in rounds 1 and 2 — tend to do worse than groups that slow down, read the incoming cards, and build to demand. This is pull logic in its clearest form, and it’s also the Agile Manifesto’s principle of responding to change over following a plan, made tangible.
What the Debrief Data Makes Visible
After each round, the app generates a results breakdown: completed pizzas, wasted pizzas, unsold stock, leftover ingredients, and a score. In round 3, fulfilled orders, unmatched pizzas, and remaining unfulfilled orders are tracked separately.
Get Adam Clement’s stories in your inbox
Join Medium for free to get updates from this writer.
These numbers aren’t just a scoreboard. A high wasted-pizza count with a low unfulfilled-order count points to a quality problem — invalid combinations getting built. The inverse points to a throughput problem. Lots of leftover ingredients with low completion points to WIP — work starting and not finishing.
The cumulative flow data the app records (snapshots of pipeline stage counts at five-second intervals) mirrors the cumulative flow diagrams used in real Kanban implementations to track lead time and diagnose bottlenecks. The game generates this data naturally, without students needing to know what cumulative flow is.
Experiential Learning and Why It Works Here
The case for simulation-based learning in professional development goes back at least to Kolb’s 1984 experiential learning cycle — concrete experience, followed by reflection, followed by abstraction into transferable concepts, followed by active experimentation. Games have been used in management training for decades because they create the concrete experience that classroom instruction can only describe.
What Kanban Pizza adds is real-time feedback with genuine stakes within the scoring system, and a structure that forces iteration across three rounds. The team doesn’t play once and debrief. They play three times, with a debrief and a chance to adjust strategy between each. The behaviour change this enables — teams performing demonstrably differently in round 3 than in round 1 — is the learning made visible.
The Agile Manifesto’s twelfth principle is: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.” The game’s structure is a compressed implementation of exactly that. The retrospective is built into the format.
Running It
Players navigate to https://kanbanpizzagame.toolsforteaching.co.uk/ or the backup deployment at https://kanbanpizzagame-backup.onrender.com/, enter a shared room name and password, and join. The facilitator starts the round when everyone is ready.
For in-person sessions, a projector showing one player’s screen works well for narrating what’s happening in real time. For remote sessions, the Socket.IO updates mean everyone sees the same game state simultaneously.
The source code is available on GitHub under an MIT licence, deployable to Render, GitHub Pages, or any Python-capable hosting environment.
What It Does Not Replace
Kanban Pizza is a game. A team that plays three rounds and scores well has learned something about pull systems, WIP limits, and demand-driven delivery — but they haven’t learned Kanban. Kanban as a method involves ongoing metric tracking, service level policies, feedback cadences, and a change management philosophy that doesn’t compress into thirty minutes.
What the game can do — and what it does well — is create a shared reference point. When I explain later that a kanban system limits WIP to prevent exactly the kind of inventory build-up that happened in round 1, the explanation lands differently than it would on a blank slate. Students have felt the problem. They’re in a position to hear the solution with more than polite attention.
The best training tools don’t teach the concept. They create the conditions in which the concept becomes necessary.
Kanban Pizza does that with a three-minute oven timer and a bench full of pizzas nobody got round to baking.
References
Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., … Thomas, D. (2001). Manifesto for Agile Software Development. Agile Alliance. https://agilemanifesto.org
Anderson, D. J. (2010). Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press. ISBN 978–0–9845214–0–1.
Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press. ISBN 978–0–915299–14–0.
Kolb, D. A. (1984). Experiential Learning: Experience as the Source of Learning and Development. Prentice Hall.
Kanban Pizza (source code). GitHub. https://github.com/southernadd-cmyk/kanbanpizza2
