Swarming vs. Parallel Work

---

Two Theories of Throughput

The parallel-work intuition is simple: with eight engineers, run eight items at once. No one is idle, and the team's "capacity" is maximized. The swarm intuition is the opposite: have many engineers work the same item, finish it fast, then move to the next. Idle people are not the problem; un-finished work is.

Both intuitions are partially correct, and the literature on this — particularly Reinertsen's Principles of Product Development Flow — is unambiguous about when each works.¹

What Parallel Work Optimizes For

• Utilization. Every person is busy.
• Variety of progress. Many items are moving forward at any given moment.
• Specialization fit. When skills don't overlap, parallel work matches each person to the work they can do.

How Parallel Work Fails

• Cycle time inflates. An item worked by one person takes as long as that one person can take. Eight items in parallel finish later than eight items completed sequentially.
• WIP piles up. Half-finished work in eight states is more risk and more management cost than finished work plus one in progress.
• Context-switching multiplies. Each person owns their item plus reviews others; cognitive load is high.
• Late integration. Items finished separately have to be integrated. Conflicts and surprises emerge at the end.

What Swarming Optimizes For

• Cycle time. One item, three engineers, finishes in a third the time. Customer feedback arrives sooner.
• WIP minimization. Fewer items in flight; fewer half-done states; lower management cost.
• Knowledge transfer. Multiple people on the same item learn together. The team's bus factor improves.
• Quality. More eyes on the same code produces fewer defects.

How Swarming Fails

• Coordination cost. Five engineers on one story spend a lot of time coordinating. The throughput penalty is real.
• Skill mismatches. If the work is genuinely backend, the frontend engineers may not have useful contributions.
• "Too many cooks." Some items don't get faster with more people. Past a certain point, adding engineers slows the work down.
• Specialization waste. A senior algorithm engineer swarming on routine UI work is misallocated capacity.

The Productive Reframe

The right question is not "should we swarm or parallel?" It is: "what would maximize flow?" For some work, the answer is swarm. For other work, the answer is parallel. The factors that decide:

• How divisible is the work? Tightly coupled work resists parallelization. Loosely coupled work doesn't benefit from swarming.
• How urgent is the cycle time? If the team needs to ship by Friday, swarm. If timing isn't pressing, parallel.
• How much shared learning matters? When the team needs to all understand the change (architecture, security, novel domain), swarm. When the work is routine, parallel.
• What's the current WIP? High WIP signals the team is paralleling too much. Swarming a story or two clears the board.

The Default Most Healthy Teams Use

The pattern in mature teams: some parallel, some swarm, governed by WIP limits. The team runs three or four items in parallel (not eight), and swarms on any item that stalls. The WIP limit forces the team to swarm rather than start a fifth parallel item.

This is the underlying mechanism Kanban encodes. WIP limits don't directly prescribe swarming — they make swarming the obvious response when the limit is reached. The team learns to swarm by being unable to start new work.

The Hidden Dysfunction

Teams that struggle to swarm often have a deeper problem: code ownership. If only one engineer can work on the auth code, swarming is impossible. The fix is broader code familiarity through pairing, mobbing, and explicit knowledge sharing — not "swarm harder."

Coaching Tips

Add WIP limits.

The single biggest lever for moving a team from over-parallel to healthy swarming. The limit forces the right behavior.

Watch the stuck item.

An item not moving for two days is the swarming opportunity. Pull engineers off other work and converge on it.

Measure cycle time before/after.

Swarming pays off in cycle time. Track the metric — teams that see the data switch on their own.

Don't force swarm on routine work.

Five people on a typo fix is theatre. Swarming earns its keep on consequential, complex, or stalled items.

Address code ownership debt.

If swarming is impossible because only one person knows the code, pair, mob, and document until it isn't. The staffing model can't fix the knowledge problem.

Reframe utilization for managers.

"Idle engineers" is the wrong metric. "Stalled work" is the right one. Until leaders see this, the team will be pushed back to parallel.

Summary

The swarming-vs-parallel debate is about whether the team optimizes for keeping everyone busy or for finishing things. The flow literature is clear: finishing wins. But pure swarming on every item is impractical. The working answer is moderate parallel work (three or four items in flight) with disciplined swarming when work stalls or WIP limits hit. The team that masters this rhythm produces dramatically faster throughput than one running eight items at a time — even though, on any given day, the parallel team looks busier.

Back to The Great Agile Debates