Swarming: a team-based way to power through work

Swarming is a team collaboration technique that’s been around for decades. Its roots go back to the early days of aviation, when a group of biplanes were flying together in a tight formation.

The pilots might have been able to fly their planes on their own. But staying in an organized formation required coordination among them — particularly close communication about who was where and when.

Similarly, swarming is a team collaboration technique that can help agile teams finish user stories. This works by keeping the entire group in sync and communicating how they are progressing toward completing a task.

As you’ve probably figured out, this comes in pretty handy when it comes to projects. So let’s take a closer look at this handy technique!

What is swarming?

Agile teams often try to follow the “we’re all responsible” philosophy of collective commitment.  This means that if something goes wrong, “we all go down together.”

Swarming takes this idea one step further. Instead of just holding everybody accountable for getting work done, swarming encourages team members to coordinate their efforts. They help each other out as they collectively power through a user story or other backlog item.

Essentially, a team is beginning a ‘swam’ when more than one team member starts working on a user story simultaneously.

At the low end of the spectrum, the swarm could consist of two. It could be much larger at the other end, e.g., when the entire scrum team works to build a feature or fix an issue.

Typically, people associate swarming with agile practices such as Scrum. But, team can also practice it to some extent in other iterative/incremental frameworks.

Swarming works best for user stories that are high priority and require significant effort to complete. The idea behind swarming is that the project becomes ‘doubly iterative.’ This is because you’re getting work done twice as fast by working together instead of waiting your turn. Teams can use it during a sprint for any reason: internal dependencies, external dependencies, finishing stories early, etc. But, most often, it is triggered by missing or incomplete story estimates.

The takeaway: Swarming is all about shared responsibility and shared accountability. Everybody helps out, each person takes on some of the work, and nobody is solely responsible for completing the user story.

What are the advantages of swarming?

There are many benefits to swarming. Here are some of the top reasons:

• Swarming increases productivity because more than one person engages in development at any point during development. If someone gets stuck, there’s always another team member to help them get back into ‘swim’ with the rest.
• Teams gain a broader understanding of the work because everyone is working on user stories together. This practice avoids silos and situations where knowledge is only accessible to one or two people.
• Swarming also allows for real-time code review, which speeds things up.
• Swarming increases morale because team members get to witness each other’s successes more often. Because of this, they know they’re helping one another to succeed.

The whole point of swarming is to keep everyone working on the same thing at the same time. For example, one team member is finishing coding an aspect of their story while another stakeholder is still finalizing acceptance criteria for the same story. Yet another team member is polishing up his UI mockups. The product owner will be able to notice when all these pieces are complete and ready for review. The team members can then present their accomplishments in one session later.

What are the disadvantages?

It may take a little getting used to for new scrum team members, especially those accustomed to working on their own. Everyone will need to learn how to work together and focus on the same task. This is why it’s extra-important for everyone on the team to be on the same page.

Team managers should also realize that swarming is not just about giving orders or even following them to a tee. The point of this approach is to give each member a chance to voice their opinion about what they think needs doing first and what can wait a bit longer. This way there’s an element of democracy in the mix.

One final note to keep in mind: While swarming is a great way to boost productivity, the process only works if everyone on the team commits to getting user stories done. If even one team member isn’t all in your product success, they’re sure to make trouble — figuratively speaking — for everyone else.

How does swarming work?

When swarming, there are typically two or three team members around a computer working on the same user story simultaneously. While one person is typing code into their IDE, another might be compiling it to run on their local machine so they can test it out. Yet another might have opened up their acceptance tests in an automated testing tool. This approach speeds up software delivery by as much as five times. So, having three people on one piece of work makes sense.

Swarming patterns: some examples

The following is a list of some common swarming patterns that work well.

Tester-developer

Testers and developers both verify software quality together as the team builds it. This is instead of at the end of a lengthy development process. This approach to testing reduces bug counts by as much as 50%.

Developer-developer

Two developers share one computer where each person takes turns stepping through the new source code line by line. They are also verbally explaining what they’re doing to their pair partner. In this way, both coders have an opportunity to learn from one another and solve issues faster.

Developer-designer-tester

Similar to the tester-developer pairing, this set includes a designer who sketches out storyboards or wireframes of new screens. This approach helps designers understand more about development and what’s realistic before mocking up UI designs for testing.

Developer-designer-data scientist

This is common in companies that are building data products. The developer will code, but the designer works closely with them. They help ensure that all output renderings are correct and that UI elements have good placement within the layout. Meanwhile, the data scientist looks for new insights based on analysis of outputting metrics.

Developer-tester-product owner

This approach focuses testers more on test automation, whereas developers lean toward unit testing their code before moving it into production. This helps avoid costly regression cycles. Developers can spot problems early when changes to existing source code must be made.

DevOps guru-QA engineer 

A dev ops expert creates scripts and packages to automate tasks such as updating documentation and deploying new builds. The QA engineer creates tests for new features, assists with testing actual builds, and can provide a second set of eyes to review code. This focused approach makes the QA engineer more efficient at finding problems before customers do.

• Want to learn more? Make sure to check out our DevOps Guide.

As seen above, numerous combinations exist for how teams can divvy up work among their members in different scenarios. Some share responsibilities, whereas others have team members who specialize in particular areas. No matter what combination you use, do what works best for you.

In action

Typically, a scrum approach involves assigning tasks to individuals who then work independently. The product owner assigns user stories to the team that picks up tasks and works on them until they are done or tossed out.

The scrum master keeps things moving by removing obstacles and making sure the team solves impediments as soon as possible to proceed smoothly with sprint goals. At the end of each sprint, everyone gathers together to review the work, showcase features, and talk about what might need some additional polish before release.

Swarming is different because it gives teams opportunities to gang up on user stories instead of assigning individuals to tasks.

Here’s a typical scenario. Say the Scrum team in the figure is in the middle of sprint planning to create a new build. They discover that work on user story 1 (US1) will take longer than they have plans for. The swarming coordination meeting occurs when one scrum team member, let’s say it’s the UX designer, notices this breakdown in estimating and alerts the rest of the team by asking, “How about we start working on US2 instead?” Two other members quickly begin work on US2 while three others continue to finish up with US1. Swarming is in progress.

Examples like these underscore the value of swarming in establishing a sense of communal ownership and collective accountability for getting work done. In other words, scrum teams that swarm take collective responsibility for finishing all the user stories — not just their own.

How to swarm in three easy steps:

1. Make sure the whole team knows the top priority item is in their backlog.
2. Pull in as many people as possible to work on that item. Make sure that all members agree on what they can deliver in the defined time frame.
3. Start working on that item simultaneously. How you do this will depend on your project and your team. Once that task is completed, you all move on to the next priority one.

Top tip: Try swarming your user stories from smallest to largest. This tends to keep team velocity from getting too erratic from one day to another since newly started stories have generally been estimated at lower points than larger stories.

What should I do if my team is having trouble swarming?

Problem: My team already has a backlog full of user stories, and we’re supposed to start swarming our work next Sprint. But what do we do until then?

Solution: Don’t worry too much about it — instead, focus on running an effective Daily Scrum with your existing backlog to make sure you’ve got everything prioritized correctly. Also, think about which tasks will likely go the fastest (and thus be easiest for you to swarm), and consider starting there (such as getting design mockups done for top priority stories) — after all, an easy task completed first means more time for harder tasks later.

Final thoughts

Swarming comes with lots of advantages. It makes all the individual team members feel more accomplished, it provides better visibility for non-technical team members to see user story progress, and it allows for distributed tasks across the whole group at once.

Most importantly, swarming improves overall productivity by taking areas of strength enjoyed by individuals and turning them into areas of strength enjoyed by the entire group at once. This means that, compared to even a team with one superstar coder or two great designers, an average software development team using swarming will produce higher quality work faster.

To work even more efficiently as a team, give project management software a try. With Backlog, our own project management tool for developers, you can track your team’s progress throughout the sprint, track expected work versus completed work, and keep up-to-date with notifications. When projects are moving quickly, a good project management tool can be the difference between flying in formation and tumbling to earth with a bump.