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.
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, it’s the demand which drives what to produce and when to produce. It reduces inventory and brings in visibility to the seller and buyer.
Kanban can be applied for software development and support.
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 1liner 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”. It’s 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
- Moves the task into it’s respective state
About the Author
The author of the blog is a cross-functional leader and part of the Core team at Tectoro Consulting, India. He currently works on multi-market multi-asset enhancements to Gloss for our client in Hyderabad. His prior expertise is in analysis, design and development for Derivatives Regulations – Dodd Frank, EMIR, MiFID, JFSA, etc across product/entity/counterparty scope, entity registration, mandatory clearing and transaction reporting.