The word “kanban” sometimes comes up in software and game development circles. But, when it does, it’s usually within the context of agile and scrum. And the interpretation of the term usually begins and ends with “It’s like scrum, but without sprints.”

This is a massive oversimplification.

You see, when I was a freshly minted scrum master, I often told folks that I was all about scrum, but I would happily kick it to the curb as soon as I found a better framework.

Kanban is that framework.

Previously on “Game Planning With Science!”: Part 1 Part 2 Part 3 Part 4 Part 5 Part 6 Part 7 Part 8 Part 9 Part 10

---

By Reading This Post, You Will Learn

• The difference between push- and pull-based process flows
• What “kanban” is
• Why work-in-progress constraints can improve efficiency and make production issues easier to spot
• How to apply kanban in a game development setting 

---

Note

If you haven’t read “Game Planning With Science!” Part 1 (or it’s been a while), you should go review it. This post will make a lot more sense that way.

Push-Based Production

A traditional factory model is a “push-based” production system. “Upstream” stations (those earlier in the process) push work to the “downstream” stations. The machine that makes cans sends them to the machine that fills them with soup, which in turns sends it to the machine that applies the lid. Or in the context of game development, the character modeler passes his model to the rigger as soon as he’s done, or a designer sends his Unity updates to QA for review as soon as they’re in the build.

This model it perfectly serviceable, with one caveat: the throughput of the various stations has to match, and they all have to run at a constant rate. Otherwise, inventory will build-up will occur in front of the bottleneck/s, and this will pooch screw your flow time efficiency.

The Inventory Build-Up Dilemma Of Push-Based Production

For example, lets look at a very simple 4-stage production process, measured in units of time T. The first activity takes 1 unit of time, the second takes 2, the third takes 3, and the fourth takes 1. Easy enough. We have a combined theoretical flow time of 7T.

Until we actually engage the process flow.

The first unit we put in the pipeline will indeed have a flow time of 7T. But as soon as we get to our second unit, we start getting a queue before Activity 2. Activity 1 sends units to Activity 2 at twice the rate the latter can process them. So the units start to pile up in front of Activity 2. Activity 2, like wise, sends units to Activity 3 50% faster than Activity 3 can process. So we start to accrue a queue there as well.

And as these queues build up, our flow time efficiency starts to drop. After 5 units of time (t = 5T), the queues are sufficiently long that our flow time efficiency is already down to 50%! And at t = 20T, our flow time efficiency has dropped to 19.4%!

The big takeaway here: the larger the difference in throughput between activities, (or the more inherent variance in those activities) the more your flow time efficiency will bottom out in a push-based system.

Pull-Based Production

The alternative to push-based production is “pull-based” production. Simply put, instead of Activity 1 pushing work to Activity 2 as soon as 1 is done, 2 pulls the work from 1 when it’s ready for it. Activity 1 finishes a unit and simply holds it until Activity 2 signals that it’s ready to process another unit. Moreover, Activity 1 doesn’t start on another unit until Activity 2 pulls the unit 1 is currently holding.

But That Seems So Inefficient!

Don’t confuse “efficiency” and “utilization”. Yes, Activity A will be less than 100% utilized. But that’s okay. Remember what we talked about in Part 2 – ramping every resource to 100% utilization is not the objective. The bottlenecks determine how fast you move. Maximizing everyone’s utilization will not get units through the system faster. It will only protract the time to get any one unit through the entire process due to queue buildups.

Kanban (看板)

Kanban is a pull-based production system. The word kanban translates literally as “sign” or “card” (I’ve also seen “billboard”). It specifically refers to physical cards passed between stations on Toyota’s production line. When a downstream activity requires input, it passes a kanban (a card) to the upstream station. So, when the person who mounts doors on cars runs out of doors, he passes a card to the person who assembles doors. That person puts a set number of doors (defined by the kanban) onto a cart and sends the cart back to the door-mounter.

There are two important observations to make here. First, the inventory passed between stations is dictated by the cards. And second, if cards dictate how much inventory is passing between stations, then, by extension, the amount of cards in circulation control how much inventory is available in the entire production process.

And, over time, Toyota management pulls cards out of circulation, reducing the overall level of inventory.

What? Why? How Is That Remotely Helpful?

Three reasons.

First, as pointed out above, the less inventory you have in the system, the fewer queues you have, and thus the higher the level of flow time efficiency. No queues means everything the enters the system get through it faster.

This Is A Little Counter-Intuitive, So, By Way Of Analogy…

Think of it this way. Amusement parks like Disneyland keep their rides moving at a regular clip to allow as many people as possible to take as many rides as possible on any given day. But that doesn’t stop you from waiting in line all the time. So, while you could, theoretically*, ride every attraction once in a single day, the amount of time you spend in queues means that you have to visit the magic kingdom on multiple days to see everything.

Now, instead imaginee that Disneyland restricted the number of visitors such every ride was at capacity at all times, but nobody ever had to wait in line. In other words, a perfect balance between capacity and visitors. Now you CAN get through all of the rides in one day. So everyone who comes through spends the same amount of time on rides, they just get through all of the rides faster in less time overall.

Back To The Usefulness Of Restricting Work-In-Progress Inventory…

The second benefit of restricted work in progress, is that excess inventory incurs its own costs, which I will delve into in the post on heijunka.

Third, excess inventory masks production issues.

See, while having lots of stuff to do means you can keep everyone busy, it also acts like a layer of protective fat. Because there’s always something to do, it becomes far less obvious when issues are impacting your process.

---

Resources That Informed And Influenced This Post

If you have ad blockers turned on, you may not see the above links. Breaking The Wheel is part of Amazon’s Affiliate Program. If you purchase products using the above links, the blog will get a portion of the sale (at no cost to you).

---

Rocks In The Stream

Toyota uses this analogy. Imagine a stream. Your job is to remove every rock in the stream. With lots of water flowing, you can’t see any rocks. But if you drop the water level a little bit, some big rocks suddenly emerge. So you haul those out, then drop the water level a little more. Some slightly smaller rocks appear, and you remove those. Repeat. And repeat. And repeat.

With lots of excess inventory (water) in your process (the stream), it’s nearly impossible to spot issues (rocks) because things are always getting done (the water is always moving). But if you start pulling that excess work out of the system, if people have fewer alternate tasks to keep them occupied if they hit a roadblock. And then the roadblock starts sticking out like a sore thumb.

And if you severely restrict work in progress – if a team member can only have one assignment at a time, and they can’t offload that assignment until the next person in the flow can pull it from them – any production issues, imbalances, and inefficiencies are going to start giving off a lot of smoke.

The logic is slightly counter-intuitive. You’re actively trying to make issues more acutely painful. But the squeaky wheel is the on that gets the grease. So the purpose of limiting work-in-progress is to make your problems really squeaky, starting with the biggest ones.

Applying Kanban To Games

The objective of a true kanban process is three fold:

• Minimizing the flow time of any one unit that moves through the process by pulling them downstream rather than pushing them from upstream in order to avoid queuing
• Make production issues more obvious by minimizing work in progress
• Maintain a continuous flow of output and reduce or avoid batching (I’ll cover this in more detail in the section on heijunka)

Now, you’re probably not going to be working with physical kanban cards. But most modern task-tracking software packages (Jira and Hansoft, specifically) have the next best thing: work-in-progress constraints.

So, to get started with kanban:

1. Adjust your production processes so that team members pull work from each other rather than push it to each other
2. Set an initial WIP constraint that’s slightly tighter than the amount of work your team members usually maintain, then slowly ratchet that constraint up over time as you solve the chronic/persistent production issues that emerge
3. Work on reducing your batch sizes (again, more on this in the heijunka post)

The Limits of Kanban

There are going to be limits to what recurring issues you can realistically solve. It is entirely possible that, under your particular, idiosyncratic constraints, a WIP limit of one unit (one story, one character model, one bug) might be less efficient than a limit of two units. Or that different activities need different WIP contraints. Totally understandable, totally fine. The goal is not to match some arbitrary point of perfection. It’s to maximize efficiency under your given constraints.

On The Topic of Muda

Returning to the seven categories of waste from Toyota, kanban is designed to improve two of them. It constrains excess work in progress. And it reduces queuing.

---

Further Reading If You Enjoyed This Post

Video Game Art Pipelines – Game Planning With Science! Part 1

Character Art Pipeline Capacity Charts – Game Planning With Science! Part 2

The Time Value of Fixes, Or: A Fix in the Hand is Worth Two in the Bush

---

Where Do We Go From Here?

Now that we have a production framework for maximizing efficiency, it behooves us to try to limit the variance within that framework. And while much can be accomplished by human beings, we can make even larger strides if we put the robots to work on our behalf. So, in the next post, I’m going to cover just that with the concept of jidoka.

---

Key Takeaways

• There are two basic forms of process flows: push- and pull-based
• In a push-based system, upstream processed push work to downstream stations
• Push-based processes are fine, as long as the throughputs of the various activities match
• As soon as they do not match, queues will start to accrue along the process flow, and flow time efficiency will start to crater
• In a pull-based method, downstream stations pull work from upstream when they are ready for it
• Kanban is such a pull-based process
• Over the long term, the goal of kanban is to reduce the amount of work in progress both to improve flow time efficiency but also to make production issues easier to spot
• The way to apply kanban to game development is to first establish a pull-based system, then slowly implement work-in-progress constraints over time

---

If You Enjoyed This Post, Please Share It!

*I’m using “theoretically” in terms of theoretical flow time, not in terms of a guess. Settle down, science grammar nerds.

Return to the “Game Planning With Science” Table of Contents

“Kanban: The Counter-Intuitive Value Of Pull-Based Production – Game Planning With Science! Part 11” by Justin Fischer is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

SaveSave