I once was leading / coaching a team that struggled mightily to work together as a team. I was the Director of R&D at an eCommerce SaaS product company. We had been leveraging Scrum for a number of years with reasonably good success and had approximately 10 Scrum teams focusing on the various aspects of our online product.

But there were a couple of teams that were really struggling, which often seems to be the nature of things. Out of ten teams, we had about three that were high performing, three that were moderately performing, and three that struggled along. Don’t get me wrong, the team members were solid people and good employees. It was just that this whole “agile collaboration thing” was hard for some of them to grasp and embrace.

One particular team truly struggled. They had failed quite a few sprints in a row and I was intervening as a coach. Let me digress for just a moment on the whole failure thing, before you all start throwing tomatoes:

We measured success or failure not by hours, or points, or stories completed. We measured it by the team meeting their Sprint Goal that was established when they planned and committed to their sprint. There is a lot of angst in the Scrum community over using Pass vs. Fail or even using the word “commitment”. For the purposes of this article, I do not necessarily want to try and debate this practice. You can see references to some related posts at the end of the article. Suffice it to say that, at the time of this example, we measured and cared about sprints passing versus failing.

As they failed, they would talk about adjustments in their retrospectives. But the modifications were often quite trivial or safe. I felt they were not addressing the issues that were truly impacting their performance. I remember in one retrospective, they decided that the estimation units they were using were flawed. So they moved from a modified Fibonacci to Gummy Bears. Needlessly to say, the next sprint was not positively influenced by the adjustment. This went on for quite some time.

I am normally a patient coach and I try to influence teams to observe and improve on their own. But this team truly was not “getting it”. So, after about their fourth or fifth failure in a row, I gathered the team’s Scrum Master and Product Owner in my office for a “chat”. I insisted that the failure pattern that they were experiencing needed to stop. I told them that I felt their root problem was that the team was not collaborating on their work. That they were operating as a Scrummer-fall based team and that individual work was the norm rather than teaming, swarming, collaboration, and teamwork.  They agreed and they voiced their own frustration with the lack of improvement. But they did not know what to do and they were reluctant to “tell” the team what to do.

I quickly suggested two things. But the change had to be theirs. If they did not like my adjustment recommendations, then they should pick meaningful ones of their own, but they should stop dancing around the root challenges and truly attack meaningful adjustment ideas in their retrospective. Clearly, something had to change – for the team’s sake.

My Two Adjustments

I recommended two simple adjustments for their team:

  • First, I asked them to co-locate or sit together as a team, find a place where they could all sit together for one sprint. I spoke about the quintessential Agile team environment, where everyone sat at a long table – along both sides. The entire team residing in a single room, where they could see and hear each other and where they would be naturally pairing. A room where they could pull away from the laptops and gather around a whiteboard and where they could have their daily Scrum right there in the same space. Could they just try it…for only a 2 week sprint?
  • Next, I asked them to limit their work-in-progress or WIP. I did not necessarily have a “magic number”, but I thought that a WIP limit of three might be useful for them. And, as a note, this would be a hard limit. The team could only work on three user stories in the Sprint Backlog at one time. These would be the highest priority stories. In order for them to pick-up the next story, they would have to complete one of the current three and demonstrate that it met their definition of “done”.

That was it. Two small changes fully targeted at their collaboration challenges. 

Well, fast forward past their next retrospective and the team “accepted” my recommendations and tried them out. They found a large conference room that they took over as a team room and everyone moved into the room: front-developers, testers, back-end developers, Scrum Master and the Product Owner. The whole team co-located for a sprint.

Their sprint planning went on largely as before, but the workflow strategies were strongly influenced by the WIP limits. In fact, they only planned on attacking the first three stories, leaving the remainder of the work to emerge during the sprint. So, they did a bit of guessing on how much would fit into the sprint.

But, importantly, they left sprint planning with a commitment to a body of work and a commitment to swarm on their work as a team. They were willing to give the adjustments an honest try.

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.

Thanks for listening,

Bob.