One of the reasons I enjoy working at Zirous is we are always considering new ways to provide value to our customers. One way we learn and share new methodologies is through our internal ‘Lunch and Learns’. Recently, co-worker Kyle Fattig and I presented on Kanban, an interesting method for managing work focusing on just-in-time delivery.
What is 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.
History and Influence
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:
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.
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 blog. 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.
For many technical people, the first thing that comes to mind when discussing development process is tools. While software can be valuable, it’s not always necessary with a Kanban approach. A simple marker board is sufficient for many teams, and takes minutes to setup. Software tools are powerful, but often complex and time consuming to configure. It’s usually best to follow the K.I.S.S. principle and not complicate things upfront.
Potential pitfalls - And how to avoid them
- Slow or no process improvement
Starting with an existing process is critical to success, but improvement is the goal. Constant assessment and adjustment is necessary for improvement. To avoid this pitfall, focus on identifying roadblocks and sub-optimizations and then correct them.
Start small, and keep only what works. For additional help, see the section on tools above.
- No built-in release or sprint concept
Use a hybrid approach. Kanban can be adapted to co-exist with just about any other practice, as required.