The Two Staffing Models
The Scrum Guide is clear: the development team should be cross-functional, possessing all skills needed to create the product increment. In practice this is hard. Specialist skills — security, UX research, data engineering, ML, accessibility, internationalization — appear unevenly across stories. Embedding a specialist permanently in every team means the specialist is under-utilized most of the time. Pulling them in on demand introduces handoffs and waits.
The debate: do you stuff every team with every skill (cross-functional), or maintain specialist pools that swarm on stories that need them (swarm)?1
The Case for Permanent Cross-Functional
- No handoff waits. All skills are present; the team never blocks waiting for someone outside.
- Shared context. Specialists embedded in the team understand its customer, codebase, and constraints.
- Continuous improvement. Specialists provide ongoing input, not just gate-style review.
- Identity. A truly cross-functional team is a cohesive unit; a team plus visiting specialists is a team-plus-visitors dynamic.
How Cross-Functional Fails
- Specialist under-utilization. A team's security needs are episodic. A full-time security person on each team is mostly idle on security work and ends up doing other things.
- Specialist isolation. A security person embedded in one team is cut off from peers and current practice elsewhere. Their expertise rots.
- Scarce skills don't scale. If your org has three accessibility experts and twenty teams, the model breaks immediately.
- Career path problems. Specialists isolated in product teams have no peer feedback, no peer learning, no specialty-aligned career growth.
The Case for Swarm
- Specialist utilization. Three experts across twenty teams can serve everyone if the engagement model is good.
- Maintains specialty community. Specialists stay connected to peers, current practice, and ongoing learning.
- Scales with limited expertise. Most organizations have only a handful of specialists in scarce domains. Swarm is the only model that works.
- Specialists improve. A pool of specialists peer-reviews each other, builds shared patterns, develops the practice. An isolated embedded specialist doesn't.
How Swarm Fails
- Coordination cost. Each engagement requires scheduling, ramp-up, context-transfer. A 30-minute consult costs an hour and a half of total time.
- Specialists become bottlenecks. Demand outpaces supply. Stories wait in the specialist's queue.
- Gate-style review. Specialists pulled in late catch problems that should have been designed-in early.
- Team learns less. Without an embedded specialist, the team doesn't grow the skill in itself.
The Modern Synthesis
Most healthy organizations use a hybrid based on demand frequency:
- High-frequency, high-priority skills: embed permanently. Backend, frontend, QA, design — these touch nearly every story. Cross-functional.
- Medium-frequency or scarce skills: use enabling teams (see Team Topologies). Security, accessibility, ML engineering, data engineering. The enabling team teaches and supports the stream-aligned teams.
- Episodic specialty work: swarm from a central pool. Penetration testing, formal accessibility audits, performance regression analysis. Pull when needed.
The categorization is the work. Putting security on the cross-functional team for an e-commerce product is right; putting it there for an internal CRUD app is overkill. The frequency of need should drive the model.
The Hidden Variable
This debate is often a proxy for an inventory question: does the organization have enough specialists to embed at all? Many organizations don't. They have a few specialists serving many teams, and the question of "embed vs. swarm" is moot — they can only swarm. Naming this reality openly is more useful than pretending the choice exists.
Coaching Tips
Measure skill demand frequency.
How often does a typical story need this specialty? Daily = embed. Quarterly = swarm. Weekly = enabling team.
Avoid lonely embedded specialists.
Even an embedded specialist needs a peer community. Otherwise their expertise rots in isolation.
Build enabling teams deliberately.
Three accessibility specialists serving fifteen teams is more impactful than three specialists scattered as embeds.
Don't make swarm a gate.
If specialists only appear at the end of work, the work is being reviewed not designed. Pull them in early.
Audit specialist utilization.
An embedded specialist spending less than 30% of time on their specialty is misallocated. Either expand their role or move them out.
Have the inventory conversation.
If "embed vs. swarm" is moot because there aren't enough specialists, name that. The question becomes "how do we grow the bench?" — a different problem.
Summary
The cross-functional-vs-swarm debate is best resolved by demand frequency, not ideology. Skills the team touches every sprint should live in the team. Skills the team touches every few months should be available through a swarm model or an enabling team. The wrong move is to insist on full cross-functionality everywhere, which under-utilizes scarce expertise and isolates specialists from their peers. The other wrong move is to swarm everything, which produces gate-style reviews instead of integrated quality. The right move is to choose per skill, deliberately.
- Skelton, Matthew and Manuel Pais. Team Topologies. IT Revolution, 2019.
- Schwaber, Ken and Jeff Sutherland. The Scrum Guide. 2020.
- Larman, Craig and Bas Vodde. Large-Scale Scrum. Addison-Wesley, 2016.