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.

Wrapping Up

In the next and closing part of this post, I’ll explore the results that happened for this team and the impact that WIP limits can generally make.

Until then…stay agile my friends,

Bob.