What is “Swarming?”

The term is derived from the behavior of insects in nature. The classic example of this behavior is a beehive when it reaches a critical mass. The workers will grow a new queen, and then the hive will split and a swarm will form that will leave the hive and seek out a location for a new hive. Perhaps the most astonishing thing is the fact that there is no one individual controlling the actions of the hive. There is no controller, no authority, no coordinating influence. Sounds kind of Agile.

These characteristics of “swarming” in the insect world are very similar to the kind of behavior that we are trying to foster within Agile teams. We want the entire team to focus on one and only one story at a time.

We want to use simple rules. We want to allow the team to self organize.

However, swarming is a relatively new pattern to emerge in the software world, and there has been a lot of misunderstanding and resistance to the notion of swarming. The idea of having the entire team focused exclusively on the same story is very hard for some people to swallow. The key is to create the right environment to support swarming activity.

If you are going to practice the swarming you need to make sure the following conditions hold true for your team:

  1. There is a definition of done that enables the involvement of the entire team
  2. The scope of the story is non-trivial
  3. A Set based decision making model is used

Often the argument that I hear is that a given story simply doesn’t require the involvement of everyone on the team. However, the more I thought about it, the more I realized that this probably isn’t really true very often. If we look at the definition of done for a team, we fine that there are activities from virtually every team specialization that are required to get a story into “potentially shippable” form. There needs to be a definition of done that enables the involvement of the entire team. Think about it – what activities need to be done for each story? Can we leave out QA? Documentation? Analysis? Design?

Someone once argued that it doesn’t make any sense to build a car 1 tire at a time. I have to agree, but I must also maintain that the challenge must be equal to the resources of the team. We should scale the stories to the appropriate size. The scope of the story must be non-trivial. Instead of building one wheel at at time, perhaps we should change the story to implementing the braking system? Perhaps the team should be implementing the suspension? The drive train? The story has to be scoped large enough that it allows the participation of more than one team member.

We also have to realize that swarming opens up some opportunities that we might not have using more conventional team organizational patterns. A Set based decision making model can be used. If the entire team is focused on the same problem, then we can also have them explore multiple solutions to the problem. This can lead to enhanced learning by the team, and allows them to explore alternatives more fully before making a commitment to an implementation or technology.

So, if you want to explore your busy inner bee, you need to create the right environmental conditions to support the swarming behavior:

  1. There is a definition of done that enables the involvement of the entire team
  2. The scope of the story is non-trivial
  3. A Set based decision making model is used

Given these conditions, the swarming pattern represents an exciting opportunity for us to explore a new way of understanding how we collaborate within our teams.

11 Responses to What is “Swarming?”

  1. Frede says:

    Although you have many activities for a story, like documentation, testing etc. They cannot all be executed simultaneously. You cannot test until the code is checked in. You cannot complete documentation cause there might be changes to the interface etc. If you should be able to do this you’d need very detailed specs. for each story which is quite un-agile.

    • MrHinsh says:

      Why can you not test until there is code checked in?

      Do your testers not have Acceptance based Test Cases to write?
      Do they not need to validate those Test Cases with the business?
      Do they have Functional based Test Cases to gain understanding of by sitting with the programmers as they code?

      There is a lot that can be done in parallel, and more that can be done by swarming…

  2. Tom Perry says:


    Many of the teams I’ve worked with have been very successful executing tests before coding. And documentation before coding (or at the same time). There are no constraints I’m aware of that prevent this. Try it out sometime – you might be surprised at the results. There is no one “right” way to develop software.

  3. Curious says:

    Can you clarify what you mean by “A Set based decision making model is used” a link would be great!

  4. […] What is « Swarming »?, Tom Perry (Agile Tools) […]

  5. jemdjelal says:

    Interesting in theory. But there are two big prerequisites for swarming to begin. (1) You need a cross functional team, not every dev can pick up ‘that’ story if they don’t have the technical skills to do it (2) The mindset change, new SCRUM teams often look to grab the stuff on the left (from the sprint backlog say) as opposed to addressing the stuff on the right first (WIP Work in progress).

    Nice idea if you can address the two points above.

  6. […] Swarm. Encourage the team to assign as many developers, designers and QA to each story as is reasonable (based on how well the work can be parallelized). […]

  7. […] how to do things right before we went ahead and broke them down further. Then we discovered that swarming is a powerful technic and lets us do things seamlessly in parallel. Soon we built or own Brackets […]

  8. Darin says:

    “Swarm” is a great concept. I love the notion of Biomimicry where you look at what is working in nature and apply it to your organization. There is a lot of learn from nature…a place where things generally work better than in organizations!


  9. […] would we provide that environment? Our department asked these questions and the whole department swarmed to tackle the problem. The solution we came up with worked well in our context, and I also believe […]

  10. […] En appliquant des stratégies de partage de connaissance et de collaboration lors des temps libres provoqués par les limites de WIP, on s’attaque directement à la division du travail. Si on divise le travail et qu’on l’attribue, on multiplie les dépendances puisque toutes ces petites divisions du travail doivent être terminées pour que l’item de valeur soit considéré comme terminé. Chaque dépendance augmente les chances de retard de 50%. Ces divisions et ces attributions deviennent des freins à la collaboration et sont rapidement abandonnées au profit d’un découpage plus macro et une réalisation en équipe. On verra émerger des pratiques telles que le mob programming et le swarming. […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: