I've heard swarming mentioned in the context of Agile or Extreme Programming. It seems to be a complement to pairing.
What exactly is it? When should it be applied? How do you do it well?
Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.Sign up to join this community
The idea is that everyone on your team works on the same story at the same time. Instead of everyone focusing on different tasks, everyone focuses on one task at a time until it's completed. Then they move on to the next thing, where they all work together on it.
This helps teams that struggle completing stories before the end of sprint. Often teams finish 80% of all the stories, but none are complete. This is less useful than completely finishing 80% of the stories, since unfinished stories have (effectively) no value to an end user. It's easier to get stories completed when everyone on the team is focusing on one story at a time. This is the motivation behind swarming.
There are some difficulties here. For instance, QA can't always test things before they are built (or even designed). In this case, you should establish a design together early on, and then QA can write (initially failing) tests against the design and not the actual implementation.
Swarming just refers to the fact that multiple people work together to complete a task or story. In my experience this isn't something you do often.
Typically, each member of my team works on a different task and/or different story. If someone is falling behind, or if there's a desire to finish a task or story early, other people will stop working on other tasks and "swarm" to complete the task, which means they all work together on a single task or story until it is completed.
We recently had a small number of stories that was some fairly boring, uninteresting work. I gave the team a small incentive (pizza) and deadline (end of the day) to finish the work, so they swarmed on the story and knocked out at least a couple days of work in one afternoon. They got the work done and out of the way early, then each team member went back to whatever they were working on. They got a free lunch, I got work done early that could have dragged on due to it's dull nature, and the team got ahead of their sprint. Win-win-win.
"Swarming" is nothing more than a fancy term for "hey, let us help you with that".
Swarming is actually a central concept to agility. It is not something that is done "when there are problems". Swarming, in its simplest form, means that teams work collaboratively on items (stories) and work them to completion. The core concept is to "quit starting, and start finishing". In other words, instead of every developer working independently on a story, the team focuses on a more limited set of stories/tasks together and get each item done sooner. Think of it as the difference between a single-threaded system, and multi-threaded. If a User Story has 10 tasks that must be done, and each one is 8 hours, assuming that there were no complications, one developer could work each task sequentially and complete the story in 80 hours, or about two weeks (given 10 day sprint of 8 dev hours per day). What if two developers split the tasks and worked them concurrently? The same 80 hours of work can be completed this way in one week. Add a third, and you can see now it might be done in 3 to 4 days.
Swarming can be done in several ways:
Teams that give a story to every developer tend to have too much "work in progress" or WIP, and often many stories get started but not done. This is an ANTI-PATTERN, and is NOT best practices.
Teams that swarm tend to have less WIP and complete more stories--and by done, I mean Developed, Tested, Approved, ready to deploy. Thus, this is a practice is that core to agility.
The following article on InfoQ describes one approach to swarming:
Read the article for the detailed explanation.