This morning there was a large amount of bird chirping outside. When I looked out the window there were about a dozen sparrows, and mockingbirds chasing a hawk. They were swarming and chirping all over the place and working together they chased that hawk out of the area. They teamed up to defeat an unexpected problem that came out of nowhere which was bigger than they were.
When you stop and think about it, it’s no different when a critical production issue or overly difficult problem appears in front of a an engineering team. The problem is identified, the team drops everything they are currently working on, and they “swarm” the problem until it is eradicated. During the swarm some people may drop off the problem when their skills are no longer required and other may get pulled in as the team determines the next steps they need to complete the problem. Ultimately, think of swarming as Pair Programming on steroids.
As a manager or team lead you need to recognize when swarming could be a help, as it does take resources away from day to day work. Honestly, I think it’s usually pretty obvious when swarming is needed, and it doesn’t hurt that the team will usually say so. Swarms don’t often affect the outcome of the Sprint as the swarm has a force multiplying effect which gets things done faster, however it’s always wise to communicate to the stakeholders that a swarm is happening and when the possible risks may be to the Sprint. Regardless, if the team comes to you asking to swarm on a problem, let them, they know what they’re doing.
Swarming is a highly effective way for a team to accomplish a large task quickly. Even a bird brain can see that.