Scrum and WIP limits ???

A New Pair of Glasses. In this series I challenge some of the misinformed and myopic statements I've heard people make about Scrum over the years, with the intent of clearing away much of the nonsense, confusion and even antagonism that surrounds this very simple, elegant and effective method of working.

Blindspot #1: Scrum doesn't have WIP limits

A work-in-progress (WIP) limit is explicitly called out in the Kanban method. Kanban tracks work phases, such as design, development, testing, deployment, etc. and each phase would be assigned its own WIP limit. The purpose of these limits is to prevent work items piling up at the end of any particular phase and creating bottlenecks of work and thus waste. It is a brilliant technique for ensuring focus and maintaining an efficient workflow. Limiting work in progress is one of the two essential Kanban principles (the other being visualisation). It could reasonably be said that if you are not visualising your work flow, and explicitly limiting your work in progress you are not using the Kanban method.

So, if the principle of limiting work in progress is so important, why is it not part of Scrum? The term is certainly absent from the Scrum Guide. The assumption made by many is that Scrum doesn't call out WIP limits because the Scrum inventors and its practitioners don't know about the principle, don't understand it, or cannot implement it. The conclusion thus reached is that Scrum is an inferior way of working to Kanban. End of discussion.

In such a simple analysis and quick dismissal quite a lot is lost. We need to step back and look at the fundamental differences between Kanban and Scrum. Kanban works with the system as it is. Scrum challenges it. Over the past fifty years or so a phased approach to development has been utilised, almost exclusively. Kanban accepts this, and works with it, helping to improve flow and remove waste. Scrum on the other hand refuses to accept this way of working. Where Kanban complies, Scrum confronts. 

Scrum offers an entirely different approach. Scrum doesn't acknowledge phased development, so not only is there no need to limit work in each phase, it would actually be impossible to do so. Instead, Scrum offers a cross-functional team approach. Scrum teams accept work, through agreement, in small batches, each represented by a sprint backlog. A sprint is typically 1-2 weeks in duration. There may be several product requests in a sprint but because the team is cross-functional the team members collaborate with one another—a work technique sometimes known as 'swarming'—on one item at a time. Guided by a clear definition of done on each request all team members continue to work together until the work item is complete. Only when an item of work meets the definition of done is the next item worked on. Team members who believe they have "nothing to do", i.e. because they have a narrow skillset, do not start work on a different item, but instead are encouraged to pair with other team members to learn the skills they actually need to contribute to the work of the team. No one is ever idle (except through choice).

Scrum doesn't call out WIP limits because Scrum, when its values of commitment and focus are adhered to, will naturally have an implicit WIP limit of one. I'll repeat that: Scrum limits work in progress to one item at a time. 1. Any limit above 1 is sub-optimal, indicating a wavering commitment and a loss of focus.

Phase-based WIP limits in Kanban are essentially a work-around, helping take a company from where they are now, to where they could be. It's an evolutionary approach. Knowing that smaller WIP limits are better that larger ones the more effective Kanban practices would converge overtime to smaller and smaller WIP limits, ideally arriving at a limit of one for each phase, and perhaps eventually having workers pool their skills to have single-piece flow from start to finish. Rather like Scrum.