After completing this unit, you’ll be able to:
- Describe the problem that Kanban was developed to solve.
- Summarize how Kanban boards and cards help visualize and optimize the flow of work within teams.
- Discuss the benefits of using Kanban for software development.
Kanban is a popular framework used by software teams practicing agile software development. It’s enormously prominent among today’s agile software teams, but the Kanban methodology of work dates back more than 50 years.
In the late 1940s Toyota began optimizing its engineering processes based on the same model that supermarkets were using to stock their shelves. Supermarkets stock just enough product to meet consumer demand, a practice that optimizes the flow between the supermarket and the consumer. Because inventory levels match consumption patterns, the supermarket gains significant efficiency in inventory management by decreasing the amount of excess stock it must hold at any given time. Meanwhile, the supermarket can still ensure that the given product a consumer needs is always in stock.
When Toyota applied this same system to its factory floors, its goal was to align its massive inventory levels with the actual consumption of materials. To communicate capacity levels in real-time on the factory floor (and to suppliers), workers passed a card, or “Kanban,” between teams. On the production line, when a materials bin was emptied, workers passed a Kanban to the warehouse with the type and quantity of replacement material needed. The warehouse had a bin of the material waiting to send to the factory floor. The warehouse then sent their own Kanban to the supplier for restocking. The supplier also had a bin of the particular material waiting, and shipped it to the warehouse. While the signaling technology of this process has evolved since the 1940s, this same just-in-time (or JIT) manufacturing process is still at the heart of it.
Check out this tutorial by Atlassian with step-by-step instructions to set up a Kanban project with JIRA Software.
Agile software development teams today are able to utilize these same JIT principles by matching the amount of work in progress (WIP) to the team's capacity. This gives teams more flexible planning options, faster output, clearer focus, and transparency throughout the development cycle.
While the core principles of the framework are timeless and applicable to almost any industry, software development teams have found particular success with the agile practice. In part, this is because software teams can begin using it with little to no overhead once they understand the basic principles. Unlike implementing Kanban on a factory floor, which involves changes to physical processes and the addition of substantial materials, the only physical things a software team needs are a board and cards, and even those can be virtual.
The work of all Kanban teams revolves around a Kanban board, a tool used to visualize and optimize the flow of work within the team. While physical boards are popular among some teams, virtual boards are a crucial feature in any agile software development tool for their traceability, easier collaboration, and accessibility from multiple locations.
Regardless of whether a team’s board is physical or digital, their function is to ensure the team’s work is visualized, their workflow is standardized, and all blockers and dependencies are immediately identified and resolved. A basic Kanban board has a three-step workflow: To Do, In Progress, and Done. However, depending on a team’s size, structure, and objectives, the workflow can be mapped to meet the unique process of any particular team.
The Kanban methodology relies upon full transparency of work and real-time communication of capacity; therefore, consider the Kanban board as the single source of truth for the team's work.
In Japanese, Kanban translates to “visual signal.” For Kanban teams, every work item is represented as a separate card on the board. This enables team members to track the progress of work through its workflow in a highly visual manner.
Kanban cards feature critical information about that particular work item. This gives the entire team full visibility into who is responsible for that item of work, a brief description of the job being done, how long that piece of work is estimated to take, and so on. Cards on virtual Kanban boards often feature screenshots and other technical details that is valuable to the assignee.
Enabling team members to see the state of every work item at any given point in time, and all the associated details, ensures increased focus, full traceability, and fast identification of blockers and dependencies.
Kanban is one of the most popular software development methodologies adopted by agile teams today. Kanban offers several advantages to task planning and throughput for teams of all sizes.
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 reprioritize 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’re delivering maximum value back to the business. So there’s no need for the fixed-length iterations you find in Scrum.
Shortened Cycle Times
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 can 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.
Multitasking kills efficiency. The more work items in flight at any given time, the more context 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 has four workflow states: To Do, In Progress, Code Review, and Done. They can choose to set a WIP limit of 2 for the code review state. That can seem like a low limit, but there’s good reason for it: developers often prefer to write new code, rather than spend time reviewing someone else’s work. A low limit encourages the team to pay special attention to issues in the review state, and to review others’ work before raising their own code reviews. This ultimately reduces the overall cycle time.
One of the core values is a strong focus on continually improving team efficiency and effectiveness with every iteration of work. Charts provide a visual mechanism for teams to ensure they’re continuing to improve. 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 and a rolling average for the team.
A cumulative flow diagram shows the number of issues in each state. Issues in intermediate states such as “In Progress” or “In Review” are not yet shipped to customers. The diagram shows the continuous status of the issues the team is working on so that if there was a blockage (too many issues in the In Progress status, for example) the team would be able to spot it. The chart you see here is what a healthy project should look like, with a relatively steady stream of work in the “In Progress” state.
We know that continuous integration—the practice of automatically building and testing code incrementally throughout the day—is essential for maintaining quality. Now it’s time to meet continuous delivery (CD). CD 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 can be in the marketplace. And Kanban teams focus on exactly that: optimizing the flow of work out to customers.
Kanban and Scrum share some of the same concepts but have different approaches. Let’s check some of them out.
||Regular fixed-length sprints (that is, 2 weeks)
||At the end of each sprint if approved by the product owner
||Continuous delivery, or at the team’s discretion
||Product owner, Scrum master, development team
||No existing roles. Some teams enlist the help of an agile coach.
||Teams should strive to not make changes to the sprint forecast during the sprint. Doing so compromises learnings around estimation.
||Change can happen at any time
Some teams blend the ideals of Kanban and Scrum into “Scrumban.” They take fixed-length sprints and roles from Scrum and the focus on work-in-progress limits and cycle time from Kanban. For teams just starting out with agile, however, we strongly recommend choosing one methodology or the other and running with it for a while. You can always get fancy later on.
This module gives you a taste of two of the most popular agile methodologies, but this is just the first level. See the resources for more information on Scrum and Kanban.