This is the conclusion of a post on the power of WIP limits within agile teams. Now we get to the juicy part…the results.

Results

I rarely like to use numbers to illustrate results because they can be misleading and miss much of the nuance. However, in this case, I want to leverage some of the team’s numbers simply because it illustrates the impact these modifications had AND the results the team realized.

The team previously would commit to a body of work and deliver only 60-75% of the work (stories) toward their sprint goals. That was typical. They also often missed delivering higher priority stories over lower priority stories.

The sprint where they made these two adjustments, the team delivered to 140% of their commitment; pulling more work in than they had thought feasible. Not only that, they delivered in priority order, so if something had happened they would have delivered higher value first.

But there is even a hidden fact I have left out. It just so happened that this team received a new team member a few days before the sprint started. While being an experienced engineer, this person was totally new to the company, product, and team. As part of the team’s renewed focus on collaboration and swarming, they embraced the new developer and he actually had a net-net positive impact on the sprint’s results.

What Changes Do WIP Limits Influence?

Even before Kanban became more popular I was leveraging WIP limits in my coaching as an aid to driving collaboration and swarming around work. The reality is that when a team swarms around their work and removes delays, hand-offs, and inspection points, they simply get more done. But it is often hard for some teams to realize it.

Getting back to our team, what did they experience over their initial sprint?

1. The daily Scrum became more of a collaborative planning session than a status meeting for the team. The discussions surrounded who would work with whom to maximize their focus on the limited WIP and effectively working together.
2. Since the team only had a few things to work on, keeping them “flowing” towards completion was important. So any delays, impediments, or issues became immediately visible and required team-wide adjustments. This helped in getting work “done” as well as improving their throughput.
3. It was funny. Even though they all sat in close proximity, the team had not truly collaborated previously. But removing all of the walls and getting everyone co-located changed the collaborative dynamic. There was much more dynamic pairing across team members and natural cross-team communication.
4. Another aspect of the room was work visualization. There was a shared whiteboard where the team had their sprint plans. Story and task card movement was incredibly visual and the team spent time at the board every day adjusting their visualizations for work pairings and workflow.
5. Quality was better as the developers and testers paired more frequently and naturally. They found bugs quickly and focused on repairing them rather than talking about or documenting them for later resolution.
6. As I mentioned earlier, the team really did not plan the sprint end-to-end in the traditional sense. Instead, they planned each new story as they picked it up, changing their collaboration as required. It was dynamic, fast, and optimized the throughput of the team towards getting things DONE!

The key conversations in the daily stand-up moved from “What has each individual done or what do they plan to do?” to “How does the team maximize their daily focus to get the highest priority work done as quickly and as well as possible?”

Wrapping Up

As for my example team, some might wonder what happened after that initial sprint. Did they move back to their old offices? Did they change back to their old habits? And did they continue to improve?

I will leave that answer for another time and another article.

The real point is – are you struggling to collaborate as a team? Are your developers holding on to work too long? Do you have too many stories in play at once and miss delivering important work? Is Scrummer-fall alive and well in your organization? Or are you just not as productive as you think you could be?

If so, please consider sitting together and limiting your WIP. You just might see a different result.

Stay agile my friends,

Bob.