Efficiency through focus is achieved by limiting the WIP. This is one of the principles of the Kanban -“limit the WIP”.
Here’ s bit of details on why and how around the ‘WIP limit’ principle.
What is WIP limit?
WIP limits determine the minimum and maximum amount of work that lives in each status of a Kanban workflow.
Limiting WIP is to match team’s development capacity. Generally it is set per column – workflow stage. However, it is also acceptable to establish limits per person or team. Setting a WIP limit for a given column does not mean that you absolutely cannot put another task into that column. Rather, it means that when limit is exceeded, the whole team should take on the responsibility of understanding why such a situation occurred that they can improve it and prevent it from happening again.
Why WIP limits ? (benefits of setting a WIP limit)
- WIP limits highlight bottlenecks and backups in the team’s process due to lack of focus, people, or skill sets. n a team’s delivery pipeline before a situation becomes dire. These benefits guarantee increments of value to the customer sooner, making WIP limits a valuable tool in agile development.
- WIP limits make blockers and bottlenecks visible. Teams can swarm around blocking issues to get them understood, implemented, and resolved when there is a clear indicator of what existing work is causing a bottleneck. Once blockages are removed, work across the team begins to flow again
- For example, a typical software team might have four simple workflowstates: to do, in progress, code review, and done. They could choose to set a WIP limit of 2 for the code review state. That might seem like a low limit, but there’s good reason for it: code that hasn’t been reviewed not only hasn’t shipped yet, but may need significant re-work before it is ready to ship. So it’s important to take action on code reviews right away, and setting a WIP limit helps the team hold themselves accountable to that. It forces the team to knock out those reviews before pulling in new work.
- Work in progress limits do not mean developers need to rush through work to avoid work overload in a particular status. They are meant to support solid agile engineering practices that protect the quality of the product and health of the code base.
- Items that are in fag end state should be acted on urgently, for a few reasons:
- The code doesn’t rot as team members check in new code
- The developer doesn’t lose the context he or she gained in writing the original code
- The feature can be merged into the main branch for release
- WIP limits guarantee un-reviewed/ un-tested code doesn’t pile up
- Limiting WIP also means Focus on one task, avoid multitasking. Multitasking kills efficiency. The more work items in flight at any given time, the more context switching, which hinders their path to completion. Multitasking requires switching and switching tasks is not free. Here’s simple explanation by Just buchweitz in ‘Handbook of congnitive science’ ( What Brain Imaging Reveals About the Nature of Multitasking )on how multitasking works in human brain. He says effective multitasking requires that two complex cognitive processes co-occur gracefully while sharing some common, resource-limited infrastructure. This reduces the performance eventually. Eg: Reduced behaviour of the human brain while driving and listening – in parallel. This is applicable in other aspsects of brain forcing to multitask.
- After the team uses their WIP limits for few weeks, make adjustments as needed. Resist the temptation to raise a WIP limit just because the team keeps hitting it. Seize that opportunity to increase capacity–ideally, by educating the team and giving each member new skill sets or making some aspect of the development process more efficient. Look at weekly plan of two teams. Obviously second on is more focused and achievable
- This is another example on how to manage the daily tasks by keeping limiting WIP items giving good breaks during time of task switchings. Too many tasks may also means inability to prioritise leading to stress leading to the degraded performance.
How to set WIP limits
- There is no secret formula for setting accurate Work in Progress limits. Following two critical questions help in setting the limit:
- How many people do we have in our team?
- How many things do we want them to work on at a time
- Overall WIP can be achieved by
- Size individual tasks consistently
- Map WIP limits to the team’s skill and the teams bandwidth
- Give enough time/break for task switching
Typical Areas where Kanban is mostly used are hot fixes, environment patch, application upgrades, on-call incident, problem RCA, e.t.c.
Links to references used for above post
Other good read