What are the benefits and challenges of implementing WIP limit in agile projects?

Kanban is a flexible, pull-based system which allows the team to work on items that align with their capacity. Limiting a maximum number of items that can be pulled or remain in a Kanban column at a time provides a guardrail to focus on the work and increases throughput. The underlying reason is setting a WIP limit helps to deliver faster through smaller batches as cross-functional teams can work efficiently on the items at capacity and tasks do not sit idle by creating bottlenecks. It's like only allowing a number of vehicles which the highway can support without blocking the flow.

A WIP limit is like a diet. It can be really powerful and pretty painful. And it’s hard and even cruel to inflict it on others.

WIP limits create and encourage opportunities to change how work is done. For example people that notice bottlenecks or constraints downstream might decide to take on additional work to make downstream step less costly. Eg developers might decide to spend time automating, providing test ability hooks. Marketers might spend time improving quality of leads and the information available to sales.

Little’s law states that the average cycle time for work items increases as work in process increases. Like in a traffic jam the more cars on a highway the slower the traffic gets. Traffic control measures speeds up the traffic by limiting ingress of traffic. Similarly limiting WIP in the system on average reduces cycle time.

Remember, if it’s not painful it’s not making an impact. It’s tempting to raise the WiP limit or ignore it and say “this doesn’t work for us”. Instead, lean into the wip limits. Explore creative ways to work within the WIP limit. Make it a game !

Do not make WIP control a process thing , something we must do. Make it pragmatic and purposeful. Ask “ what is our current average cycle time ? “ then ask yourself “ does this meet expectations of our customers and meet our business goals? “. If the answer is no then we need to optimise ! One lever is controlling WIP in system on average. Experiment by reducing WIP and empirically test is cycle time is within expected range.

Implementing WIP limits in agile projects enhances focus and reduces burnout by setting realistic expectations based on team capabilities and project demands. Key to success is engaging the team in setting these limits, fostering buy-in by highlighting how it streamlines workflow and elevates productivity. Monitoring metrics such as cycle times and work item age aids in fine-tuning processes. Regular retrospectives ensure continuous improvement, allowing the team to adapt strategies based on real-world outcomes. My experience confirms that a collaborative approach in adjusting WIP limits, grounded in transparency and flexibility, significantly boosts efficiency and team morale, turning potential challenges into opportunities for growth.

One heuristic to try is - single piece continuous flow. Set WIP to 1. Increase it only if it is an absolute necessity. Setting WIP to 1 had many additional benefits , besides controlling of cycle time and increasing average throughout. For instance , It makes us more adaptive and predictable - when there is only one item in process , it is easier to get that item done and move to urgent items without having to stop multiple items in progress. The scrum metaphor has one rugby ball within a scrum , the whole team moves the single ball forward as a team , there aren’t multiple rugby balls flying around l.

See also the kanban guide for scrum teams https://www.scrum.org/resources/kanban-guide-scrum-teams And also https://www.scrum.org/resources/blog/limiting-work-progress-wip-scrum-kanban-what-when-who-how