Posted on 10-Aug-2018 19:17:29
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.
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.
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.
The flow of work can be measured in terms of Capacity (number of tasks being delivered), Lead time and Predictability.
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.
Teams review the flow of work and bring in improvements to the process.
Here are the roles in Kanban.
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
Picks up tasks from the Queue
Interacts with PO for clarifications
Completes the task
Moves the task into it’s respective state
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.
With an ability to conduct deep analysis, strong execution skills and an innovative mindset, he has successfully led R&D teams to build engineering solutions to improve reliability of applications. He also has deep expertise in building high volume transaction processing applications for middle & back office functions at Investment Banks using a variety of architectures.
He has been part of leadership teams in driving Site Reliability Engineering transformation and Agile transformation.