Kanban provides an enormous range of invaluable capabilities
to projects, such as efficiency, focus, communication, limiting work in
process, prioritization, and visibility on status. There is great value for
your teams using Kanban and for all team members regardless of their role. This
article will take a look at some of the benefits reaped from implementing
Kanban into your process.
Kanban is a process control system that originated about 50
years ago at Toyota. 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 you work on--regardless of the size of the team and even if you are the
only person on the project.
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
Every project has a process. For some projects, the process
is very short, and for other projects 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:
|| Code Review
|| Design Review
| Story 21
|| Story 20
|| Story 18
|| Story 17
|| Story 16
|| Story 15
|| Story 13
|| Story 11
|| Stories 1-10
| Story 22
|| Story 19
|| Story 14
|| Story 12
The Kanban board will be constantly 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 specifically
expect 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 furthest 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 mark the date on the story when it is
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 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
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 it 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
- "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 also be constantly changing 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
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.
Matt Simpson is a technical lead software engineer at Asynchrony Solutions, Inc. (www.asolutions.com), where Kanban is used daily to manage software design projects. For more information, visit http://blog.asolutions.com or contact Matt directly at firstname.lastname@example.org.