Kanban is a visual process and project management tool first developed in Japan by Toyota. Kanban is a way to visualize your work and limit the amount of work in progress at any one time. KanBan is often seen as a central element of “Lean” manufacturing and is probably the most widely used type of “Pull” signaling system. Kanban stands for Kan- card, Ban- signal and as you probably guessed, is of Japanese origin.
Simply described a “pull” production system controls the flow of work through a factory by only releasing materials into production as the customer demands them i.e. only when they are needed. A “push” system on the other hand would release material into production as customer orders are processed and material becomes available, MRP (Material Requirement Planning / Manufacturing Resource Planning) systems are typically “push” systems. What must be made clear at this point is that Kanban is not a scheduling system but rather a production control system.
Kanban has three core principles:
- Start with what you know – Don’t try to reinvent the wheel right away. Visualize what you have now.
- Pursue incremental, evolutionary change – Once you can see the current state of your work, visualize how to improve it.
- Respect the current process, roles, responsibilities & titles – Don’t make drastic, sweeping changes without getting buy-in from the rest of your team. Remember, Kanban is a collaborative process.
Kanban is based on five core properties:
- Visual workflows – You can’t understand what you can’t see.
- Work-in-progress (WIP) limits – Limit multi-tasking. By limiting your work in progress, you can actually get more done and do it better. Multitasking, and especially task switching, may make it seem like you are getting more done, but in fact you are wasting a lot of time between tasks, forcing your brain to refocus. Kanban is a great way to see the work needing to be done and systematically work on just one or two of the most important things until they are done.
- Enhanced workflows – Continuously improving the way you work makes you more effective and more happy.
- Agreement on process policies – Decide how you want to manage your team’s kanban using feedback from the team.
- Data-driven collaborative improvement – Changes should be made based on the scientific method instead of “gut” feeling.
What is Kanban WIP Limit?
A WIP (work in progress) limit is a strategy for preventing bottlenecks in software development. This concept is based on the assumption that Multi-Tasking results in loss of time in context switching.
Work in progress limits are agreed upon by the development team before a project begins and are enforced by the team’s facilitator. For example, a team may divide the tasks that must be performed for a feature into design, code, test and deploy. When a WIP limit for a certain task has been reached, the team stops and works together to clear the bottleneck. The goal of working in this manner is meant to ensure that the entire team takes ownership of the project and produces high quality code.
Consider the example below
- The project is of 13 user stories to be implemented (A thru M) by a team of 3 people.
| Backlog | TODO | Development | Testing | Deployment | Done | |||
| Ongoing | Done | Ongoing | Done | |||||
| WIP Limit | 2 | 3 | 2 | 1 | ||||
| I | G | E | D | C | B | A | ||
| J | H | F | ||||||
| K | ||||||||
| L | ||||||||
| M | ||||||||
- Suppose there are No WIP limits on the implementation, all 13 may be considered by the team with a average of 4+ user stories per person. The concept is that, if there is too much context switching, the 13 user stories might get delayed because the 3 developers may not be able to focus on any of the user stories.
- Thus now WIP limits are introduced as shown below. A WIP limit of 2 in TODO means that only 2 user stories should be short listed for development. A WIP limit of 3 in development means that there can be only 3 at a time in development cycle.
- Please notice that D is Done (and therefore there may be a slack with this developer) but still development is not started on G/H. If G/H is taken for development, the backlog for testing will increase and nothing will get completed. Instead the developer who completed D can either share some tasks of E,F or help in testing of C before taking up G/H.