Your introduction to Kanban

In a recent post, we provided an in-depth introduction to the Agile methodology and one of its most popular frameworks, i.e., Scrum. There are tons of agile frameworks available to choose from, like Crystal Clear methods and Extreme Programming (XP). Each has something unique to offer. One framework often compared to Scrum, and sometimes even combined with it, is Kanban.

History

Kanban dates back more than 50 years to the Toyota factories of the late 1940s. At the time, Toyota’s car factories were changing their production methods to emulate supermarket models wherein they stock only enough product to meet consumer demand.

It seems straightforward today, but at the time, they placed car orders in bulk upon release based on lofty sales projections. When real-world demand didn’t meet those projections, factories housed the excess inventory until it was eventually sold, or they disassembled it back into parts for future products. This method is obviously pretty inefficient, which is why they needed a way to match inventory levels with consumption.

To communicate capacity levels in real-time on the factory floor, workers devised a card, or “kanban,” system. Whenever a bin of materials was empty, they passed a kanban to the warehouse to order more. The warehouse would send a new bin to the factory floor and in turn, send their own kanban to notify the supplier.

The supplier would then ship more materials to the warehouse. While the kanban themselves are no longer physical notes sent between workstations, the chain of communication for producing stock “just in time” (or JIT) is still the same.

While almost any industry can use this framework, agile software development teams have taken a particular liking to it. Teams today use these same JIT principles to match the amount of work in progress (WIP) to the team’s capacity.

The theory

As complicated as the transition may be from scheduling car builds to setting up whole projects for dev teams, Kanban is based on four core principles that overarch all:

• Start with what you do now
• Agree to pursue evolutionary change
• Initially, respect current roles, responsibilities, and job titles
• Encourage acts of leadership at all levels

The Kanban board

Instead of physically passing notes back and forth between members, teams today organize these stages of production requests using a Kanban board. This board could be a physical whiteboard with sticky notes or a digital board like the ones often incorporated into project management tools.

Physical boards tend to lose their usefulness once a project becomes too complex. This is because they can’t provide much context compared to a virtual board with features for adding things like documents and screenshots. Virtual boards also make it easy to archive and retrieve cards at a later date, whereas post-its tend to get thrown out or lost. Even if you do keep them, they’re likely a nightmare to organize and retrieve information from at a later date. Virtual boards allow for more traceability and context, with the added bonus of being accessible from any location with a Wi-Fi connection.

Things to know

Most boards incorporate three basic stages into their workflow: To Do, In Progress, and Done. Development teams also often include a Code Review stage. However, teams can customize their boards to whatever workflow is best for them.

The stage names are not as important as the board itself is. The purpose of the board is to visualize teamwork, standardize workflow, and make blockers more easily identified and resolved.

The Kanban board is also dependent on all team members taking responsibility for being transparent about their work and communicating their capacity in real time. The board is only as good as the integrity of the information it represents.

Across each stage designated on the Kanban board, cards are placed to represent different work items currently in that stage of production. Cards can contain a lot of important information, like who is responsible for each item of work, a description of the task and any relevant documents for context, a time estimate, and more.

Again, teams can customize relevant information to their own needs. As you complete a stage, you move the card across the board until it reaches the final stage.

The benefits of Kanban

Kanban teams are more productive because they are only focused on work that is actively in progress.

Teams pull items from the top of the backlog to work on. Those items are the only things that concern the team until they are complete. Then they move on to the next items that have moved up to the top of the backlog.

If teams choose to assign a specific Product Owner, they are responsible for organizing this backlog. They can do so freely since the team is only concerned with items in progress. Backlog changes don’t cause interruption or distraction for the rest of the team.

Overlapping skill sets means teams can also deliver work in shortened cycle times, a key metric for Kanban teams. Cycle time is the amount of time it takes for one unit of work to make its way through the entire team workflow from start to finish.

When only one or two people have the skill set to complete certain tasks, cycle time often slows. To-do items begin to create a bottleneck in the workflow, and the system breaks down. In Kanban, teams have shared skills, which means that things like testing aren’t just left to QA. Developers can step in when necessary, too. It’s the entire team’s responsibility to move items through the workflow.

WIPs

An important metric of Kanban is ‘work in progress,’ or WIP. Teams set limits to the number of items in any given stage to prevent a bottleneck from arising. If a certain stage reaches capacity, team members refocus their energy and swarm that stage to help clear the way and move items along the workflow faster. Addressing issues and delays is, therefore, part of the system itself.

Tracking this process helps teams improve as they go. And it also helps them more confidently forecast delivery estimates in the future.

The final benefit we’ll mention is that of continuous delivery. Continuous delivery, often referred to by its acronym CD, is the practice of releasing work regularly and often.

Some teams release work daily or even hourly. As long as the item goes through the full workflow, it’s ready for release. The faster a team delivers innovation, the more competitive its product is in the current market.

Final Thoughts

Kanban provides teams with a high level of visibility into their work. It also keeps individuals focused on just a few tasks and incorporates identifying and addressing problems in the cycle itself. It’s hard to argue with benefits like that. Especially if you have the right Kanban tools to support it.

And if you’re thinking to yourself, Kanban seems like it would actually pair well with Scrum, you’re not wrong! Many teams actually blend the working styles together in what’s cleverly called “Scrumban.” You can learn more about Scrumban in this post.

This post was originally published on October 28, 2016, and updated most recently on January 30, 2021.