An Overview of Kanban

Many of us have heard of Scrum and some of the people reading this might be developing products using Scrum. But Scrum is mainly applicable for “true software development” and R&D teams. By true software development, I mean new products being developed and major changes for existing products.

But we do have several products which are in BAU (Business as usual) phase which primarily have minor enhancements and bug fixes. Most of the changes in these products take 1 to 2 days of effort and there is also a need for L3 support. The Scrum events (planning, product backlog refinement, sprint review, etc) will be too much of overhead for the minor changes. And L3 support is completely out of scope for Scrum. I read in another blog which says, “you do not need a hammer to fix a screw”. If these teams want to be Agile, Kanban might be the best bet for them.

Now, what is Kanban?

The Kanban system was developed by Taiichi Ohno, at Toyota Production System. It is a pull system and the emphasis is on Just-in Time production. The words pull and Just-in Time are very important to understand this process. In a push system, there is forecasting of what to deliver and how much we can deliver. In a pull system, its the demand which drives what to produce and when to produce. It reduces inventory and brings in visibility to the seller and buyer.

Ok, now lets see how we can apply Kanban for software.

Kanban teams follow few core practices.

• Visualize workflow

Most teams use a Kanban Board. The Kanban board has columns for each of the state in the workflow. Example flow: Backlog (work items pending) -> Ready Queue (analyzed items ready to be picked up by the team) -> Development and Testing -> Done. Work item number (JIRA, SR, etc) or a liner description is written on Post-It notes and the item is placed under the relevant column.

• Limit WIP

Kanban teams use a WIP (work in progress) limit for items in the Dev and Testing phase. This limit is set in such a way that the team members are not overloaded and do not need to do multi-tasking. At the same time, the team members should not be idle due to a low WIP. The teams usually start with a low WIP and then increase it based on observation over few Cadences. Teams also set a ready-queue limit to avoid pre-mature work.

• Measure and Optimize Flow

The flow of work can be measured in terms of Capacity (number of tasks being delivered), Lead time and Predictability.

• Make policies explicit

Teams get an understanding of how things should work. Unlike Scrum where the team members need to be cross-functional, Kanban teams can have specialists and generalists. Its up to the team how each state of an item is handled. A definition of ready and definition of done are also used like Scrum teams.

• Implement feedback loops

Teams review the flow of work and bring in improvements to the process.

Here are the roles in Kanban.

Kanban Queue Master

• Supports the Product Owner (PO) with the Backlog

• Keeps the Queue re-filled with new tasks as earlier tasks move to done

• Enforces WIP Limits

• Ensures work is picked up as per the given priority

Kanban Team Member

• Picks up tasks from the Queue

• Interacts with PO for clarifications

• Completes the task

• Moves the task into it’s respective state

About the author

Vishnu Vardhan Chikoti is a co-author for the book "Hands-on Site Reliability Engineering". He is a technology leader with diverse experience in the areas of Application and Database design and development, Micro-services & Micro-frontends, DevOps, Site Reliability Engineering and Machine Learning.