DEV Community

Cover image for Kanban - a brief description and history

Posted on

Kanban - a brief description and history

We can define Kanban applied to agile project management, as the techniques of visual representation of information to improve the efficiency in the execution of the tasks of a project, but this wasn't its origin. The Japanese term Kanban, was applied by Taiichi Onho (Toyota), to refer to the display system used in the production processes that coordinate in an assembly line the delivery of each part on time at the moment it is needed.


At the end of the 1940s, Toyota implemented the "just in time" system in its production, which actually represents a drag system. This means that production is based on customer demand and not on the traditional “pull” practice of making products and trying to sell them on the market.
Its exclusive production system laid the foundations for Lean Manufacturing ("lean production"). Its fundamental purpose is to minimize waste without affecting production. The main objective is to create more value for the customer without generating more expenses.
In the early 21st century, the software industry realized that Kanban could make a real change in the way products and services were produced and delivered. Kanban was proven to be suitable not only for the automotive industry but also for any other type of industry. This is how the Kanban method was born.

How it works

Kanban works around 6 practices

  • Visualize the workflow To visualize your process in Kanban, you will need a board with cards and columns. Each column on the dashboard represents a step in your workflow. Each Kanban card represents a work item. You can have as many columns as you workflow require. Alt Text
  • Eliminate interruptions Changing focus can seriously damage your process, and multitasking (or multitasking) could lead to waste. This is the reason why the second Kanban practice focuses on establishing the limits of the work in process (the WIP limits). It establishes a max number of activities by each stage.
  • Manage the flow The idea is to create a continuous and uninterrupted flow. By flow, we mean the movement of work items through the production process in a sustainable rhythm. What matters is the continuity of the movement.
  • Make Policies Explicit (Promote Visibility) You cannot do well something that is not understood. This is the reason why the process must be well defined, published and promoted.
  • Feedback loops The Lean philosophy admits that regular meetings are necessary for knowledge transfer. These meetings are for service delivery review, operations review, and risk review. Their frequency depends on many factors, but the idea is that they are regular, at a strictly fixed time, straight to the point and never unnecessarily long.

What is the difference with Scrum?

Well here I want to share some differences between the 2 disciplines:

  • Scrum prescribes roles, kanban does not.
  • Scrum works with fixed time iterations, Kanban is more event-driven.
  • Scrum limits the WIP per iteration, kanban limits the WIP per workflow state.
  • Scrum teams are multidisciplinary, in kanban they can be specialists.
  • In scrum, the product stack must be at least one sprint long. In kanban, you must pay attention to the rhythm of task dragging.
  • In scrum, stories and tasks must be estimated and speed calculated, kanban does not measure that tight the speed.
  • Scrum needs a prioritized product stack, in kanban, it is the next story or task dragged from the customer.
  • Scrum prescribes daily meetings, kanban does not.
  • Scrum uses burndown diagrams, kanban does not.

The majority of the information I investigate in the Scrum Manager Body of Knowledge

At last, I just want to say that one isn't better than the other, everything depends on the specific necessities of your project and your team, but I hope this post will be helpful for someone who is beginning the search and thank you very much for reading

Top comments (2)

felipemalinoski profile image
Felipe Matos Malinoski

hey Sabrina, nice post!

Just wanted to point that the Scrum Book don't mention any required estimation for stories or turndown diagrams. This is the kind of stuff that becomes so wide spread that in general people think it's part of Scrum, but it's not defined in the Scrum Book.

Also would be nice to mention that Kanban and Scrum can be combined, by using Kanban as a way to manage the sprint work (another thing that Scrum doesn't have a defined way).

Finally a question: using only Kanban, do you managed to implement a proper PDCA cycle?

sabrinasuarezarrieta profile image

Thanks for your comment and I agree 100% hybrid models are the best, actually in my work expirience I've always used scrum accompanied by kanban