Kanban is a tool for optimising the flow of value through a process that uses a visual, work in-progress limited pull system.
Kanban is most often used with Scrum or Lean.
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 for Scrum.org.
The four basic metrics of flow that teams using Kanban need to track are:
While Kanban requires teams to visualise their work, visualisation alone isn’t Kanban. Kanban requires a team to:
Kanban is very difficult for new teams to adopt as they are not used to the rigour that is required to manage flow.
Some teams don't want to change the way they work and, rather than adopt Scrum, ask "can't we just do Kanban". This is an excuse to not change and has nothing to do with Kanban. Most of these teams feel that Kanban = a visual board. This is a symptom of cargocult agile.
Scrum is a framework for agile product development whereas Kanban is a tool. They are both complementary. Most advanced agile teams use both. Some key differences in their structure include:
Kanban | Scrum | Prescribed events | None | Sprint Planning, Daily Scrum, Sprint Review, Retrospective and the Sprint |
---|---|---|
Planning | Just-in time | Sprint-sized batches and a formal Sprint Plan | Commitment | Based on capacity. Team members commit to completing work before taking on new work. | Quality (Done), the Sprint Goal, and the Product Goal. Team members hold each other to account. | Core Metrics | Lead time, cycle time, work item age. | Increment of Done by the end of the Sprint | Improvement | Continuous and iterative | Actively planned and executed Sprint-to-Sprint |
Scrum has a minimal, pre-defined structure. When people are used to working in an ad-hoc way, and operate more as a workgroup instead of one team, the structure of Scrum can seem too prescriptive. This attitude has promoted much of the Scrum vs Kanban debate, suggesting that Kanban is a superior alternative to Scrum. The reality is that the discipline required to effectively do just-in-time planning and proactively manage flow is beyond most teams when they are starting out.
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.
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.
All fields are required.