Kanban uses a board to visualize and manage both the Kanban process and the overall 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 feet long (click here to see an actual Kanban board on display).
Every project has a process. For some projects, the process is very short, and for others the process can be very long. Kanban is designed to help manage your process, not define it, so the first step in getting started with Kanban 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 constantly be changing over 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 expect specifically from the Kanban process.
Priority is automagical with Kanban. For most people they don’t even see it happen. Stories are initially placed in the waiting queue in prioritized order. As priorities change over 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 right (highest priority) to left. For example, if there are multiple stories on the board and you need to work on something, you would pick the story farthest on the right side of the board you can work on, 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.
The main reason for giving stories priority from right (highest priority) 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 the 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 work in process, 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 (Work in Process) 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 to either clear the queue ahead or find someone who can. This is very important because it prevents the project from consuming a block in 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, 3 mirrors and 1 completed car, or 5 doors, 2 mirrors and 50 completed cars? I think the answer is obvious. This example directly applies to any project.
Cycle Time & Estimations
Let’s take a look at cycle time. How long does it take to complete your product? Even more, 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 very easy and effective way is to mark the date on the story when it is started and 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 lifecycle 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 to designate a color for each queue; for example: red = design; blue = code; 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 give a very 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.
If we lived in an anti-social 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 people, most of the time, still like to talk and interact with each other. However, the fact that ANYONE, even someone outside of 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 very easy to put a sticky note on the story for someone to pick up the next day. Every morning a project standup 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:
- “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?”
- “Why does this story have five other stories stacked on top of it?”
When those questions are asked in a non-judging, non-disciplining direction, 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.
Remember that your project is constantly changing and your Kanban should be as well to support activity. Use your stand up 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. In order to get the most quality and the most work completed, it’s imperative to think about work in process. Team members should notice where stories have the longest cycle time, which queue fills up with stories rather quickly, and to 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 needs to own their Kanban board, and more importantly, every member on the team should have a voice to change it.
Don't forget to leave your comments below.