Working on Agile team for a few years I have enjoyed the ability to iterate over large epic stories. Although sometimes it is helpful to track the flow of work through the system. To do this it is helpful to get out the Kanban board and analyze where things are getting bogged down. Perhaps you are putting too many things into Work in Progress or WIP. Limiting your WIP is an important principle of Kanban that we must abide by.
What are the origins of Kanban?
Kanban is a technique for managing workflow through a system that aims for just-in-time delivery without overwhelming the team members. “Kanban in the context of software development can mean a visual process management system that tells what to produce, when to produce it, and how much to produce.” It came to software development from the lean manufacturing movement started at Toyota.
What is Kanban’s History?
Kanban was inspired by store clerks in Japan in the 1940s. Toyota engineers were looking for a way to improve their manufacturing process. They witnessed the “just-in-time” delivery process of goods to the store. Seeing this, the engineers attempted to change their vendor supply methods.
Kanban is Japanese for “card” or “visual signal,” so they gave line workers a Kanban card to signal completion of work. The Kanban card is used when there is a need for new parts. This is used in a “Just-in-Time” manufacturing environment. Through detailed analysis they noticed they were stockpiling large inventories that was very expensive. This change helped them reduce waste and maximize value which helped avoid carrying large amounts of inventory such as tires. In 2005 a new application of Kanban emerged for knowledge work. David Anderson and few others in the software development community began to adopt the techniques from Lean Manufacturing.
The four main principles of Kanban are as follows:
- Visualize work
First create a visual model of your workflow. This will help you observe the work moving through your system. You will begin to see what steps are blockers and what are bottlenecks. You should be able to start with your existing process and gain a deeper understanding of it.
- Limit Work in Process
Limiting the work in process will help you reduce the time it takes for work to travel through the system. This will also reduce the problems with task switching and re-prioritizing all the work.
- Focus on Flow
You can optimize your Kanban system to upgrade your the smooth flow of work by using work-in-process limits and reinforce team-driven policies. We can collect metrics to analyze flow and get leading indicators of problems by analyzing the flow of work.
- Continuous Improvement
The Kanban system becomes the cornerstone of a culture of continuous improvement. The team can measure their effectiveness by tracking flow, throughput, and lead times. We can embrace the changes we make and learn from them. If they provide value we can include them, if not we can learn and move on.
Potential use cases
I spoke with Bob Payne, Vice President of Agile Consulting at Lithespeed, as I was researching for this presentation. He mentioned some of the potential situations where a Kanban approach would be beneficial. They include:
- Teams with unstable planning windows
- Operation teams
- Teams with unstable demands
- DevOps teams
- Spotify teams
Bob mentioned that these types of situations work best for Kanban but there are many other scenarios where he sees the system working well simply by understanding how important controlling the flow of work is.