Kanban is basically a process or workflow with an emphasis on visualization. It’s used within manufacturing and software development (or anything else for that matter).

See Kanban (development) and Kanban on wikipedia for much fully explanations as to what Kanban is.

I’m (currently) only interested in learning and using Kanban with software development, so this post (and probably any subsequent posts, unless stated otherwise, will also assume the use of Kanban within the development of software).

Disclaimer: I am not a seasoned Kanban expert, the title of this post is not so much about me trying to teach somebody else how best to use Kanban but instead is about my understanding and self-learning regarding Kanban. So please don’t read this post as a definitive guide to Kanban

At it’s heart, Kanban is very simple. It’s aimed at giving a visual representation to current work, or WIP (both Work In Process and Work In Progress are terms associated with the acronym WIP). Generally the preferred method of visualization is via a Kanban board, a physical representation of groupings of work (usually using columns) but when teams are remote or prefer to, digital representations of this board can be used. As stated, usually the group (the development team, management, test team etc.) would define columns on the board which represent states within the flow of their work practices. Each work item would be represented by a sticky note, using different colours to represent different information, such as maybe a red sticky for a bug or the likes.

Whilst a physical Kanban board can be anything, from a Window to a wall as long as it can be divided into columns and accept sticky notes, for the sake of simplicity I shall assume the Kanban board to be a white board (note: there are various bits of software that can help you to work with Kanban, I actually use kanbanflow.com at the moment, but to keep things simple, we’ll only talk about the physical representation of a white board in this post).

The Kanban board

So we’ve got ourselves a whiteboard and we’re calling this our Kanban board but what do we do with it?

The first thing we need to do is, as a team, including not just software devs but others that are integral to the development process. We need to define columns on the board, that in turn define our works flow for taking a task/use case/user story (or the likes) from a start position to a defined “done” position.

Now the start position might be defined as when work has completed analysis as is ready to be assigned to a developer or maybe even going back further in the process to include “gather requirements”. It’s really down to the workflow process the team defines. In the case of a team using Scrum one might define the start position as the Backlog for example.

We also need to define the end position on the board, now this might be when the dev team has completed and checked in their work to some source repository or better still when the item is actually released to production and confirmed as working by the customer/user.

Obviously work doesn’t just start and end so the team also needs to define the steps in the work flow between the start and end. If the team has trouble defining these phases within the workflow upfront, the Kanban board can simply evolve over time. Simply implement columns on the board to indicate the current feelings on the workflow and use this visualization to be the starting point for further discussions.

So let’s put together something a little more concrete now, let’s assume we’ve either drawn or used sticky coloured tape to define the columns “Backlog”, “In Development”, “In Test”, “Ready for Deployment”, “Deployed” and “Done”. So our board will now show, from left to right the process of work being added to the “Backlog”, then when an item is taken/assigned to a developer it’s “In Development”, when the developer complete’s their work it’s going to go to “In Test”, once the test team are happy it goes into the “Ready for Deployment” column, then (assuming in this case that there’s no continuous deployment) it’s then “Deployed” and finally the user/customer uses the functionality and it’s “Done”.

We can possibly better refine this workflow, by noting that just because a developer may have completed work the work item may not currently be in test, so we might either introduce a new column “Awaiting Test” or we might replace “In Test” with the column “Test” and have this span two columns “Awaiting Test” and “Done”, equally we might prefer to actually have both “In Development” and “In Test” have the columns “In Progress” and “Done”. This way when work is taken off the “Backlog” by the developer it goes “In Progress” and when completed in the “Done” column. The the testers might take an item from “Development | Done” and place into their “In Progress” column before completing and placing in their “Done” column.

The point here is that the make up of the columns which visualize the workflow can be changed to suit the way the team works and there’s no right or wrong configuration of the columns.

The stickies

Anyone who’s seen a Kanban board will have seen the sticky notes. As already mentioned, sticky notes are used to represent the work items or user story. They should have a short but obvious title and short description. If need be, referring to some other documentation whether physical or electronic where further in depth information may exist.

We move the sticky from it’s start column through the Kanban board and we may add information to the sticky as it goes, for example placing a dot on the sticky for each day it’s taken or noting anything that’s blocked it. Again anything you add to the sticky needs to be brief and not overload the card with information.

Colours should be used to denote different types of work. For example a defect/bug might be represented with a red sticky note. Then a quick look at the Kanban board will immediately show if defects are taking over the WIP in which case, the team may need to look at the quality of the work to see how such defects are making it into the software.

Avatars or who’s working on what

Whilst the Kanban board and sticky notes denote the work item and it’s place in the overall workflow process it’s also beneficial to tell, at a glance, who’s working on an item at any particular time. Using a magnetic whiteboard we could create Avatars to represent team members or even just name tags. When a member of the team starts work on something they place their avatar or name tag over (say the corner) of the sticky and at a glance the team can see what’s in progress, where it is and who’s working on it.

The book “Kanban in Action” suggests that choosing tokens representing (for example) monopoly tokens or in the book if I recall they talk about pictures of dogs being used it not a good idea. These, they point out, are not good because you then have to ask who’s the Monopoly boot or the Springer Spaniel or whatever – ofcourse you can get around this or just get used to who’s who but bare this in mind when choosing the Avatar or other type of token to be used that you want something that’s easy to identify quickly.

Another way to organize the Kanban board (if the team is small enough) might be to create rows with each person’s name/avatar on. Then simply place an item in the correct column in the row associated with your name to denote you’re working on something.

Limiting WIP

So at this point, hopefully, we can create a Kanban, define our workflow process, create our work items, see at a glance who’s working on what, whether there are bugs or new items etc. But one thing we also need to think about is limiting the WIP.

Limiting WIP may seem counter intuitive, surely our aim is to get as much work in process as possible ? Again, this is something the team needs to experiment with. If developers are busy on too many items and not completing enough the cadence of the workflow slows meaning we could have testers sitting, twiddling their thumbs waiting for work. When work builds up like this we would be better off reducing the work in process and ensuring that the cadence of the flow is increased to ensure work gets through the system as quickly as possible.

In such situations we might place a number above a column to denote (for example) that only three items at a time should be in process In Development. So no new work should enter the In Development columns until an item is removed from the column and so on.

If, on the other hand we find ourselves block due to the WIP limit we could ofcourse increase the limit or maybe the limit is fine but occasionally we need to help out colleages to ensure any items that are blocked are cleared on moved through the workflow.

Surely there’s more to it than that?

In essence, that’s all there is to it, but ofcourse we might find as we evolve our Kanban that we need to cater for expedited work items. Maybe something that is business critical or possibly a regulatory requirement where we need to push an item through the workflow even though it might violate our WIP – in such cases we might create a special “swim lane” on the board, again we should look towards limiting the number of items that could go into this “fast track” route so as to ensure it doesn’t become the norm.

Metrics

To help our processes/work flow to evolve we should also be capturing various metrics. I will not go into this too deeply in this post, but obvious one’s include when an item start’s being worked on and when it’s “done” this will give us a lead time which is in essence the time it took to complete a piece of work from start to finish. We might also wish to track the time in each part of the workflow – thus tracking where things might be getting blocked and so on.

This was a simple introduction into learning Kanban.