11Who fits on an agile team?

It is an uncomfortable question, often avoided: is everyone suited to working in a Scrum team? The short answer is no. The useful answer is more nuanced, because the people who fit least are often not where one expects them.

What Scrum asks of people

Scrum is demanding in ways that are rarely made explicit. It asks people to accept that their work, progress and difficulties are visible every day. It asks them to share ownership, so that success and failure are collective. It asks them to tolerate ambiguity, since stories are deliberately incomplete and gaps are filled through conversation. It asks them to direct themselves, pulling work rather than receiving assignments. And it asks them to give and receive direct feedback.

Some people thrive in that environment. Others find it tiring or threatening, and prefer well-defined tasks, individual ownership and long periods of uninterrupted focus. Those are legitimate ways of working. Some deep specialists, in areas such as cryptography, signal processing or complex algorithms, are often more effective outside a standard Scrum team.

Can't, won't or not allowed

Table 4 · Three reasons someone does not fit, and why they call for different responses.

In my experience the third case is the most frequent, and the most often mistaken for the first two. Before concluding that a person is not "agile", it is worth checking which of the three situations applies.

The misfits above the team

The roles that most often undermine Scrum sit above or around the team rather than within it.

• The manager who cannot let go assigns tasks, attends the daily to collect status and overrides the team's plan. Self-management cannot develop under these conditions.
• The proxy Product Owner has no real authority and no direct access to stakeholders, and relays decisions taken elsewhere. The value loop is broken at its source.
• The renamed project manager holds the title of Scrum Master but runs the project in practice: the shadow project manager described in section 05.

These roles do more damage than any individual developer, because they distort the whole system. They are also harder to discuss, because they are senior.

Within teams, some patterns are recognizably destructive: the hero who keeps knowledge to themselves to remain indispensable, the cynic who undermines every retrospective, the person who systematically refuses work outside their specialty. Scrum assumes a self-managing team, yet teams rarely choose who joins them. Approaches to team self-selection exist, described for instance by Sandy Mamoli and David Mole in Creating Great Teams, but few organisations try them.

Format is not principle

"Not a good fit" can easily become a way to exclude people who simply work differently: introverts, neurodivergent people, non-native speakers, people who think better in writing than in meetings. Many of them are excellent engineers. The stand-up meeting, constant verbal collaboration and open-plan pairing favour one temperament, but none of them is essential to Scrum. Written updates, asynchronous refinement and quieter forms of collaboration are fully compatible with transparency and inspection. The values and the pillars matter; the format of the rituals is the surface of the iceberg.

The precise conclusion is that not everyone fits every form of agile teamwork, and teams should adapt the form before deciding the person is the problem. Where the issue is a genuine preference, the right answer is another path. Skelton and Pais's Team Topologies offers useful options here, such as complicated-subsystem teams for deep specialists. Sometimes the framework is the misfit: operations and maintenance work often suit Kanban better than Scrum.