Kanban is a Japanese term meaning “visual record” or “card” or, more succinctly, “signal card”. It originated in Japanese manufacturing and was a central part of Toyota’s “kaizen” (continuous improvement) process. In the mid-2000s it was modified and adapted to software development by David J. Anderson. Contrary to what many think, Kanban is not a development methodology, per se, but rather a workflow process utilizing a pull system. It is a set of management practices with the primary goals of continuous improvement, removing of constraints, and creating consistent flow.
The Kanban board (similar to a Scrum board) acts as a visual control system, showing the flow of value through the development process. Columns on the board represent work states (e.g. To Do, Development, etc.) and each column has strict Work-In-Process (WIP) limits. These WIP limits are at the team level, not the individual level. Some teams use a physical board with sticky notes, but more commonly, Jira Software or something similar will be used. The board clearly shows status and constraints and helps the team self-organize and work together.
The team sets the WIP limits for each column. As a rule of thumb the Development or In Progress column limit should be less than the number of engineers on the team. These limits are in place primarily to: Reduce lead time, reduce late delivery, and discover flow constraints in real-time. Loosely related, but important to WIP limits is that features in Kanban should be broken down such that tasks are relatively similar in size. The team’s cycle time (the average time to complete a task) can then be used to calculate a predictable lead time. Lead time is calculated by dividing WIP by cycle time and represents the time it will take for a brand new story or bug placed at the top of the to-do column to be completed. Unlike cycle time, however, the lead time will vary based on how much work is in progress at any given time.
In Kanban, the focus is on the flow of value rather than the utilization of the team. The Kanban board’s columns do not represent strict hand-offs; they indicate a story’s general state in the development cycle. The team will swarm tasks to stay within WIP limits and ensure consistent flow. Additionally, the team needs to be made up of specializing generalists to reduce skill-set dependencies and highlight opportunities for improving skills. Further emphasizing flow, Kanban replaces Sprint Velocity with the aforementioned lead time.
The major benefits of Kanban are more predictability and more agility. Predictability is increased through reduced lead times and late deliveries. Agility is increased through quicker discovery of constraints and the ability tackle new business priorities and urgent bugs, relatively quickly, without interrupting the flow. Due to a predictable lead time, a Product Owner can tell a business owner with a high degree of certainty when a new feature will be completed.
One potential drawback of Kanban is that it is best suited to mature teams–that is, teams that have worked together for a while and are generally more effective than a newer team. Less mature teams will benefit from the added structure of Scrum.