How to build a Kanban board

When I arrived here at Allbus S.r.l. as a consultant two weeks ago, the team was busy developing a managerial web application. After having become aquainted with my new colleagues, we started looking for improvements on the informal development process that was in place, and choose a simple tool to collect TODOs and model the flow of work from its definition to completion: a Kanban board.

In the software development field, the word Kanban denotes a simple methodology, much less prescriptive than Scrum and Extreme Programming. Kanban does not tell you if you should write tests before or after the production code they exercise, or how to plan iterations. Actually, it does not tell you even to work in iterations.

In fact, Kanban is a scheduling system, which takes the stories to implement as an input and displays them in the different phases they are in. The only tool needed to implement this system is a Kanban board, which we built in less than an hour with already available materials.

How it works

Here's how a Kanban board works in 100 words.

• You divide the board in vertical columns, one for each different phase in which a story can be. For example you can probably start with a division such as TODO, developmennt, QA testing, Done.
• Then, you set up a number (WIP) limit for each intermediate column, and no more than this number of stories can be in that state at any time.
• Stories advance from the first state to the last one when there is space available: they are pulled in subsequent stages from the developers who intend to work on them.

Goals

What are the advantages of using such a simple tool?

For starters, having a single inbox where TODOs go. I was overhelmed by the list of tasks that come to mind here and which I may explore with the team later. Some sort of collection bin is the primary tool of every time management system, and our first column acts as one.

Another primary goal is to minimize work in progress (WIP for friends). In incremental development, every story either provides 100% value (it is fully functional) or 0% (it's not working and it is not visible to the end user.): there are no intermediate values as they are too difficult to estimate. Therefore, we must favor completing a story over starting development on another one. Kanban places explicit limtis, chosen by the team, over the number of stories in development at the same time.

A consequence of limiting WIP is improving lead time: the time it takes for an item to go from the TODO to the Done state (these are the names we have chosen for our first and last column).

The Done column also shows work completed to the team to augment the self confidence of its components.

WIP limits on each stage are useful in finding the bottlenecks in the development process. When a stage is full, the whole board stalls as well and the focus of the entire team is put on resolving the bottleneck.

By adding and removing columns as they fit in our first-hand experience, we can empirically model the currently informal process. For example, we started with 4 columns and switch to 5 today when we noticed we were dedicating a small design discussion phase to each story prior to jump into the code.

Howto

So here's how we built our Kanban board from scratch, and how you can do it too as a team or as a freelancer.

• We found an old plastic board, which we firmly attached to the wall. A board is more visible than any sheet or online but tracking tool when a team member enter the office.
• We chose Post-it notes to represent stories: each story (or task) goes on a single Post-it, which can be moved along the board. Besides the story description, on the Post-it there is also the date of creation and of completion.
• We used colored adhesive tape to divide the board in columns, knowing that this tape is easy to remove and the columns could be adjusted in the future if they do not fit the team workflow. If you have a white board, you can use markers instead.
• We decided the WIP limits for the central stages basing on the number of developers available for them, so that no one is sitting idle, but we do not embark in ten different stories at the same time. We intend to experiment with different limits of course.
• We got a bunch of different Post-it colors to use for different projects in the same board. The WIP limits are considered global for each column, since even when there are different projects people's time is still the same.

Note that all the team is responsible for each story (cross-functional teams are all the rage in Agile methodologies). Often someone is responsible for a subset of the columns, given its expertise on development or quality assurance or on the business domain.

If you feel some process improvement can be put in place in your team, but you do not want to introduce a full-fledged Agile methodology like Scrum and XP, nothing stops you from trying out Kanban. You can also find useful our Refcard. Happy exploration!