Kanban Principles and Properties

Sofiia.
3 min readAug 5, 2020

Kanban is based on a continuous flow model, where you try to optimize your existing software development process. Technical Kanban is a practice that was borrowed from Toyota’s production system. To understand Kanban, let’s put it next to a Scrum process so we know how different it is.

In Scrum, we work in one to four weeks iterations, and the product changes over time. As we complete each cycle, we may get feedback from the client, and we may change what we want to build.

Kanban doesn’t prescribe fixed iterations or any new practices. It’s a set of properties and principles that help optimize the software development process as long as that process is a continuous flow. Tasks from the backlog are moving through the software development pipeline and the finished product is coming out at the other end of the pipeline. This is an adaptive process because as tasks are getting done, we can get feedback from the customer and change the backlog, but in the end, we get the whole product.

Kanban optimizes the software development pipeline by a set of principles and properties. Let’s imagine a team has a process where the work items go from backlog to analysis, developing, testing, and then to release.

Kanban Property #1: Visualize Your Workflow

To visualize the workflow, you create a visual board. For each step of your process, you create a column. In some columns, you add sub-columns ‘Doing’ and ‘Done’. If the work item is being processed, then it will be in the ‘Doing’ sub-column. If it is done, then you will move it to the ‘Done’ sub-column. As the work is being done, the work items are moving on the board to represent where each item is.

Kanban Property #2: Limit Work in Progress

If there are no limits on the number of items in the column, items pile up and slow the delivery. Kanban property ‘Limit Work in Progress’ helps to identify such situations and resolve issues.

‘Limit Work in Progress’ (WIP) means that for each of your columns you define the maximum number of items. WIP limit calculates both doing and the done. You can’t take the new item to work on if your column reached its limit.

In this case, the developer and the tester can’t take new tasks, the flow has stopped. The team should discuss why the tasks are not moving from the test. The first reason could be that the code is buggy. In this case, the developer can do his job better and fix some bugs. The second reason could be that there are not enough people in testing. In this case, the developer can help test.

If the flow stops once, this is ok, you don’t need to do anything. However, if it will happen again, then it is a permanent problem and you need to manage the flow.

Kanban Property #3: Manage the Flow

When the flow stops regularly, you should find the reason and solve the problem. For example, you can add more people.

Kanban Property #4: Make Process Policies Explicit

The kanban board will work well only if team members are moving the cards from one state to another consistently. However, everyone may have a different understanding of when to move or not.

Kanban property ‘Make Process Policies Explicit’ means that you define exactly, what are the policies that the team will follow. For example, the definition of done for each of the steps gives a clear understanding to the team members when they can move items.

Kanban Property #5: Improve Collaboratively

Team members should work collectively or collaboratively. Everybody in a team should know the constraints and how each process works, to be able to have meaningful conversations and fix the issues in the flow.

Kanban Principle #1: Start With What You Do Know

Start with the current process.

Kanban Principle #2: Agree to Pursue Incremental, Evolutionary Change

Slowly find out where the roadblock or where the bottleneck is, and fix that.

Kanban Principle #3: Respect the Current Process, Roles, Responsibility and Titles.

Change roles and titles only when you find an issue with the current flow.

--

--

Sofiia.

Project and product manager. Writes about Agile, Scrum, Software development life cycle.