Kanban vs Scrum
The Kanban Method is an agile delivery framework that has its roots in the Toyota Production System (TPS). Its goal is to deliver maximum customer value at minimum cost. Kanban uses 3 fundamental practices to accomplish this goal:
- Visualize the workflow. This involves laying out the workflow on a board with columns and cards and helps teams understand how the work is actually done in a step-by-step way to provide the product or service to a customer.
- Manage Work-In-Progress (WIP) by setting limits on the number of work items in each workflow state. This ensures that work is pulled into each stage of the process only when there is available capacity.
- Continuously measure and improve the process by systematically removing all sources of waste and delay.
Kanban uses a small number of key measurements to support improvement efforts.
Lead Time. This measures how much time it takes for a work item (for example a task or user story) to go through a process from end to end.
Throughput. Throughput is a measure of how many work items can be delivered per unit of time by the process. For example, cellphones manufactured per month, or user stories delivered per day. It measures the production capacity of a system.
Work In Progress (WIP). A fundamental ingredient of the Kanban Method is limiting work-in-progress.
The relationship between these parameters is described by Little’s Law.
This can be visualized as:
The above visualization makes it fairly obvious that Lead Time (the time to get serviced) is directly proportional to the length of the queue in front of the server (the green circle in the diagram). Little’s Law can help us understand any basic situation where we have a queue, like how much server capacity do we need in a coffee shop to avoid turning away customers. What may not be so obvious is that overloading the server beyond it’s capacity can make the problem even worse. Overloading a server leads to multi-tasking, increased transaction cost overhead, and poor quality. This negatively impacts the denominator in our Little’s Law equation, slowing throughput and hence increasing lead times. We all have experienced the joy of sitting on a grid-locked (zero throughput) highway when it has been overloaded beyond it’s available capacity. This phenomenon applies anywhere we have a workload being serviced by a server of finite capacity. In Kanban, this problem is controlled by applying WIP limits to each step in a workflow, and the challenge for any Kanban Team is to discover the optimum WIP limits in their workflow to maximize flow and throughput.
The analysis of flow through any Kanban system is done most effectively using a Cumulative Flow Diagram. The CFD Diagram is one of the primary artifacts of the Kanban Method, and is used to measure flow performance and drive improvement. The CFD shows the distribution of work in each of the workflow states and how that distribution trends over time. Each band in the diagram shows the number of work items in each state of the workflow. In the example below, we see an increasing accumulation of WIP, which should trigger a closer look at this team’s ‘In Progress’ state to identify bottlenecks and other sources of delay. Or, it could be that the arrival rate of new work items simply exceeds the team’s capacity.
The Kanban method is ideal in situations where a product or service is reasonably well understood such as product support, manufacturing or well-understood software development programs. The following assumptions are generally true:
- The customer knows exactly what they want
- The development team knows how to build it
- Nothing will change
In many software programs however, especially those involved in innovation and discovery, most or all of these assumptions are never true, and what works better is an empirical approach, where teams advance in small steps or increments, inspecting and getting feedback on their work at the end of each step, and then making any needed adaptations to the product, or the process being used to create it. This is exactly what Scrum is designed for.
Kanban does have feedback loops and uses them to inspect and adapt for the achievement of maximum value at minimum cost. It accomplishes this by not only optimizing WIP limits for each step in a workflow but by also removing bottlenecks and waste from the process. The primary focus is on process improvement. The primary focus of inspection and adaptation in Scrum is on the product itself, and how to evolve the best possible solution in an environment of uncertainty and rapid change. It does this by proceeding in small increments followed by product adaptations in response to user and stakeholder feedback. Yes, Kanban can be used to build software products, but is likely to be more successful where the product is well understood and less susceptible to constantly changing requirements. In cases where requirements and solutions evolve through collaboration and feedback between delivery teams and business stakeholders, and where planning needs to be adaptive vs. predictive, then the Scrum framework provides a sound approach. Kanban is a much better fit in the pursuit of production excellence, whereas Scrum provides a solid framework for innovation. Bottom Line: For software development, start with the Scrum Framework. Work to achieve a stable velocity. Then consider adding Kanban practices such as WIP limits and Kanban metrics to support improvement efforts.
