What Are Kanban Boards and Why Are They Important to Our Customers?

When we do tours of our office for customers, prospects, new starters and other guests we often get asked a number of questions about our development Kanban boards.

It seemed appropriate to write a few words on what the boards are and why we use them.

So what is a Kanban Board?

The Kanban (in Japanese it typically translates as “sign”) concept was created by Taiichi Ohno who is credited with creating the concept of Just In Time whilst working at Toyota.

Taiichi Ohno is often cited as the creator of the Toyota Production System, which is considered the foundations for the Lean Manufacturing and Lean Software Development approaches.

Kanban is essentially a scheduling system which helps to move work through different stages of a lifecycle. The lifecycle we use it to schedule is the development process here at NewVoiceMedia.

Observing the Kanban boards shows us where specific work items are in the system, where there may be blockages and where we are achieving a good level of “flow”.

Therefore observing the Kanban board can often lead to insights of areas to improve, bottlenecks and general process improvements.

There is a difference between Kanban and agile. Many agile approaches use a time-box approach to work, whereas Kanban systems focus more on continuous flow of work, at a pace that is sustainable. There are many different approaches to both agile and Kanban and the use of boards and I’ll explain how we use our Kanban board here.

What does a Kanban board look like?

We have a number of teams within development and each one has a slightly different approach to their boards and flow of work. These differences are due to the teams approach, the type of work they do and the release cadence of the products they work on. Many people within development have their own personal Kanban boards too, typically these are digital though.

Our Kanban boards have columns to represent the different stages that a new item of work will flow through.

We have a number of different items of work that flow through a board like this:

• A story task – this is a work item related to new functionality we are adding
• A story bug – this is work on a bug found during functional testing
• A bug – this is a bug that has been identified for fixing
• A chore – this is a work item not directly related to the product. For example – adding a new build machine
• A story – this only really moves to done once all of the tasks and bugs have been completed

Each of these pieces of work are something that needs to flow through the system to a “done” state.

Why are there numbers above some columns?

The numbers above the columns represent a Work In Progress (WIP) limit. This is a technique for ensuring that each stage in the process is not flooded with more work than can realistically be done.

Kanban is about flowing work through an entire system as smoothly as possible. As such anything that impedes that flow should be improved or changed to achieve a more balanced continuous flow. Having work items stop at certain points in the system and become backed up suggests an area for improvement.

Why does this improve productivity?

There are a number of reasons why we work using Kanbans. One of the main reasons is to ensure productivity remains balanced. Having a good week of productivity and releasing a product is great, but following that week with a poor week of productivity and no release is not so good.

We use Kanban to try to even this productivity out so that each week is a good week. Stacking a system (and hence, our development team) with more work than can be achieved will slow the entire process down.

Working in peaks and troughs of productivity also makes it very hard to predict and estimate the delivery of features.

We have found that Kanban helps to achieve continues flow of productivity in the following ways:

• People are not overwhelmed with work one day and then sat waiting for work another. Although we still have moments like this, we are working hard to get an even flow.
• By limiting the amount of work items in each stage we can even out the entire system. We do change the WIP limits and tweak the columns every so often.
• We are visualising our work. This gives us an opportunity to see shortfalls, blockages or areas for improvement every day (the boards sit in our development area).
• We are looking at the system as a whole, not the localised productivity. Having one productive member in a system that doesn’t cater for this productivity is hindering progress.
• Kanban brings in to play a “pull” system. This is where the next stage in the lifecycle essentially pulls in work. In our example we have a “deployed” and a “test” column. This means that the Testers can pull in work items to work on, rather than having a number of items pushed towards them.
• Bottlenecks and breaking of WIP limits are more visible in real-time. This means the team can pull together to get the work items flowing and the WIP limits adhered to again.
• We can identify clearly areas of “waste”. Waste is typically considered anything that is not adding value, or slowing down/impeding process.
• Measuring the rate at which a feature flows through the kanban board can provide real and accurate data for estimation.
• It also gives us a great opportunity to huddle the team around it each day to discuss progress. This aligns expectations and brings the team together for collaboration and identification of things that are going well, and things that may need to change.

The Kanban board is a visual representation of the work we do. It gives us up-to-date information on how work is flowing through our development process. It’s not a silver bullet solution, but it does give us a more visually way of identifying areas for improvement and a way of seeing our work items moving through the systems.

The beauty of a Kanban system is that it can be used to visualise any type of work item, not just development or manufacturing tasks.

If you want to read more on Kanban then the following links may be useful for you:

http://en.wikipedia.org/wiki/Kanban_board

http://blog.caplin.com/2010/02/16/designing-a-kanban-board-not-as-simple-as-you-might-think/

http://blog.crisp.se/2010/12/03/mattiasskarin/1291361993216

http://agilescout.com/agile-guide-building-a-kanban-board-discussion/

http://www.toyota-global.com/company/vision_philosophy/toyota_production_system/just-in-time.html