Kanban in IT

This week I was in a Kanban training. I already knew Kanban, as we use it in our company to plan work for our teams. With this training I could see deeper into the rabbit hole. So I will summarize my learnings with this post.

What is Kanban?

First I want to give a little introduction, of what Kanban is in general and what the goals of Kanban are.

Kanban is a production planning and controlling system. But production is not limited to manufacturing in a common sense. It includes everything you may “build” or “produce” and deliver. So you may also use Kanban in a software development environment.
The history and development of it can be found on Wikipedia, so I will not copy it.

The mean goal is to optimize the production flow. This means to minimize buffers within your system and therefor maximize your plan compliance.

To do so, you align inventory levels with actual consumption, so it also downsizes the storage and you do not need to store a lot of items for a long period of time.

Kanban in IT environments

For companies with IT services, such as software development etc. Kanban helps to reduce stress from employees and visualize and optimize the planning of work items. This also affects the estimation and its compliance of time to market.

I am absolutely impressed by the concept “start where you are“. Which means, that you don’t have to bring in another system that requires a lot of tools and money before you’re sure, whether or not this is what solves your problem.

Visualize work in progress

First you just visualize the actual state of your team, department or company (depending on which flight level you are).

For that, you need to have a card or Post-It with every task of every employee, to see, what he’s actually working on and bring it to a board or wall. Okay, there may be some resistance, making the work transparent, but this is another story, which I will not discuss in this post.

Normally you will find, that there are massive amounts of these cards.
201 tickets on a kanban board

Structuring the process

In the picture above, there is already a structure on the board. This is what you do next. You visualize your process steps with columns. In our company this is Analysis, Development and Testing.  Every column is then again divided into two further columns doing and done. And this is where the pull method starts. Everybody out of work, may pull the next item from the previous done column and start working on it.

Definition of done

Before a card may pass the way to the done column, it needs to fulfill some rules that you define. In our example the definition of done for the development phase is that the software must implement the requirements and the documentation must be finished.

Limit work in progress

When the structuring is done, introduce a limitation for the amount of work that may be stated in one column. This is called Work in progress (WIP) limit. Every column may have a different WIP limit and may change with later insights.
You never put more cards into one column, than its limit allows.

Results

Now this does not yet explain the why. So this is what you do all this for:
With the pull method, which means that you always pull the next card from the previous column, you force that the work within the queue is more important than the unstarted work. And with the WIP limits you make sure that it will be finished, because you cannot bring in more work, as you did not finish the old one. Now the why is simply because unfinished work means already spent costs, but the return will not start, before the work is completely finished.

Imagine a new smart phone. You cannot sell it, before there is an according operating system running on it. Neither can you sell any apps, before the OS is able to execute them. But with the development of the hardware you already spent a lot of money, where there is income, until you finish the OS.

finishing work

The image shows, what happens, when there are several tasks processing at the same time. Finished work means ready for income, where unfinished work means nothing but cost.

Eliminating false assumption

Somehow, there are some false assumptions that lead to the major problems, we try to solve with Kanban. I will list some of them.

Increasing performance

One false assumption that people often make is, that we could increase the output of the system, by filling more into it. But this is not possible! One stage has always the same average performance. Hence, there is no way to change this, except with adding more processing power to it (another machine or a new team member for example). This assumption has often negative effects for employees, as there will be more pressure and stress. But pressure to people does not mean increasing performance (most likely it means the opposite).
Another negative effect of having parallel work is, that context switches always waste a lot of performance (this is true for machines, as well as for employees).

Increasing buffer

The image above shows, what happens, if every stage of the system was filled with work:
The first stage processes more than the second one, which ends in blowing up the buffer between them to an infinite size. But the output of the system stays the same and the only difference is the loss of your plan compliance.

Off time

As there are WIP limits in your system and the bottle neck dictates the performance, there will be off time for other stages.
It would be naive to believe, you could build a system where every stage has the same processing power and that therefore is no bottle neck.

As you may no longer fill more work to your system, you may want to fill this off time with worthwhile task. You can introduce a separate improvement lane. There you fill tasks that can be processed, whenever somebody has nothing to do. Important is, that this is work which can stay on hold for a while and has no direct outcome that another productive task relies on.

Raping the system

There is an interessting blog post that explains, what happens when you stupidly follow the plan and don’t think while performing. Ok the post is about scrum, but in Kanban you may have the same effects, when you do not consider several things. Also the opposite may happen, when you do not respect the following points:

  • You must not ignore the WIP limits. You may change them. But if you do this over short-terms, you can also omit them, as they have no longer a positive effect.
  • You must not fill your input queue with a lot of items, as this would only shift your buffer from the bottle neck there.
  • Every task must appear on the board and therefore step through the whole process. Otherwise the board has no advantage.
  • Nobody is allowed to take items into the input queue than just the team. Otherwise you cannot plan and control what happens.
  • There might be pressure from some stages, stakeholders or from the next (or management) level. You must defend your system and keep the structure. If you add an exception for one person, your structure is busted. But this means also, that you may require the support of your boss or something.

Leave a Reply

Your email address will not be published. Required fields are marked *