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.
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.
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.
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.
Something to add? Continue the conversation on Twitter