There are several terms for pairing among more than two people. I’ve heard it referred to as “trio-ing,” “mobbing,” or just “group code review.” Personally, I like to use the term “swarming” for any pairing session involving more than two developers.
I haven’t seen swarming as overtly praised as the more commonly seen two-person pairing setup, and for good reason. In a pairing session, there are two distinct roles, each with its own responsibilities. When more people join in, those roles begin to blur. When you have one driver and three navigators, which navigator is paying attention to what? How can the driver make progress if all three navigators are pointing in different directions?
Despite the increased complications of working with more than just a pair, there is definite power in a swarm, when used effectively.
In this three-part series, I’m exploring different ways to work on software development with and without your teammates. Hopefully, this will help you find a better balance when building your code.
Context, Context, Context
First and foremost, swarming is one of the best ways to rapidly share complex context among team members. If there’s a section of code you’re unfamiliar with, swarm with a pair that knows that space. You’ll not only learn how to navigate the space, but you’ll work on that code with the support of more knowledgeable teammates.
Trust the Brain Trust
Another benefit of a swarm is the brainpower that’s brought by each individual teammate joining in. It’s all about the dynamic combination of context and perspective. Bringing more people together means more ideas for solving problems.
Even if there’s not one specific problem that needs to be solved, getting the team together to swarm on a concept is valuable, too. Everyone leaves the swarm knowing what needs to be done next — and why it’s going to be done that way. That kind of shared thinking builds trust and cohesion throughout the team.
Beware the Constant Swarm
It’s a known fact that development time doesn’t scale based solely on the number of programmers working. If a task would take one programmer eight hours to complete, it won’t be done by eight programmers in one hour. That same truth holds for swarming. Throwing more people at a story won’t make development faster. In fact, swarming can slow down development time due to the increase in conversation, debate, and overall communication that’s necessary as more people join in.
Swarming all the time is not an efficient or even practical action. If your team feels like it needs to be constantly swarming, that could indicate that the team’s work is too large or too complicated to be managed by just pairing time. I’d recommend bringing it up at your next retro and trying to find more manageable ways to divide up the work.
Swarming is a valuable option for dispersing lots of context and information quickly throughout a team. But it uses a lot of people’s time and should only be leveraged when appropriate. Like all options discussed in this series, the effectiveness of this approach really depends on the dedication of the developers using the tactic.
Working solo, pairing, and swarming are all just tools. They need to be applied in ways that not only optimize the efficiency of the team but take into account of stressors that they place on the team. No one approach is universally better than another, and all of them should be balanced between developers that trust each other and can communicate well.