Kanban is a tool for optimising the flow of value through a process that uses a visual, work in-progress limited pull system.
There are a number of interpretations of how Kanban is defined and used. It was originally developed by Taiichi Ohno, an engineer at Toyota, to improve manufacturing efficiency and monitor inventory levels to remove waste.
In 2004, David Anderson published the book “Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results”, which covered concepts such as flow, bottleneck, visual control and cumulative flow diagram, all of which he later incorporated into the Kanban method in 2010.
In 2007, Daniel Vacanti helped to develop the Kanban Method for knowledge work and managed the world’s first project implementation of Kanban. Together with Yuval Yeret, he developed the Professional Scrum with Kanban course.
While Kanban requires teams to visualise their work, visualisation alone isn’t Kanban.
Scrum is a framework for agile product development whereas Kanban is a tool. They are both complementary. Most advanced agile teams use both.
Kanban is often chosen by teams who feel Scrum isn’t suited to their work. As Kanban is a tool, however, there is no such thing as a “Kanban Team”. Many teams who don’t wish to change the way they work opt to simply visualise their work and call it “Kanban”. Kanban, however, is much more than just visualising work.
Kanban is used by teams to optimise the flow of their work. Teams, therefore, need another framework such as Scrum or Lean, to assist with work structure that Kanban can then be applied to.
The four basic metrics of flow that teams using Kanban need to track are:
Kanban is a strategy for optimising flow. The practices in the Kanban Guide for Scrum Teams help enhance and complement the Scrum framework and its implementation.