Alexander Bird Software • Blog

Learning to build useful, valuable software as part of a team.

Crossing the WIP per person threshold

How we reduced WIP/person from >1.5 to <1

Before we started pairing and mobbing, each person had their own task in progress. Because of review queuing, at any given time about half of the team was wrapping up one task while working on a new task. Average WIP/person was >1.5.

Now, with 2+ people per task, we're at <0.5 WIP/person.

On an 8 person team, with 1.5 WIP/person, that's 12 different tasks in flight. You may be called on to help any team mate at any time, so throughout the week you could be switching context between up to 12 tasks. Or you can avoid that by ignoring your coworker's work. Neither of those are good options.

On an 8 person team with <0.5 WIP/person, that's about 3 different tasks in flight that we may have to switch context between. Even if I'm paying attention to everything that all my team mates are doing, I'm within my context switching limits. Less stress, more collaboration.


Our working style is radically changed by dropping below the 1 WIP/person threshold. That may sound dramatic, but mostly it's just queueing theory and lean engineering.

More collaboration

Less stress

I'm not scattered and struggling to keep up with the team's activity. When there are multiple things in flight that I have opinions about, it's not hard for me to have my voice heard. I'm not worried that I'll miss something exciting or important that my team mates are doing, because we're working together.

More flexible team schedule and work breakdown

How we got here

Two years ago when I joined this team, our WIP/person was at least 1.5. We "uncovered better ways of developing software by doing it and helping others do it". We made suggestions to each other, tried things out, retrospected, shared our experiences with neighboring teams. And repeated. It took about three months from when I started to our first pairing session, another three months before pairing became a standard practice on our team, and another six months before mobbing became more normal. Along the way we had to grow a lot in our mobbing skills (mobbing pattern language, mobbing RPG, etc.) to overcome collaboration obstacles. Then, we started applying mobbing to non-feature work: operational investigations, infrastructure changes, document writing. Along the way we had to figure out how to explain this to new team members as our team lost and gained members.

Aside: on sharing our experiences with neighboring teams

The sharing with neighbors was consistently instructive for us, but not consistently effective. To teach, we had to summarize, so we had to understand what we were doing. We were exposed to new questions, doubts, and corner cases. That was helpful for us. On the recieving end, it was interesting to see what parts other teams refused to believe or failed to apply. Some of what we're doing doesn't even apply to neighboring teams! It's critical to tune practices to your very very specific context if you want it to take hold. See also: the "Just Sharing" principle.

What does this look like in practice?

  1. When we start a new task, instead of asking "how few people do we need", we ask "how many people can we get working on this task"
  2. Whenever we're collaborating, it's up to each individual to decide if they should stay or if they should go do something else.
    • As an individual, you can stay if you're either contributing or learning
    • If you feel like working solo, you can do so. It's acknowledged that this is usually worse for team productivity, but it's important for keeping our minds fresh and motivated
  3. When you finish a task, you ask the team if anyone has something in progress that you can help finish.
  4. When you're stuck waiting on something, you should catch up on clerical work before starting new task (e.g. install software updates, respond to emails, complete required training, submit your expenses, etc.)

Something to add? Continue the conversation on Twitter

Written 2021-11