Introduction to Kanban

Many organizations get interested in Kanban due to its lightweight methodology when compared to other Agile practices. Often, however, they aren’t sure what Kanban actually is beyond a To Do/Doing/Done column layout, and something to do with cars. So what is it? What does it offer? And how do you use it?

What Is Kanban?

There are lots of things you can read about where Kanban came from; the short form is that it’s a method pioneered by the Toyota car manufacturing company, with roots going back to the 1940s. Kanban (and you can pronounce the “a” long or short) is a “lean” workflow management system that emphasizes waste reduction through just-in-time processes and continuous improvement.

According to Toyota, there are six rules for Kanban (per Wikipedia). The first three rules are:

• Each process issues requests to its suppliers when it consumes its supplies.
• Each process produces according to the quantity and sequence of incoming requests.
• No items are made or transported without a request.

What these rules amount to is the definition of a pull-based system. Each person working in a process takes on more work as the person doing it has capacity, not as the work becomes available to be done. If you have thirty tasks on your To Do stack, you don’t add any more until you’ve gotten rid of some of the existing ones.

The result of this process in an ideal world is a system in which nothing happens until a customer places an order, upon which the system requests materials and produces exactly one perfect car instantly, because having materials sitting around unused and cars sitting around unsold both cost money. 

The software industry, lot of magpies that we are, took this idea and said “what if we could approach software development like that?” Because having half-finished software sitting around also costs money.

Back to the rules.

• The request associated with an item is always attached to it.
• Processes must not send out defective items, to ensure that the finished products will be defect-free.

These are about quality; every step is traceable, and every product is as close to defect-free as possible. Sending out sloppy product is at best wasteful – you will inevitably spend more resources addressing the problem than it would have required to fix it at the time it occurred – and potentially ruinous for an organization. Doing work that you can’t track back to any particular need is similarly wasteful. I’m sure most of us have had the experience of looking back at the past week or month and trying to figure out what we spent all of that time doing. If we can’t answer that question, though, how can we hope to figure out whether we should do things the same way next month, or if there might be a better way to use the time? 

The final rule is this:

• Limiting the number of pending requests makes the process more sensitive and reveals inefficiencies.

The final rule describes work-in-progress (WIP) limits. The best, simplest demonstration of how limiting WIP speeds up flow is through the penny-flipping game. https://www.tastycupcakes.org/2013/05/the-penny-game/

The tighter the focus of the work, the faster work moves through the process—and the more quickly the team will become aware of problems with that process. When you only work on one thing at a time, delays are instantly visible.

The route to putting these rules into practice is the Kanban board.

The simplest form of Kanban board is one you’ve probably seen around: three columns labeled To Do / Doing / Done.

This is probably fine if you’re keeping track of personal tasks; unless you’re a serious productivity geek, you just want to know that you made a dentist appointment and need to pick up flowers before the party this weekend. 

Regardless of scope, every board starts with a backlog. Where do tasks come from? How do you decide what gets top priority? What counts as work? Not knowing (or not admitting) how much work you actually have and where it all comes from makes the system less useful.

So one of the first things you’ll want to do is to write up all of the tasks, one card apiece, and put them on the backlog in some kind of order. When it comes to writing a task card, less is more, at least to start with. You don’t want to have repeated “what was that about again?” conversations, but you don’t need to include every detail on the physical card, either. Put enough on it that it’s useful to your team.

Once you’ve got a backlog, create columns for every state your tasks occupy from start to finish. Don’t be tempted to discount things as “not really work”; that stuff adds up, and you end up wondering why everything takes so long. Are things waiting for more information, being reviewed before they go out the door, or being researched? Are there dependencies outside the team’s control? Make them visible.

It is critical to have clear, transparent rules spelling out how work moves from one column to another. This is part of your Kanban commitment to quality. It’s easy for unacknowledged work to hide in those transition areas.

Once you have the columns figured out, you can add richness to your board. It should be visible at glance who on the team is doing what. You might do this with different colors, or with stickers on the cards, etc.  You might also want to include dates [MOU1] (when it came in, when it’s due if there is a hard deadline), and how long the has spent in various stages. You don’t have to restrict yourself to words here, either (one story I read involved a team who stapled a banana peel to a card to make it obvious how long it had been waiting).

Once you’ve got a solid sketch of the workflow, go ahead and start using it. Don’t be afraid to make changes if they’re needed down the road. One of the great things about Kanban is the lens it provides through which to inspect your work. If your model of how things get done doesn’t turn out to match how your team is really doing things , then change the model.

A Few Important Terms

In this section we’ll define some useful Kanban-related terms.

Lead Time – Lead time is the period between a new task’s appearance in your workflow and its final departure from the system. (source)

Opinions vary on whether you should start counting from the moment something hits the backlog, or the moment someone commits to working on it. Personally, I think there’s more value in the former, because that’s information. If new tasks spend forever in the queue, why is that? If something has been in there for months and never reached the top of the priority list, are you really going to do it?

Cycle Time –Basically, the time it actually spends being worked on. Cycle time begins at the moment when the new arrival enters “in progress” stage and somebody is actually working on it. (source)

Work in Progress/WIP – The number of work items in a given column at a given time. A “WIP limit” is a hard cap on how many things can be placed in that column, ever. (Remember, Kanban is pull-based! You don’t take a new task until you finish something you’ve already got.) More work in progress leads to longer cycle times. When you consider how much time is lost to context-switching, it doesn’t take very many things to be in progress before you’re spending more time moving among things than you are moving any one task forward.

Swimlane – A horizontal pass across the Kanban board that allows you to describe different workflows for different types of work. Lots of places have a “fast lane” for customer-critical issues (but when everything is a critical issue, beware).

What Makes Kanban Useful?

First, it’s easy to tell what’s going on in your team from a well-populated Kanban board. No one should ever have to attend a status meeting ever again. Personally, that alone would sell me on it.

This, by the way, I find to be a strong argument in favor of using a physical representation of your work instead of an online one. Because this is what an online board with six things to do looks like:

And this is what an online board with sixty things to do looks like:

Being able to see the whole thing at once really does make a difference to your brain. What you have to scroll to see, you will not pay as much attention to. Online boards miss out on entire dimensions of information, literally. Don’t just assume that there’s no other way you can do it, either; I would at least urge that people experiment with analog before resorting to digital boards.

The second benefit to Kanban is that you can do experiments. Now that you’ve got your board all put together and once you’ve been using it for a little while, you have a lot of data. With that data in hand, you can try different things and see what happens—where do things slow down or speed up, what effect does it have if you change WIP limits, what if people cross-train… you’ll find endless opportunities.

You can do these things just as easily with your personal board as you can with a work board for a big team, when you have all of the information visible. Just remember that if you think a good goal is “everybody is busy 100% of the time,” it’s easy to make that happen: just jack WIP limits through the roof… and watch the team’s throughput dive.

Where Can Kanban Go Wrong?

At risk of taking a detour here, one of the reasons I hear people decide to move to Kanban is “it doesn’t have all of those meetings like Scrum does.”

Hm. Okay. Let’s go with that for a moment.

What are the Scrum ceremonies? Backlog refinement, sprint planning, daily standup, sprint review, and retrospective. What happens at each of those meetings? You agree on which are the most important tasks, the team plans which of them they’re going to do and how in the next iteration, the team plans out the day’s collaboration, the team reviews the iteration with the customer to adjust plans for the next one, and the team collaborates on potential improvements.

Maybe you don’t need to do those things in a formal meeting, maybe you don’t need to do them every week or two or three, but I would argue that if you stop doing any of those things altogether, you are cruising for misery no matter what Agile toolkit you’re using. And if your motive for adopting Kanban is you don’t like working collaboratively, I have some bad news.

One of the other places where Kanban goes sour is when people stop keeping track of the data their board provides to them. The board can provide you with a lot of information. Cycle time, lead time, and the visible movement of work through the flow can identify bottlenecks, dependencies, and places where the overall work can be improved. If you’re not using the information that comes out of the system, you might as well not bother with the system at all.

Finally, the most important part of any Agile cycle is the inspect-and-adapt loop. What happens if you change the WIP limit? What happens if you automate a step? If you cross-train a team member? If you start taking on different kinds of work? If you’re not doing that loop – inspecting how you work and trying things to make the work better – then you’re missing at least half of what makes any Agile [MOU2] toolkit useful.

Book Recommendations

Kanban in Action

Personal Kanban

Making Work Visible