KANBAN – basic terms and rules

This article opens a series of texts on Kanban. I am planning 7-8 texts in this area, which will be posted every two weeks.

Let us start from the beginning. What is Kanban?

kanban system— a system created for the tracking of work in progress.

For instance, a kanban board, cards and arrangements connected with work. This all creates the kanban system. In theory, these things have very different meanings but in practice people often cannot see a difference. When people are referring to the term “kanban usage”, they usually think of using some kind of kanban system for the management and optimisation of visual signals, for the purpose of the process evolutionary improvement. This is what we bear in mind while using the word kanban.

Kanban in IT is a method of task fulfilment by a team. Tasks may be requirements in a traditional understanding when developing software as well as errors, notifying of incidents (e.g. as part of ITIL) or other tasks for IT.

Kanban itself is not a methodology of producing software. It is not similar to SCRUM, OPENUP or RUP. Kanban does not focus on roles and products.

Kanban system concentrates on the process improvement.

Kanban overlaps the existing manufacturing process and requires following only three basic rules:

  1. Visualise your flow
  2. Limit your partial work
  3. Manage the flow.

Visualise your work

The first rule is the presentation of a task in a visual form. It may be a self-adhesive sheet or an object in an electronic tool. The visualisation of a task, which was hidden somewhere, helps solve many problems.

Task visualisation enables us to see at what stage in the process the work is. Make the work flow through the following stages: requirements, design, construction, unit test, tests, approval of tests, implementation. Work visualisation will demonstrate at what stage each function is. When you look at a Kanban board you will find out in which phase your work is. Work visualisation will also allow you to identify losses in the process, which you can reduce or eliminate. It will also allow you to identify bottlenecks before they become a real hazard. Looking for bottlenecks will be described in the next post.


Limit your partial done work

The second rule is the essence of all the rules for managing time/tasks. In each of the approaches I am familiar with, namely, GTD, POMODORO, etc., there is one rule. Do one task at one go.

As part of Kanban, a greater number of tasks is allowed. This is determined by the WIP, an indicator that informs us how many tasks we can work on in a given moment. The WIP limit is some kind of limitation but this limitation will enable you to specify how many tasks you are “really able” to perform. Your limited resource is time. In a given moment, on a “desktop” you can have a few tasks open. In a given moment, do only one task.

Manage the flow

The third rule connected with flow management is responding to a team rate.  In other words, the work flow through the board will slow down (tasks will be shifted slower), it will start to be blocked (many tasks will be in the same place) or will stop completely (tasks will wait). When working with Kanban, it is necessary to monitor the team rate all the time in order to detect any risk of a process stopping. Sometimes it is necessary to change the WIP parameter, and sometimes to put more hands to work.

Apart from the rules mentioned, it is worth remembering about establishing clear principles for work. The board visualises the work flow. The determination of the column rules makes up the first principle. This is a key determination of what statuses tasks can take. How to prepare or fulfil tasks in order to transfer them further? These rules are guidelines for actions. Sometimes, after internal consultations, it is necessary to “change” them for a time or permanently.

To sum up, Kanban does not have to change the existing process. It may be implemented in the existing process of software manufacturing. When a team gets to know its basics, there will be improvements. The WIP limits act as a blockade in a pipeline. If a pipeline gets stuck, there will be no workflow in the system, and the team will have to restore the capacity of the pipeline before starting new work.

Kanban system helps to smooth the workflow in order to maximise “capacity” and obtain high quality products.

Compared to many methodologies that introduce break-through changes in the organisation processes, Kanban is an evolutionary system focused on the gradual improvement of the existing organisational processes. Thus, the implementation of Kanban is much easier than other solutions, which makes it an increasingly popular tool in managing any type of work, including Agile Software Development.

In subsequent posts I will describe the board, tasks and partial work. You can find all the entries at: https://michael.wolski.pro/kanban/

More from my site

  • Kanban Reports Process management is a midway to success. The second midway is process monitoring and drawing conclusions. In Kanban, there are indicators, which enable process monitoring. They […]
  • Kanban Bottlenecks Queues and WIP limits, which I discussed in the previous posts,  make up a chief indicator of problems in the flow. They show bottlenecks and when they are going to form. Bottlenecks […]
  • Kanban Workflow In the preceding Kanban post, I wrote about partially done work. I wrote that it is worth limiting partily done work. The WIP (Work In Progress) which is too high results in the fact that […]
  • Partially Done Work In the previous posts, I discussed the tasks and the board in Kanban. In order to be productive, you must focus on one task at a time. Kanban facilitates this process and defines the term […]
  • Kanban Tasks In the previous entry, I wrote about the task board in Kanban. Now I will add some words about tasks and task cards. Kanban tasks are specified by means of a card. Many people prefer […]

Leave a Comment

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

Scroll to Top