The word kanban means “sign” or “signboard” in Japanese and is often used in conjunction with lean or just-in-time principles for scheduling and manufacturing. Kanban is a “pull” system, whereby product, parts, or inventory move forward based on customer demand, thus eliminating inventory, waste, and resources.

As a process control system, kanban originated about 50 years ago at Toyota as a way to enhance improvement for production. Although it was originally designed for use in manufacturing, today it is used within a wide range of industries. Kanban has proven to be so adaptable that it can be used on any software development project—regardless of the size of the team, or even if you are the only person on the project.

The kanban board

Kanban uses a board to visualize and manage both the kanban process and the overall project. The ability to “see” one’s work enhances analysis, organization, and management of the project. A large board is recommended to provide enough room to manage all activity and to be visible from a distance. A typical size can be as large as 10 ft long.

Every project has a process, although these processes can vary from very short to very long. Kanban is designed to help manage your process, not define it, so the first step when getting started with the technique is to translate existing processes into “queues,” each representing a stage of the work. For this scenario, we’ll use these fairly common software development processes: design, code, code review, quality acceptance, design review, demo, staging, and production.

Once the kanban queues are defined, the title of each queue is written on a piece of paper, placed on the board, and partitioned into columns. Then, a planning meeting takes place where project tasks are broken into “stories,” which should take no more than a couple of days to complete. As stories are added, they are arranged in the waiting queue so that the team can start working from left to right. When a story is done in a queue, it is moved to the one on the right, reflecting the next process needed to be accomplished for that story.  After you go through a few stories, your board will look like this:

The kanban board will be constantly changing during the course of the project because your team constantly changes. In other words, the board is an active display and project tool rather than a static one, so don’t be afraid to add or remove a queue along the way. Once the kanban board is in place and is used as an integral part of the project, the team can expect to receive much value from the process. Let’s take a look at what to specifically expect from the kanban process.

Right to left

Priority is automagical with kanban—i.e., most people don’t even see prioritizing happening. Stories are initially placed in the waiting queue in prioritized order. As priorities change during the course of a project, the waiting queue is updated on the board to reflect the new priorities. If the stories for the new priorities are not yet written, then it’s time for the team to have another planning meeting.

An important rule to follow: Stories receive priority by order of queue, from the highest priority on the right and descending to the left.  For example, if there are multiple stories on the board and you must work on something, you would pick the story farthest to the right side of the board, so that it can reach completion as fast as possible.  This provides the most efficient and focused flow of progress.  If there are no stories remaining in the queues, simply choose the first story in the waiting queue.

Eliminate waste

The main reason for giving stories priority from right to left is to limit work in progress and enhance efficiency. Work in progress is considered waste to a project. Although it’s difficult not to have some waste in a project, the goal is to limit it as much as possible to increase efficiency.

What is waste? It is considered waste when the story, at the state of being a work in process (WIP), is unusable code. If at any point in time the customer says, “Let’s change priorities completely” or if for some reason the project finished prematurely, the incomplete code is wasted.

Therefore, it’s best to apply WIP limits by restricting the number of stories that can be in a particular queue.  If you can’t move a queue forward because the WIP limit is already full, you are forced either to clear the queue ahead or find someone who can. This is very important because it prevents the project from blocking the flow of progress, and it prevents the project from acquiring a lot of unusable code.

Take, for example, an automobile production line. A plant would want to complete as many high-quality cars as possible—with the keyword being “complete.” Would you rather have 200 doors, three mirrors, and one completed car, or five doors, two mirrors and 50 completed cars? I think the answer is obvious. This example directly applies to any project.

Improve cycle time

Let’s take a look at cycle time. How long does it take to complete your product? Even more important, what is a product? Is it five features of your app, or is it one small feature? To make the question even simpler, let’s consider a finished unit of work to be a story. Cycle time for a story can be tracked in many ways. One easy and effective way is to mark the date on the story when it is started, and mark the date on the story when it is finished.

However, cycle time is not just how long it takes to complete a story. It can also include how long it takes to finish coding a story, or how long a story sits in the demo queue before a demo actually happens. Remember, if a story sits in the demo queue for two weeks, it is considered waste for two weeks.  If you are tracking the story’s queue cycle time as well as the story’s life cycle time, you would be able to notice that the story was waste for two weeks in the demo queue. What can we do to make less waste in the demo queue?

One sure way to measure queue cycle time is to use colored markers and designate a color for each queue. For example, red = design, blue = code, and green = code review. Every morning, someone would mark each story with the queue’s marker. If the team wanted more granular metrics, each story could also be marked at noon as well. This would offer a simple way to figure out where the most waste has occurred.

Estimations should only be used to find pain points and to adjust change where needed, rather than prophesying the completion time of a set of features. This method of tracking cycle time provides the ability to do both.

Team collaboration

If we lived in an antisocial world, with a kanban board you wouldn’t even have to talk to anyone outside of the planning meetings to understand how the project is progressing. But we live in a world where most of the time people still like to talk and interact with each other. However, the fact that anyone, even someone outside the project’s everyday interactions, can gain knowledge in the progress of the project by viewing the kanban board is quite a valuable benefit.

If a story gets left at the end of the day, it is easy to put a sticky note on it for someone to pick it up the next day. Every morning a project stand-up meeting should take place, where the entire team, and anyone else who is interested, stands around the board and talks about the project. This eliminates the need for longer progress meetings, upper-management miscommunication, and micromanagement. It also provides an opportunity for the team to hold each other accountable.

Any simple dimension is right on the board for all to see. For example, let’s take the tracking of queue cycle time. We could drill down on finding the status of this by asking a few simple questions:

1. “Why has this story been in Code for four days, yet our estimated difficulty is one day? Is there anything we can do to help this story move along?”

2. “Why does this story have five other stories stacked on top of it?”

When those questions are asked in a nonjudging, nondisciplining manner, action can be taken to eliminate stories that have become big holes in the project. This action often leads to a decrease in cycle time, less waste, and enhanced project quality.  

Visualize your project

Remember that your project is constantly changing, so your kanban board should also be constantly changing to support activity. Use your stand-up meeting to recognize pain points in your process, and have your kanban board expose that pain so that it can be resolved immediately. When building your kanban, make sure that your processes are accurately reflected in the queues.

Your project’s development cycle is a production line. To get the most quality and work completed, it’s important to think about WIP. Team members should notice where stories have the longest cycle time, which queue fills up with stories rather quickly, and determine if more resources are needed. This might require more developers to satisfy that particular queue, or you’ll need a greater WIP limit. A good team must own its kanban board. More important, every team member should have a voice in changing it.