Kanban Framework Overview
In the 1940’s, Toyota innovated its engineering process into a “just in time” model which closely resembled how supermarkets managed inventory stocks to meet consumer demand. On the factor floor, they applied this methodology with a card system called Kanban. Thus, each team on the factory floor would deliver these cards or Kanbans as a signal that they have excess capacity and ready to pull more materials.
Kanban means “Visual Sign” in Japanese
Thus, Kanban is a means of just in time manufacturing via a pull or demand based card signal system.
Kanban can also be used by software development teams. In this capacity, you match the amount of work in progress to the team’s over capacity. This provides the software development team with a means of faster throughput and efficiencies as well as better focus and transparency throughout the software development life cycle. In software development the card signal is intended to limit work in progress to allow developers to focus on one thing and #Deliver.
The Kanban Team is focused on active work in progress. Once a team member completes his work unit, they send a card signal that they are ready to pick-up the next work unit off the top of the backlog. The Product Owner plays an important role in that he/she is able to re-prioritize and groom the backlog without impacting the team’s work.
The Product Owner’s main responsibility is to keep the highest priority work units on the top of the backlog. This means the development team is always delivering maximum business value to the business. This is why there is less need for iterations that you will find in scrum.
Minimize Cycle Time
For Kanban teams, cycle time is the key performance metric. Cycle time is the sum of all time required to move a work unit from the beginning of the workflow to the point where it is shippable software product. Over time, the Kanban team will become very familiar with cycle time and can use it to confidently forecast the delivery of all future work.
Efficiency and Focus
An important concept in Kanban is to avoid multi-tasking as it kills efficiency. The software development team needs to limit work in progress to “one”. This is because adding work items leads to concept called “context switching” which degrades the focus of the developer. By limiting work in progress, you avoid bottlenecks, delays and lags which increases overall efficiency.
For example, the Kanban team might have four different stages in their development workflow:
- To Do
- In Progress
- Code Review
The team could choose to limit the WIP for Code Reviews to 2. This might seem inefficient; however, the code might need significant refactoring before it is ready to ship. Thus, by leaving the WIP to 2, you can improve quality control and increase your ability to deliver shippable code.
Limiting WIP to 2 at the Code Review will hold the team accountable for both quality and delivery. Developers need to really kill-it on the code reviews before sending a card signal that they are ready for new work.
The Kanban board below provides a real life example of Kanban in process for a small development team.