A brief introduction to Kanban

Kanban is another framework used to implement agile. Back in the 1940s, Toyota optimized its engineering process by modeling it after how supermarkets stock shelves. Supermarkets stock just enough products to meet consumer demand, a practice that optimizes the flow between the supermarket and the consumer. Because inventory levels match with consumption patterns, the supermarket gains significant efficiency in inventory management and optimizing for the customer. When Toyota brought that idea to its factory floors, teams (such as the team that attaches the doors to the car's frame) would deliver a card, or "kanban", to each other (say, to the team that assembles the doors) to signal that they have excess capacity and are ready to pull more materials. Although the signaling technology has evolved, this system is still at the core of "just in time" manufacturing today.

Kanban does the same for software teams. By matching the amount of work in progress to the team's capacity, kanban gives teams more flexible planning options, faster output, clear focus, and transparency throughout the development cycle. 

Flexibility in planning

A kanban team is only focused on the work that's actively in progress. Once the team completes a work item, they pluck the next work item off the top of the backlog. The Product Owner is free to re-prioritize work in the backlog without disrupting the team, because any changes outside the current work items don't impact the team. As long as the product owner keeps the most important work items on top of the backlog, the development team is assured they are delivering maximum value back to the business. So there's no need for the fixed-length iterations you find in scrum. 

Minimizing cycle time

Cycle time is a key metric for kanban teams. Cycle time is the amount of time it takes for a unit of work to travel through the team’s workflow–from the moment work starts to the moment it ships. By optimizing cycle time, the team confidently forecast the delivery of future work.

Overlapping skill sets lead to smaller cycle times. When only one person holds a skill set, that person becomes a bottleneck in the workflow. So teams employ basic best practices like code review and mentoring help to spread knowledge. Shared skills mean that team members can take on heterogeneous work, which further optimizes cycle time. It also means that if there is a backup of work, the entire team can swarm on it to get the process flowing smoothly again. For instance, testing isn't only done by QA engineers. Developers pitch in too!

In a kanban framework, it's the entire team's responsibility to ensure work is moving smoothly through the process. 

Efficiency through focus

Multitasking kills efficiency. The more work items in flight at any given time, the more contexts switching, which hinders their path to completion. That's why a key tenant of kanban is to limit the amount of work in progress (WIP). Work-in-progress limits highlight bottlenecks and backups in the team's process due to lack of focus, people, or skill sets.

For example, a typical software team might have four workflow states: to do, in progress, code review, and done. They could choose to set a WIP limit of 2 for the code review state. That might seem like a low limit, but there's good reason for it: code that hasn't been reviewed not only hasn't shipped yet, but may need significant re-work before it is ready to ship. So it's important to take action on code reviews right away, and setting a WIP limit helps the team hold themselves accountable to that. It forces the team to knock out those reviews before pulling in new work. 

Making metrics visual

One of kanban's core values is continuous improvement. But how do teams ensure they're continuing to improve? One word: visuals. When the team can see data, it's easier to spot bottlenecks in the process (and remove them!). Two common reports kanban teams use are control charts and cumulative flow diagrams.

A control chart shows the cycle time for each issue as well as a rolling average for the team. 

ProTip: The team's goal is to reduce the amount of time an issue takes to move through the entire process. Seeing the average cycle time drop in the control chart is an indicator of success. 

Moving toward continuous delivery

We know that CI–the practice of building and validating code incrementally throughout the day–is essential for maintaining quality. Now let's meet CI's older, more sophisticated cousin: continuous delivery (CD). This is the practice of releasing work to customers frequently–even daily or hourly. Kanban and CD beautifully complement each other because both techniques focus on the just-in-time (and one-at-a-time) delivery of value.

The faster a team can deliver innovation to market, the more competitive their product will be in the marketplace. And kanban teams focus on exactly that: optimizing the flow of work out to customers.