Kanban Pizza: the Game that Keeps Giving

A few years ago I was introduced to the squarely-named “Kanban Pizza” game. It has “kanban” and “pizza” in the name - so I was immediately intrigued. In all fairness, anything that involves pizza would pique my interest.

If you haven’t played this game before, I strongly recommend that you do. I believe the folks at agile42 are the ones that created it, and you can find the details for the game play, and the theory behind it here. The gist of it is that participants are grouped into teams that open their own pizzerias and are tasked with producing as many pizza slices as they can.

The catch: I can stop their process at any unannounced point of time and inspect it; any unused ingredients (i.e. not yet on a fully formed pizza slice ready to be delivered to a customer) count as negative points (i.e. in lean terms, it is inventory piled up - waste), and only fully formed and baked pizza slices count as positive points. There are a few rules though that I’ll spare you (like what ingredients to use, how much, aesthetics, etc) but the most important one is how to use the oven. You can only put in a maximum of three slices at a time, they must bake at least 30 seconds, and you can’t open it to insert/remove slices during that bake time.

When we all go through a first round of creating all Hawaiian pizza slices, every time I’ve facilitated this game, almost all teams are invariably negative. Each person in the team is focused on perfecting their role - slicing ingredients as best and as fast as possible, without paying attention to the actual customer needs - getting that slice into their (pizza) pie hole.

We talk a little about some theory of lean thinking, and teams have a kaizen to optimize their flow. Then we repeat a few more rounds. 

Now after each round, we bring it back to the room to discuss major findings - things teams did to improve their flow. I’m always looking out for what I think is one of the most important lessons of this whole game. Usually there is at least one team that discovers it: that the oven isn’t a constraint! Most people start this game thinking it is… in fact it is stated as how you typically would state a constraint: you can only put up to 3 slices at a time, you must wait 30 secs, you can’t add... so much so that folks always ask during their kaizen, can we increase the size of the oven (add more slices at a time)? Of course the answer is a flat ‘no’. This is a usual response in the workplace - “can we add more people”? What do you think? A project is already half-way through, hiring processes take a long time, ramp up times are a time sink, and so on. Is it wise to add someone in the middle of a project just to increase capacity/throughput? There may be times when that is indeed the solution, but I would say the vast majority of times, it isn’t.

The Theory of Constraints says that in any system, at any given point of time, there is at least one constraint. You can find that constraint by looking where the inventory is piling up. But when  you look at all the team’s workstations, there is little piling up in front of the ovens. Actually most of the inventory was piled up between stations… ingredients waiting to be put on a slice. When teams realize this, they have a major ‘aha’ moment: the constraint in our system isn’t the oven, but it is in how we work together as a team. Ah, how easy it is to blame someone else!

Most teams are able to flip things around and have a positive flow - they reduce inventory and get closer to one-piece flow, where eyes are now on the pizza slice, the customer value, versus my own local optimization. In fact, some distinct teams realize that to get to even higher levels of throughput, they actually had to ignore the max capacity of the oven. They were popping slices in there when they were ready, even if it was just one slice, and they didn’t wait until they had three slices to turn it on. See? It wasn't a constraint at all.

Have you looked at the flow of value throughout your team or org? How can it be simplified? How can you get closer to minimizing waste? One-piece flow? If you’re thinking, “well, we’re a software development company, we don’t have inventory”, think again. If a feature requires multiple teams to work on it to deliver it, your team backlogs all equate to piles of inventory.

So what is your pizza oven preventing you from seeing your real constraints?

Stay tuned for part 2 - Kanban and balance!