The organization

Swarming: finishing one thing at a time, together

A team in which everyone moves forward on their own subject gives an impression of speed and finishes little. The Swarming pattern in A Scrum Book proposes the opposite: the whole team concentrates on a single item until it is done, then moves on to the next. The idea comes from Toyota's one-piece flow, and it has its limits.

Five things open and nothing finished

A team of five developers is building the route-tracking app for a home meal delivery company. It works in Sprints, fixed-length periods that last two weeks here. At the start of the Sprint, each person took one item from the list: the route map, the customer signature, delay alerts, the payroll export and the handling of special diets.

The day before the Sprint Review, the meeting where the team shows its result to the stakeholders, the Product Owner, who decides the order of the items to build, goes around the desks: "What can I show the route managers tomorrow?" Lucas replies: "The route map is coded, the tests are still to do." Amel adds: "The alerts are almost done, I'm waiting for Lucas to review my code." The other three are in the same situation. Five items are "almost done" and none meets the Definition of Done, the shared definition of what finished work is. The Product Owner has nothing to show.

The word swarming comes from swarm, as of bees. It describes a team that gathers on the same piece of work instead of scattering.

The Swarming: One-Piece Continuous Flow pattern

A Scrum Book (2019) describes Scrum as a set of patterns: each one sets out a recurring problem, the forces at play and a solution drawn from experience. The Swarming: One-Piece Continuous Flow pattern carries one star: the authors see in it the core of a good solution without claiming it is the only one. It starts from a division of roles. The Product Owner orders the list of what needs to be built (the Product Backlog) to obtain the greatest value. The Developers, for their part, organize their work in the Sprint so that production flows as well as possible.

The problem. Working on too many things at once sharply reduces each person's effectiveness and the team's velocity (the amount of work it finishes per Sprint), sometimes down to zero. When everyone looks after their own subject, members do not help each other and do not learn from one another.

The forces. Individual preferences and everyday obstacles scatter effort. The result is a great deal of work in process, that is, work started and not finished. In a factory, this means half-made parts that take up space and tie up money. In an office this stock cannot be seen, but it causes just as much delay.

A developer working alone on an item prefers building to testing, and tests get postponed. If several items fall behind, none is finished at the end of the Sprint. Yet running several things at once gives an impression of speed and satisfies management's wish to see everyone busy. Finally, the items of a complex product depend on one another, which limits work in independent subgroups. Developers often want to work separately so as not to get in each other's way, which the book regards as a symptom of inadequate technical practices.

The solution. The team focuses as much effort as possible on a single Product Backlog item and finishes all the known work on that item as quickly as possible. The person who takes the item becomes its "Captain". Everyone else helps if they can, and nobody interrupts the Captain. As soon as the item is done, whoever takes the next one becomes Captain in turn.

The book makes two points clear. Focusing on one item does not mean running through phases: on the current item, a few minutes of building alternate with a test, which leads back to a little analysis, until everything is done. Handling one phase at a time for all items would be another way of avoiding teamwork. Next, each individual's efficiency stops being the criterion, and the book asserts that a little slack in everyone's schedule speeds up the whole.

Finishing one thing at a time: a simple calculation

Take three items, A, B and C, each requiring two days of work by the whole team. The team can handle them one after the other, or advance one day on each in turn.

In both cases everything is done on the sixth day. But in the first, A is usable from the second day, and items are finished on average after four days instead of five. If an emergency stops the work on the evening of the third day, the team has one item done and another half done in the first case, and three halves in the second.

This calculation assumes that switching from one subject to another costs nothing, which is optimistic. The book refers to Gerald Weinberg's rule of thumb (Quality Software Management, 1992), for whom running two projects at once loses about 20% of the time in context switching, and more beyond that. This is a practitioner's estimate, not a measurement.

From Toyota's one-piece flow to limited work in process

The pattern's subtitle refers to industry's one-piece flow: each part moves from one step to the next without waiting in a batch. The book cites Taiichi Ohno, who recounts in Toyota Production System (English edition, 1988) how, in 1947, Toyota arranged its machines in parallel lines or in an L shape so that one worker could run three or four along the production path. Skilled workers resisted, because they had to become multi-skilled. The Lean corpus article on continuous flow and one-piece flow (in French) explains this principle in detail.

Swarming transposes the idea to a team. The "part" is the Product Backlog item, and the "batch" is the set of items started at the same time. The same resistance appears, since everyone has to step outside their specialty to help finish.

Other approaches achieve a similar effect with a numerical rule. David J. Anderson's Kanban method (2010) sets a maximum number of items in progress for each step. Swarming is the extreme case in which the team sets itself a limit of one.

The 2020 Scrum Guide mentions neither swarming nor limiting work in process. It leaves it to the Developers to decide how they turn the selected items into a finished result, and asks them to adapt their plan every day. Swarming is therefore a practice compatible with the Guide, without being a rule of Scrum. Another difference in vocabulary: the book speaks of the "Development Team", a term the Guide replaced in 2020 with "Developers".

How to go about it

The book offers a few levers. The team takes the item at the top of its board and organizes itself around it. It sets itself a clear Sprint Goal, which brings it together. The organization, for its part, values the team rather than individual feats: the authors recommend limiting personal rewards and fighting the hero culture, overtime included.

The Daily Scrum, the fifteen-minute daily meeting where the Developers adjust their plan, is where swarming gets decided. The pattern's wording leaves some leeway, since everyone helps the Captain "if they can". When an item cannot keep everyone busy, those who cannot help take the next item, and the team keeps the number of open items as low as possible.

Limits and pitfalls

Not all work can be divided. Fred Brooks made the point in The Mythical Man-Month (1975) with the example of pregnancy, which lasts nine months however many women are assigned to it. Five people on a small item get in each other's way. The "if they can" proviso acknowledges this, without saying when help turns into clutter: that is for the team to judge.

Swarming also assumes shared skills and practices that let several people change the same piece of work without getting in each other's way. A team of specialists who cannot help one another will get nothing from it at first, and versatility is acquired slowly. Working together all day is tiring, and some people need time alone to think.

Seen from outside, three people in front of the same screen look like waste. If management judges the team by each person's utilization rate, it will quickly undo what the team has put in place.

That leaves the figures. The book asserts that this practice doubled the productivity of every team at the Danish company Systematic and that it brought Citrix Online's delivery cycles down from 42 months to under 10. These results come from papers signed by people involved in those transformations, in which many other things were changing at the same time. They do not allow the gain to be attributed to swarming alone. The article Criticism and the state of the evidence returns to this kind of claim.