Over a million developers have joined DZone.

Pattern of the Month: Swarm

DZone 's Guide to

Pattern of the Month: Swarm

When an Agile team is faced with an all hands on deck type of situation, this work pattern is called Swarming. Here's a quick review of the practice.

· Agile Zone ·
Free Resource

Collaborative activity is the basis of teamwork. When many people work together, the benefits of joint effort and focus can be realized. Any piece of work which is undertaken can be completed more quickly, and the value to stakeholders can be delivered in the timeliest fashion and with minimal depreciation and cost of delay.

Yet this most fundamental of team behaviors can take on many forms. Pair programming is one, although this obviously constrains focus and shared effort to just a couple of people, and they may engage in this activity only on occasion. Taking things to an extreme, we might have all team members collaborate on one piece of work at a time and make this a permanent arrangement. In effect, the team will observe a "Work In Progress" (WIP) limit of exactly one. Known as "single piece flow," this technique is theoretically the most efficient way a team can work, although there are practical constraints, such as those of physical space, which can limit its effectiveness.

Swarming is another form of collaboration which involves the whole team, but which does so on a more transient basis. The WIP limit will be higher than one, such that multiple work items can be in progress simultaneously. The team will self-organize around their completion. However, in response to a certain event of overriding importance - such as a defect, major incident, or error - the team will suspend that work and focus completely on the new concern. Again they will self-organize, and in so doing they will determine which of them should focus on resolving the matter, and which of them can return to the work in progress. At that point, the "swarm" will have fulfilled its purpose and may end.

Note that if a team supports a pre-emptive mode, then single-piece flow may be implied for that pre-emptive quality of service since the team might need to swarm on any item so raised. This is often the situation with fast-track emergency work, where escalation to the top of a backlog may not provide a sufficient immediacy of response.


Image title

Intent: Have all available resources work on one thing in order to expedite it as quickly as possible.


  • It’s best to do one thing at a time.
  • Many hands make light work.

Also Known As:

  • Single Piece Flow (when used in the context of Quality of Service).

Motivation: In theory, the most efficient way to work is one item at a time. Critical defect fixes can require a high level of motivation as and when they arise.

Structure: A development team accepts and acts on only one backlog item if the associated Quality of Service demands that such prioritization be given. The Work In Progress is limited to one.

Applicability: Swarming should be considered in situations where an urgent requirement demands the attention of the whole development team, and where work on other requirements can be suspended. Note that for Swarming to be viable, it must be possible for multiple developers to work on one item simultaneously and without causing each other impediment.

Consequences: Swarming, when applied in the right situation, can result in a faster response time and a more rapid turnover of defect fixes and small changes. However, it can also lead to waste if developers are allowed to get in each other's way.

Implementation: Swarming can be implemented for Lean Kanban teams of small size, where developers will not cause each other impediment by working on the same item. It is rarely implemented in Scrum development teams since they are expected to work on the delivery of a Sprint Backlog for the achievement of a Sprint Goal, and not to vary the quality of service of individual backlog items. 

See Also:

agile patterns ,teamwork ,agile ,swarming

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}