The Magic of WIP Limit 1 in Scrum

A couple of months back, while reading up on productivity of Scrum teams, I stumbled upon a post by Dean Lennard about patterns of hyper-productive teams (https://www.dhirubhai.net/pulse/agile-7-patterns-hyper-productive-teams-dean-lennard/). By that time, I was already aware of the paper "A Theory of Scrum Team Effectiveness" (https://arxiv.org/pdf/2105.12439.pdf), a study trying to find out the performance factors of 1200 scrum teams, and its findings: Frequent releases, management support and team autonomy have a huge influence on performance of a scrum team. A little bit stuck in my efforts of improving management support and eager to boost productivity and outcomes of the team I was currently supporting as Scrum Master, I read up on the patterns and was intrigued by the concept of swarming.

Now, I remember hearing Joe Justice talk about how agile is implemented at SpaceX, and he specifically described this idea of swarming around the most important piece of work or impediment and working at it tirelessly until it is resolved, so I thought: "Maybe this could work for our sprints as well?". After all, inventory is one of the seven wastes identified by the Lean Production method, and work in progress is the inventory of software development. The Sprint backlog, at heart, is nothing more than KANBAN, and in KANBAN WIP limits are set up in order to minimize exactly this form of waste. Limiting work in progress could also foster collaboration in a team, which consisted of individuals with expert knowledge in specific fields. A perfect fit, I thought.

This is when I got excited. We had just finished a sprint and the retrospective came up; I couldn't wait to propose my idea to the team. We would only work on one story at a time within the sprint. A drastic break of the norm the team had developed. At the start of the sprint the members would usually pick up stories on their own and work to get them finished mostly on their own as well. That's what they were used to, and to my surprise, that is what they wanted to stick with. They were clearly less excited than I was about this idea of limiting work in progress to one. I urged them to at least consider it an experiment. We'd give it a go for a sprint or two and then measure the influence on our velocity. They reluctantly agreed.

It was a chaotic time. We were fresh out of a Product Owner and no replacement was nominated yet, many different stakeholders had many different expectations from our products and previously communicated deadlines were starting to creep up on us. Focus was at an all-time low and it showed in our velocity. I don't blame the team for it at all, but when the pressure was high they fell back into picking up the items individually. The experiment had died before it started.

This was more than half a year back, and things have stabilized a lot since then. The product backlog was in great shape, we'd always stay a couple of sprints ahead with prepared backlog items, velocity was back on track. In a recent retrospective we talked about the last sprint as we usually did, and team members identified that they got stuck on a couple of work items which took them more time than usual to complete. As it turns out, other team members could have helped with the particular issues that had individuals stuck in their tracks. Clearly, we'd need to work on collaboration. That's when I remembered my idea.?

I proposed WIP limit 1 again. A similar discussion ensued. Team members felt they'd be less productive when not working on code on their own, rather than "watching" another member do it. Clearly, we could do four times as much work if all four members of the development team worked in parallel. If we were working on simple tasks like hammering nails into a board that would be true. There are few environments more complex and filled with unknowns than software development, so I argued that the wealth of experience of the team could be applied to all items if we tackled them one at a time. Let's do a new experiment, I said.

The retrospective was on a Monday afternoon. Sprint planning followed on Tuesday and ran until noon. We planned 10 story points to be completed in the next sprint, as our velocity dictated. Tuesday afternoon is when development began. On Wednesday morning in our Daily Scrum, 7 of these were already completed. That is 70% of the work we had planned for our two week sprint, completed in a single afternoon. I was delighted.

By Thursday, our sprint goal was completed and 10 story points worth of increment were delivered. We managed to add more and more stories to our sprint and completed more in two weeks than in any previous sprint. When reflecting, the team argued that they had overestimated the amount of work needing to be done for the stories, which is part of why they went so fast. I think there may be a bit of truth to it. They also agreed, however, that working together as a team had helped immensely. They even came up with and implemented an improvement to the product that would help the customer out and was not part of any story or requirement, improving the product quality as well. At the end of the day, we had delivered a high-quality product increment to our customer, and that is the best indicator for the success of our experiment. That is the power of collaboration. From then on, we would stick to WIP limit 1.

If your team could profit from more collaboration, if you, too, keep identifying a lack of focus as a problem in your retrospectives, if at the end of the sprint you have multiple stories started, but not done, then I urge you to give the WIP limit 1 a go. I am still amazed at the outcome. 70% of the work in 10% of the time. That is Jeff Sutherland's "doing twice the work in half the time" on steroids.

Do you have similar experiences with swarming? Or did you actually work with teams and on products where the opposite was true? I would love to hear your opinions and anecdotes about the topic.