Kanban is a project management tool. It has its origins at Toyota in car manufacturing. I use its ideas in Software Development though, and will therefore take a look at it through this lens.

1 The What

When using Kanban, the main thing necessary is a board - the so-called Kanban-Board. On this board there’s multiple columns, each representing a state for a task that can be worked on. On the left there’s a pool of tasks that haven’t started yet, and at the very right there’s all tasks that have already been done.

1.1 Rules

A task should not skip any columns, as that would indicate that it isn’t actually done.

A task may also not move left. Instead, if necessary, create a new task further left on the board, which will catch up with the original task. Moving left on the board wouldn’t make any sense, as it would indicate that a task is “less done” than before.

Each column has an upper limit on the amount of tasks that are allowed to be in that column. This upper limit is not the amount of people in the team, but could be smaller or bigger, depending on the column and the team.

Each person may only work on one task at a time.

2 The Why

There’s a quite a few reasons for implementing Kanban:

2.1 Identifying choke-points

By having a limit on columns it is very easy to see when tasks start piling up somewhere, which means measures can be taken to solve those issues. It also means empty columns can be identified that should not be empty, which means measures can be taken for that as well.

Identifying these problematic points in the flow of tasks is a great way to improve productivity. It is easy to make goals such as:

  • “By the end of next week, column C should not have had less than three tasks in it at any time.”
  • “By October 20th columns A, C and E should have been empty 90% of the time.”

Those are clear, measurable goals, which makes determining their success easy, and everyone knows what to work towards.

2.2 Identifying problem-tasks

Some tasks tend to be problematic in that they never actually get done, but always hover in some to-do state. These tasks are easy to identify using a Kanban board, since they will clutter up the tasks on the board and are clearly visible all the time.

Identifying these tasks is the first step in solving the underlying problem they have.

2.3 Overview over who is doing what

The board is a great way to see who is working on what right now. This means it’s easy to figure out who to ask for questions on what. It also makes it easy for team members to see what is currently going on and to identify people that should talk with each other due to the tasks each is working on.

2.4 Tasks need to be finished to start new tasks

The limits on columns can force people to first do tasks such as code-review before starting a new task, as there’s otherwise no space on the board for a new task. This ensures that tickets will actually be done, instead of all piling up in one column, waiting to finally get finished. Twenty nearly-done tasks are worth nothing compared to 3 actually done tasks.

2.5 Nobody ever works on more than one thing

No-one is able to truly do two things at a time. If someone would have multiple tasks they are working on on the board, that indicates that the tasks were not properly assigned to people. Both tasks will take unnecessarily long, as whoever is working on them tries to finish them both at the same time. Other tasks that might be dependent on them all have to wait. If the person would first do one task and then another, work could already be started on the dependents of the first task when that one’s done, allowing for more flexibility and saving time overall.

2.5.1 Tasks are made small and manageable

If it is not possible to only work on one thing at a time for some reason (or rather it appears that way), one possible reason is too big tasks. If a task is too big, the person working on it takes quite some time. If in that timeframe the need for a high-profile bugfix arises, it’s much harder to first finish what they are working on before fixing the bug.

(Note that there are valid reasons for working on two things if there’s a mission-critical bugfix - sometimes the developer should just immediately stop doing what they were doing and worry about the bug. This should be an exception though, and if it isn’t, there’s something fundamentally wrong in the development workflow.)

That means if team member identify the problem that tasks are too big to only work on a one thing at a time, the team can spend effort on limiting each task’s scope. This means team members are more flexible, and it is easier for other members to pick up somewhere someone else left off. It also means that some things are actually finished before starting smaller tasks in a larger scope - ensuring that something will be done in the end, if maybe not everything.

2.6 Requires a proper definition of done

The columns on Kanban board represent the different phases a task needs to go through to be considered done. In software development that could mean:

  1. Implementation
  2. Review
  3. Testing

Or anything more complex or simpler. Either way, it does require the team to have a clear definition of this (Advantages).

3 Pitfalls

3.1 “Waiting for…” columns

A Kanban board should never have columns that represent tasks in a state of being done with one step, but not being worked on in the next. These columns just allow more tasks to be on the board than could be worked on by the team, and they can hide choke-points. Additionally, they enable tasks to just stay dormant on the board, without ever being worked on, which is what Kanban is supposed to prevent.

Imagine Bob is working on a Login feature, which is represented by a task on the Kanban board. Once he’s finished coding, he moves it into a “Waiting for Review” column. The task can now freely stay there, while Bob already picks up the next thing to implement. What he doesn’t notice is the fact that the “In Review” column is already full. This means instead of actually getting some tasks that are near-completion actually finished, he instead starts work on yet another thing. Also, there might be a bunch of other tasks “Waiting for Review”, which Bob also doesn’t touch - either because he doesn’t want to / need to to continue working, or because the “In Review” column is full.

If instead there was no “Waiting for Review” column, here’s what would’ve happened: Bob finishes implementing the Login functionality. He’d like to start working on something else. But the “Implementing…” column is already full! That means he’ll have to move a task from that column to the next. Which would be the “Review” column. That column is also full though! Now Bob needs to take any of those tasks and move them to the “Merging…” column, which might come after “Review”. The result: Bob has actually finished a task that’s ready to be shipped. Also, there’s now a free spot on the “Review” column, meaning he can take any task that was implemented by someone else and review it. Now he’s gotten one task finished, and one closer to being done. This is the point where he can start work on something new. However, the amount of tasks being worked on right now stays at a constant, manageable amount.

If Bob can’t actually pick up a task to get it further to being done, he can instead go and support any other team member that is currently working on one of those last steps that’s blocking Bob from starting something new. Additionally, the team can talk about whether this situation was okay, or whether something went wrong which caused this blockage.

4 Backlinks   backlinks