Limiting Work In Process (WIP) is very important for Agile teams and is highly recommended for Kanban teams as they are focused on identifying and removing blocks and thereby improving flow. Here are some benefits of limiting WIP observed in teams I have coached.
The first and most talked about among the benefits of limiting WIP is improvement in the flow of work. Accumulating work items in the value stream chokes the flow as can be observed easily. It leads to several difficulties – priorities getting changed due to most priority items not getting completed, overheads of multitasking, reduced throughput and so on. Limiting WIP ensures better flow as few items get more attention and can be taken to completion faster. The cycle time would improve as the wait time is reduced.
This is a side effect of limiting WIP. When a team member cannot pick a new item due to the limit set, he/she tends to collaborate with others to see how to make space for picking a new work item. This is very useful in distributed teams as one of the big challenges there is improving collaboration across sites.
Developing cross-functional skills
When team members are forced to collaborate with others to move work items faster so as to clear the queue, they would be able to do it only if they develop some additional skills. A developer would have to help a tester and vice versa. In a Kanban team especially, the value stream would have several work states and team members would be able to help each other if all are comfortable with performing all work. Over a period of time, I have observed, team members do develop additional skills in such teams.
Problems get solved faster
As though due to some magic, team members have observed often in retrospectives that some of the problems which used to take longer to address get done faster after limiting work. Of course, it is no secret! This is one of the benefits of pair programming. Though not projected as pair programming, when team members pair up or swarm to decongest queues problems do get solved faster.
Limiting WIP exposes problems automatically. If some work state is getting choked, it may be due to some technical problem, due to dependency, due to unknown components in work and so on. Whatever it is, when members swarm all these get discussed and addressed. It brings tremendous improvement in transparency.
If teams are monitoring WIP limit and improving over time, there is more focus as team rather than individuals. Since team members swarm often, it is most times team work that is responsible for addressing blocks and complicated situations. It reduces one person struggling all the time to complete a single work item thus delaying delivery etc.
I have just listed a few off-shoots of limiting WIP and I am sure you would have come across many more and I would definitely like to hear from you. As you can see all these are very much applicable to Scrum teams as well though I have not specifically dealt with it here.
So, what are you waiting for, STOP STARTING and START FINISHING!