I was watching some clips of Leverage, as I am sometimes wont to do, and I was particular taken by a sequence of supporting characters.

The thing about Leverage is that the crew are very capable, but they also have a code, something that makes them good guys. I’m calling this clarity, but feel free to pick your own word. It’s important that there are two axes, because they provide a useful comparison to the characters around them.

That is to say, if there is someone important to the show who is not a member of the crew, they are lacking in one \of those two categories. Characters who have capability but not clarity tend to be enemies or foils (Sterling, Chaos and so on). Characters who have clarity but not capability tend to be allies and supporting characters (the FBI agents, Maggie, Jack Hurley). Characters lacking in both tend to be mooks or victims, and sometimes marks. It’s all pretty easy to illustrate in a grid.

Marks, notably, fall outside of this arrangement because their role is very different. They are often more and less capable than the crew, and may have both more and less clarity. I’m ok with that for Leverage.

Anyway, I’m intrigued by the grid because I want to remember to use it in my own games, specifically to make sure that I have names in every box. It’s easy to remember the foils because they’re so much fun, but it’s worth the effort to remember the sympathetic NPCs. If your heroes have clarity regarding who they are, nothing tests that like someone else trying to live up to the same rules and failing.

But it’s also kind of Leverage specific, since it’s a game where it’s appropriate that the PCs are “up and to the right”. That’s far from common, so I tweaked the model a bit for more traditional games.

Notably I replaces “clarity” with “drive”. This partly moves away from the moral component from leverage, but it also allowed me to move the foils to the right. 🙂 In this case, drive equates to the strength and direction of a character’s agenda.

The lower left is still largely the same, except the foils have been replaced by neutrals – characters who could act, but choose not to. On paper, these should be the most boring of characters, but in small doses they tend to be quite compelling.

Above them is the Old Man From Scene 26, which is the stand in for overpowered NPCs with no reason to be there. They tend to not contribute much to a game, but some setting shave a role for powerful observers or the equivalent. They may be more prize than participant.

To the right we have the mentors – the folks who are similar to the PCs but more capable. As with the Old Man From Scene 26, these can be a problem, and it’s best to either remove them from the board early, occupy them, or make them a source of trouble in their own right (in the sprit of the elders of Amber).

I put villains in the upper right, which may seem weird, especially since it’s so close to the PCs and the mentors, but consider: what makes a villain interesting is that they are at odds with whatever the characters want, and they cannot easily be turned from that path. Without those two characteristics, the villain is merely a challenge.

Foils re-emerge on the far right – they are as capable as the PCs, but their motives take them elsewhere.

The lower right is the category I’m east sure of – NPCs with little capability but a lot of drive. That is to say – plot hooks. And that’s great as far as it goes, but I’m not sure what I’d do with an NPC who lives in that space.

As with the Leverage grid, the utility of a grid like this is to be able to drop your NPC names and see if any gaps reveal themselves. It’s a simple trick, but maybe useful.

They’re not really design patterns, but I’ve been randomly sketching these as they occur to me. Will probably be throwing them up here intermittently.

Dungeon World does an interesting thing where a character playing a class is the sole representative of the class in the world. They are the fighter or wizard and whatnot. It’s a nice gimmick, and a few games use it, because it underscore the role of the characters as protagonists, not just interchangeable pieces.

Contrast that with D&D 3e, which did something very clever with “NPC classes”, which followed the same general rules as PC classes, but were simply less awesome. Most NPCs who fought were “Warriors” of whatever level was appropriate, and while they were capable at fighting, they lacked the bells and whistles of the PC classes.

The game I’d like to see is somewhere between those two, where PC roles or classes are meaningful, but not unique. That diminishes PC spotlight somewhat, but the tradeoff is that it gives them a stronger social context. A world where you are The Paladin is maybe a little bit different than the one where there are a dozen Paladins, and you are one of them.

The exact number doesn’t matter a lot – it could just as easily be 108 Paladins. It just matters that there’s enough of a boundary that it matters, but not so much that it has no context.

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.