Swarm

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.

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

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

Proverbs:

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

Also Known As:

Single Piece Flow (when used in 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 this high level of as and when they arise.

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 others 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.