Menu

What is Kanban? Kanban Explained with a Coffee Cup

Episode 141 - 15 Jan 2020

There's a lot to be learned from what goes on in a Coffee Shop. You'll never look at that cup of Joe in the same way again!

What is kanban?

Well, it's many things:

  • a kanban is an object
  • kanban is a set of principles
  • Kanban is also an agile framework.

And in this video, we're going to be looking at all three aspects of kanban, with the help of a coffee machine, a Doctor Who Lego character and a coffee cup.

Three aspects of kanban

Before we go too much further, let's disambiguate:

There's Kanban the Agile framework - an alternative to Scrum. I like to write "Kanban" in this context with an uppercase K.

Long before there was an uppercase K Kanban, there were a couple of lower case kanbans:

  • kanban the thing, the object, the sign
  • and kanban the set of principles.

Today we're gonna start by talking about the latter two. And then later we'll add Kanban-the-Agile-framework back in to the brew.

Talking of brew, I think I'm gonna grab myself a coffee.

Coffee shop

Into the shop, I place my order, tap my card, and she gets on and makes my coffee. Finally, I collect my coffee.

Did you see any kanban here? No, neither did I. For the simple reason that there really isn't any need for any form of kanban in here.

Now it's probably a good time to introduce a couple of terms that I'm gonna rely on later.

What we have here is a defined process:

  1. Take my order,
  2. make my coffee and,
  3. deliver it back to me.

And with just one person doing all of the steps in that defined process, we really don't have any need for any special orchestration - other than the fact that those three steps really should be done in just that order.

Scaling up

If the coffee shop becomes a bit of a destination in the neighbourhood - and of course, I wish it every success - then it's going to feel the need to scale things up a bit.

One option would be to just well, instead of having one barista in the shop, we could have two. Each doing, well, everything!

And providing they can manoeuvre around each other, there's not much we need to do to make things work: still the same defined process, and the need for a little bit of orchestration. But largely it takes care of itself: the till is either available or it isn't and the coffee machine is either available or it isn't.

(Actually, this fine looking machine looks like it might be capable of preparing more than one coffee at the same time.)

So that's one option: two people doing all of the steps inside the defined process.

Specialisation

The coffee shop has another option for scaling things up, and that is to begin to specialise.

Instead of adding a second barista, they could choose to add a dedicated order taker.

(I struggled to find a good Lego character. This is apparently Doctor Who.)

So yes:

  • Doctor Who taking orders,
  • the barista making the coffee

And this arrangement - this specialisation - comes with some notable advantages.

We have a dedicated order taker, who can become better at order taking over time.

And we have a dedicated barista; focusing all of his attention on becoming better at making coffee.

There are other advantages to this approach. (And if you can think of any, I'd love to hear from you in those comments below.)

There are also disadvantages that come along with this specialisation of skills. I am going to focus on just one of those downsides:

We have added some complexity to our process that wasn't there previously: our defined process now requires two people to carry it out fully.

For the first time, we're having to handle the handoff between the person taking the order and the person making the coffee.

Handling the handoff

Let's take a look at that in action.

Here's the coffee shop.

Let's bring in the barista. And let's bring in that Doctor Who guy.

And let's give them some customers to serve.

This person - who's just arrived at the coffee shop and joined the queue - that's our hero. His name is Robert.

And Robert patiently waits in the queue, ready to be served.

Now he's at the front of the queue. He's placing his order: coffee type, milk type, etc. And all of that information is recorded on the cup. How interesting!

He's also asked for his name, and his name is also recorded on the cup. (Obviously, if this has been real life, the writing wouldn't be nearly so neat and the spelling would not have been nearly so accurate. But this will do for our purposes here today!)

This is interesting: Robert's just left one queue and joined another. We'll be talking more about in due course.

The barista's now ready to pick up Robert's cup. He reads the information from the side of the cup, so that he knows exactly what coffee to make, and gets on and makes the coffee.

And finally, Robert is in receipt of the perfect brew. And at that point, of course, he's able to leave the shop and get on with his day, the process now complete.

Did you spot the kanban?

Hopefully no surprises there, that much is your experience of how things tend to work in a coffee shop.

Now, a big question for you. Did you spot the kanban?

You're quite right, the kanban is actually the coffee cup.

This "coffee cup kanban" helps us with a couple of complexities that weren't there when we had one person doing everything in the defined process:

  • Taking the order,
  • Making the coffee,
  • Delivering the coffee.

Now with two people in the mix, we have the situation where the person who is making the coffee didn't take the order - and therefore doesn't know what was ordered. Nor do they know who placed the order.

The kanban coffee cup answers both questions:

  • all of the information needed to make the coffee is on the cup
  • the name of the person who placed the order is also on the cup

Two problems solved.

But a kanban, coffee cup shape or otherwise, does not a kanban system make, as we shall soon see.

Kanban, the system

Let's start by looking at things from the point of view of the customer.

The best experience for our friend Robert is that the cup barely touches down on the counter before the barista picks it up to make his coffee. And then barely hits the desk on the other side before Robert picks it up and goes off with it.

The best experience for Robert is to get his coffee through the entire system in the shortest possible time.

Let's go look at that process once again but this time, I want you to pay special attention to the progress of the kanban - the coffee cup kanban - through the system. And pay extra special attention to the point where the kanban comes to a halt.

An order comes in, the details are written on the kanban coffee cup and the cup is placed on the counter to wait its turn.

Then another order comes in. Then another order, and then another, then another order and then another. All during the time when our friendly neighbourhood barista is busy making one perfect brew.

This stash of stationary cups - stationary kanbans - means there's a corresponding queue of people. (Not the first queue of people waiting to place an order, the second queue of people who have yet to receive the coffee.)

Not a desirable state of affairs.

There are lots of questions I could ask you at this point, but I'm gonna ask just one: Whose fault is this?

I suppose we could point the finger of blame at the barista. Perhaps he should work faster? But a perfect cup of joe cannot be rushed. I mean, maybe we could shave 10% off his time, while maintaining optimum coffee quality. But that's going to be nowhere near enough to clear this backlog.

Perhaps, then, it's the order-taker that's to blame? And in fact, our friend Doctor Who is perfectly positioned to prevent this pile up. He could notice that things are starting to unravel and could start to stall: he could start to take orders more slowly.

(This is kind of counterintuitive: that we should pay a specialist and then asked him to do his best work by slowing down. This is also a subject that we will be returning to in due course.)

Have you by any chance heard of the Fundamental Attribution Error? It is our human tendency, when things go wrong, to look for the guilty party. To try to find a scapegoat.

It's an error because in most cases - the overwhelming majority of cases - when things go wrong, it's not a person that's to blame, it is the system.

I mention it, because I was just guilty of it: looking for someone to blame, when really, it is the system that is to blame.

Kanban, the system

What we need to do here is fix the system so that this pile of cups cannot happen.

And we can do it very simply, just by applying a hard limit to the number of cups that are allowed in this area at any one time.

By the way, we've just implemented a kanban principle, the principle of limiting work in progress of a system.

What we've also seen, we've glimpsed, we've been given a clue as to the true nature of a kanban (that's kanban the object).

Our kanban coffee cup represents a request to do something specific: To prepare a coffee to Robert's specifications.

But it also represents a request to do something in general: to introduce another coffee cup into the system.

The value of a kanban isn't just in its existence, it's also in its scarcity. And here we can draw a parallel between kanban and currency.

A dollar bill doesn't have much intrinsic value. I mean, it's kind of a bit of paper with some clever printing on it. The value of a dollar bill, or a pound coin or a euro, comes from the fact that the supply is limited.

So it can be said that kanban isn't really about the cards, the tokens, the coffee cups, in the same way as currency isn't really about the notes and the coins.

What about my Kanban Board?

At this point, you might be thinking that this here coffee shop example is all very well and good, but how does it relate to my kanban board?

And how does it relate to Kanban (with an uppercase K) the Agile framework?

We are going be getting into that - and talking more about those kanbans-with-a-little-k - in the very next episode.

I look forward to seeing you then.