Why do 90% Get Kanban Wrong? How to Get it Right?

It's been a long while since Kanban became a new way of managing knowledge-based work, but this doesn't mean people get it, unfortunately. It still remains widely misunderstood.

Misconceptions:

Some of the most often misused concepts are:

• Kanban is meant to be applied for non-timeboxed workflows only
• There are no real prescribed methods of working in Kanban, and therefore it shouldn't be compared to Scrum, XP or other methods
• For the same reason - no rules, apart from the one of “start with what you're doing now” - when people getting started with Kanban make up rules anyway, they all get confusing for the beginners which then tend to stick to the initial wrong Kanban understanding
• The connection to the original Kanban as a stock management system brings not necessarily good understanding of the method as it is used now for knowledge based work.

The Kanban Lens:

Now, that we see what are the common problems with getting to know what Kanban is, let's take a look at the easiest way – according to Jesper Boeg – of getting a good grasp of Kanban. He proposes that we use Kanban as a lens, through which the project is being perceived, so that the object we're watching does not change by our looking, but the way we perceive it does.

How to construct the lens then?

The most sensible way to go about setting the lens right is by sticking to the well established few rules and practices:

• Start with what you know and what you do now
• Focus on evolutionary change
• Allow and fuel leadership and ownership at all levels of the process
• Visualize and manage the flow + limit WIP + set policies as explicit + create feedback loops + make improvements a collaborative effort.

The key valid points that teams need to get right to do Kanban:

Visualize

Most Agile-aspiring teams use some sort of a board. They probably have about 3 columns in there (to do – doing – done). The point that Kanban makes about visualization of the workflow aims at getting all of the process steps in, from start, through QA and Waiting, to delivery. Getting all of the steps visible makes for a better chance of understanding what the team actually works on and what takes the longest.

Limit WIP

However self-explanatory this may sound, there are easy ways in which we misunderstand and misuse this. It's not good enough to limit the work in progress within the one key column, as this has the potential to create more chaos than success. The idea behind WIP limits is that it should spread through the entire process (limits in all “working” type column), as this is the only chance of creating a real pull system – one that allows for finishing work, more than just constant starting new.

Flow management

The value of the metrics that Kanban provides is often marginalized and disregarded. It is them that we're meant to be looking at in search of the information about when are the team actually adding value to the work ordered by the customer, and when the adding of the value pauses (potentially for too long). By careful observation of the Cumulative Flow Diagram and Lead & Cycle Time, we stand an actual chance of noticing whether the flow is right or not and if it can perhaps be improved.

Policies

There may be enough talk about policies within teams, but what the “make policies explicit” principle really means is actually fitting them not just right to the process that is being followed, but also simply placing them right on the board, for all on the team to see and follow. This will actually ensure that they are being taken into consideration. Also, should they get outdated, it'll be much easier to alter, when met with everyday.

According to Jesper, making sure that these core Kanban principles are well understood and applied increases our chances of succeeding and of getting the biggest of Kanban advantages – a continuous improvement of the process. So, stay in line with the Kanban ideas as they are meant to be understood, and things may work out quite perfectly.

Read our article on Kanban problems »