Kanban Agile Framework, Kan Ban flow, Kanban methodology, Kanban board, Kanban WIP, Kan Ban system, Kanban meaning, Kanban principles
Kanban is a strategy for optimizing the flow of value through a process that uses a visual, pull-based system. Kanban is designed to manage a continuous workflow by visualizing work as it moves through a process with no timeboxed development cycles and it focuses on maximizing efficiency by identifying potential bottlenecks and fixing them so that work can flow at an optimal speed.
Kan ban, which translates to sign-board, has its roots in the Lean mindset and was initially created in the Toyota automotive factory in Japan around 1940 out of the need to visually understand the workflow, the work items, while identifying easily the bottlenecks in the kan ban flow of production. Over time, Kanban was updated and it became a popular Agile software development framework.
Kanban theory
Kanban draws on established flow theory, including but not limited to: systems thinking, lean principles, queuing theory (batch size and queue size), variability and quality control. Continually improving a Kanban system over time based on these theories is one way that organizations can attempt to optimize the delivery of value.
The theory upon which Kanban is based is also shared by many existing value-oriented methodologies and frameworks. Because of these similarities, Kanban can and should be used to augment those delivery techniques.
Kanban principles
- start with what you do know – there is no need to adapt the organization to use Kanban, instead Kanban starts from how your organization is currently working
- agree to pursue incremental change – unlike in waterfall where a lot of time is used and a huge amount of money is spent in order to get value, as an Agile framework, Kanban delivers value more often, but in smaller increments and changes are following the same incremental and evolutionary path, building on top of previous small changes
- respect the current process, roles, responsibilities and titles – there is no need to change organizational structure, processes, roles, responsibilities nor titles in order to apply Kanban, which builds over what currently exists in place
- encourage acts of leadership at all levels – Kanban teams are self-managing teams, they do not need overseeing to be on track, they are reaching for assistance when required and they decide together next course of actions and changes
Kanban board
The heart of Kanban is the Kanban board, which is a physical board or a virtual tool that helps to visualize the workflow and bottlenecks, where work items are represented as Kanban cards that move around the board through different statues in the production flow.
Kanban cards contain the details and references of the particular work items that run through the system. As they change status during their lifecycle, they are being moved on the Kanban board to the column that corresponds with the specific status reached and the timestamp of the movements through the Kanban board is tracked on the Kanban cards.
Kanban team members are not being assigned to work items or Kanban cards, instead, because Kanban is a pull methodology, team members go and pull work from the backlog themselves. In order to deliver the highest value faster, the backlog is sorted by priority, so the top cards available to pull are the ones having the top priority. Kanban team members pull the cards representing work items they are confident to deliver to the completed state based on their competence and based on the priority of the cards.
When cards are moved in a Kanban system from a status column to the next one, time is logged for any change in status from when the card is pulled from the backlog and goes to various statuses until its completion. The timestamps are used to calculate various Kanban metrics in regards to flow and bottlenecks.
A very simplistic set of columns and statuses for the cards on the Kanban board could be: to do, in progress and done. A more advanced type of statuses could be: backlog, ready, in progress, waiting, review, acceptance, deployment and done. Any column can have specific policies documented in regards to what rules does a work item need to respect in order to enter or exit a specific Kanban flow status column.
Kanban practices
- visualize the workflow – know the necessary process steps, see the cards move through different statuses on the Kanban board and the general overview at any given time
- limit work in progress – WIP – do not move everything to in progress, instead limit how much the team can work on at the same time and get them done to deliver small increments of value faster, state maximum number of items allowed per bucket and review regularly
- manage the flow – Kanban board shows the flow, bottlenecks and waiting steps, so the need is to make sure the items flow with ease and efficiently through the various statuses by continuously improving the Kanban flow focusing on bottlenecks, unnecessary steps, lead time, cycle time and throughput
- make process policies explicit – Kanban itself is not forcing rules, but it lets the organization create a shared understanding of when to move things from various statuses by creating explicit policies and procedures that manage the flow of work and establish a common understanding for team members
- feedback loops – because Kanban is not timeboxed and work items flow continuously through the system, Kanban is not very strict about the cadence of the feedback, retrospective, inspect and adapt ceremonies, but they are important for continuous improvement in value delivery
- improve collaboratively, evolve experimentally – not all work items should be assigned to one team member that gets them completed, instead some tasks can be worked on together by more team members collaboratively, making sure that tasks are done appropriately, Kanban team members experiment in ways of doing them, test the results to see if the specific way was successful and learn from different experiments
Kanban metrics
- Lead time – the amount of elapsed time between when the work item was created and put into a to do column until the date that it was completed
- Cycle Time – the amount of elapsed time between when a work item started by being pulled until when the date that it was completed
- Throughput – the exact number of work items completed per a given unit of time
- Work in progress – WIP – the number of work items are being worked on at any given time
- Work Item Age – the amount of elapsed time between when a work item started and the current time
- Flow Efficiency – the percentage of total lead time spent actually adding value (or knowledge) versus waiting – active work time / lead time * 100%
- Cumulative Flow Diagram – CFD – shows the stability of your process over time and demonstrates the cumulative arrivals and departures of work items
Little’s law
Little’s law states that the average number of items within a system is equal to the average arrival rate of items into and out of the system multiplied by the average amount of time an item spends in the system. Little’s Law explains the relationship between queue size, waiting time and processing time.
In a Kanban system, WIP limits are applied to each process state – outstanding tasks must be completed before new tasks can enter a process state. Limiting work in progress in Kanban allows the arrival and departure rate of tasks (throughput) to stay roughly the same in order to apply Little’s Law and get accurate results.
Little’s law in Kanban flow
The three Kanban flow metrics are intrinsically linked by a very straightforward and very powerful relationship known as Little’s Law:
Average Cycle Time = Average WIP / Throughput
This means that if two of the three values are known, the third value can be calculated – without knowing anything else about the tasks, team or project:
- Average Cycle Time = Average WIP / Throughput
- Average WIP = Throughput * Average Cycle Time
- Throughput = Average WIP / Average Cycle Time