Kanban is an agile methodology that has its roots in japanese manfacturing, but for most people the term is synonomous with “lots of sticky notes”. The rub is that both of these things are true, but because of terminology, things get weird.

Kanban is used for work that proceeds like a production line, where the issue is not schedules, but predictable workflow through a number of stations. To use a hypothetical situation, let’s say we have a little pizza place. When someone calls up, the following things happen:

1. Someone answers the phone and takes down the order
2. Someone grabs a round of pizza dough and spins it flat.
3. Someone adds the toppings to the Pizza
4. Someone puts the pizza in the oven
5. Someone takes the pizza out of the oven
6. Someone boxes the pizza
7. Someone copies the delivery information onto the pizza
8. Someone puts the pizza in the “to be delivered” stack 9) Someone grabs the pizza and delivers it

Now, that’s unpacked pretty far. In practice, a lot of those steps can be collapsed because they’ll be done together. With that in mind, we might define a number of workstations:

Workstation 1: The Phone, where orders are taken.

Workstation 2: The prep area, where the pizza is made, then put in the oven.

Workstation 3: The finishing area, where cooked pizza is boxed, labeled and put in the stack.

Workstation 4: The stack, where pizzas to be delivered go.

In theory, at any given point, a pizza will be at one of these stations.  But that’s not quite correct – there is another pseudo-workstation between 2 and 3, where the pizza is cooking.

So if you drew this out, i might look like:

This is a rudimentary workflow, and it’s a great starting point.

Now, imagine that you put this up on a board.  When a call was received, the first person wrote all the information about the pizza on a post it, and slapped it up under call received.

When the person in the prep station freed up, they’d grab the next card under Call’s received, and start prepping it.  When they finished, they’d put the pizza in the over and move the post it to the “cooking” status.  When the oven dings, the person at the finishing station grabs the pizza and the post it, and boxes and labels it up, then moves the post it and the pizza to the “ready” column.

(Aside: This is simplified for illustration, so roll with me here).

Now, that workflow chard has become a means of keeping track of Work in Progress. It might look something like this:

 

 

This is a “Kanban Board” and it’s what most people think about when they talk about Kanban, because this kind of board is a FANTASTIC way to make work visible.  At a glance you can see what’s happening where. There are a lot of applications for this, and many of them are outside the scope of Kanban itself.

See, in Kanban, we’re not doing this as a convenient dashboard, we’re doing it to identify capacity constraints.  What does that mean? Well, notice there are a lot of cards on Prep, but nowhere else?  Prep probably takes longer than taking a call, but it only takes about as much time as finishing, so what’s the holdup?

The holdup is that the oven is a bottleneck.  It can only process one pizza at a time, and so no matter how fast or well we take calls or prep pizzas, we’ll never go faster than the oven.

There’s a bunch more to this.  Consider, for example, what happens when our oven can handle 4 pies at a time, but there’s only prep space for 3 pizzas – we waste that extra capacity.

And this is super valuable when you have work that needs to get done, and this approach can be applied to many more problems than may be immediately obvious.  But for a lot of people, the *board* is a more useful takeaway than the capacity part.

And it’s hard to fault that. While the model is designed for a one way flow, it works equally well as a state tracker, where things might move in either direction. To use a gaming example, suppose you’re doing a Fate style fight across 3 zones.  You could draw the zone to track them, sure, but just as easily you could do:

 

 

Note that by introducing color, I’ve introduced a new way to track information – the PCs are blue-green while the monsters are yellow. I can mark them up and move them around as the scene progresses, no problems.

Now, there’s a reason we have minis and maps – they’re already pretty well established information technologies.  This is not just a substitute for that.  To see what we can do, let’s consider a more complicated example.  Perhaps you’re running a more political game, in a city with a powerful nobility, clergy and guilds.  The players are trying to get support to, say, fund an anti-dragon initiative.  This is not a single scene, but rather something that’s going to drive lots of play, as players talk to movers and shakers, cut deals, trade favors and so on.  As the GM, if you want to keep track of this all, perhaps you do something like.

 

Note that I have added something new – the cards are now distributed into bands, or “swimlaines”.  In business, these might be used to denote different projects using shared resources, but the idea is portable to anything where a littler separation would be informative.  For example, it is clear at a glance that the guilds and church lean in different directions with this.

The key is that as play happens, this layout can change, with cards moved around based on events.  The GM can keep a general overview of the state of things without needing to over mechanize it.  This comes in equally handy when you want to keep track of the movements of a conspiracy, the threats to a border town, or the agendas of megacorps.

The bottom line is that the kanban board is a powerful, versatile tool that you would be well served in adding to your toolkit.