Kanban

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.

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.

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.

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.

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.

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.

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).

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.