In a previous post I pointed out how limiting WIP helps to improve QA utilization. In this post, I'll discuss another area where limiting WIP can make your team more effective: Roadblock indentification.
We all know that identification and removal of impediments is vital to building a hyper-performing Agile team, but how do teams go about identifying and removing them? If your team is like most, you rely heavily on the activities of the daily standup. The daily standup is the team’s chance to exchange relevant information about what they're working on and to raise issues that could risk successful delivery of their stories. The challenge with relying solely on this mechanism is that it is entirely dependent upon people. Some people just don’t do a very good job of bringing up risks, while others aren’t very good at even realizing when something is a risk.
Sandy is the Scrum Master for a newly formed Scrum team. The team was composed of Sandy, a seasoned Scrum Master, and 8 developers ranging from green bean to seasoned veteran. The project was moving along at a slower than expected pace and a number of iteration commitments were missed. Finally Sandy realized the problem was that, while some impediments were being identified, the majority were going unresolved until the last minute. How did this happen? Shouldn’t the team have identified these items in the standup? Sandy realized that many of these were seemingly innocuous at first, but the longer they went unresolved the risk continued to increase until they impacted delivery. Other times she noticed that some developers, instead of raising the issue and getting it resolved quickly, they would simply pick up another task from the list and begin working it. These behaviors avoided dealing with the delays until the last minute, which ultimately caused delays in the overall project.
Sandy’s Solution: WIP Limits
So how did Sandy resolve the issues? She implemented work in process limits for the developer and QA tasks. By setting limits on the number of tasks that can be in process at each station, developers could not pick up another task (or move it downstream when completed) until their current task was completed. Before the WIP limit if a developer was waiting on a System Administrator to make some Apache changes then they would simply pick up another task, leaving the Apache change behind to reveal itself only in the customer demo at the end of the iteration. In standup, one day the developer is “working on the ATOM feed for customer orders”, the next he “pretty much finished up the ATOM feed and is now working on the bulk purchasing feature”. Pretty much done indeed…
With the application of the WIP limits, however, the developer’s behavior is forced to change. Instead of simply picking up another task, he’s required to only pick up a new story if the number of items currently being worked on is less than the WIP limit. If the WIP limit was 4, and there were 3 other tasks being worked, he has no choice but to “sit around” until one of the other tasks gets completed. How does the standup progress for our WIP limited developer? Day one: “working on the ATOM feed for customer orders” Day two: “finished up the code for the ATOM feed and am waiting for Admins to make some Apache config changes” Day three: “haven’t done anything the last 24 hours because I still haven’t heard back from Admins”
Brandon, you couldn’t possibly expect me to have developers standing around for days while we wait for these impediments to be resolved? Well, yes and no. In practice, this waiting game often motivates the developer to remove the impediment himself. In Sandy’s example the developer may just walk on over to Adam Admin’s desk and ask him to make the requisite changes. In other cases, the developer may help QA with automating a test script to enable them to finish their work sooner with only the most challenging of roadblocks left to the Scrum Master to deal with. For the other cases where the impediment is challenging to remove or get priority on, one thing that really motivates management is when you tell them that until this gets resolved, our developers can’t work”.
WIP limits are a valuable tool for your toolbox. They can be employed to solve a number of development issues. Roadblock identification is merely one of them. Set some limits and enjoy knowing that your team will will identify project risks early and often.