It’s common for advocates of agile (small “a”) development to wave the flag for small teams. Any more than eight or so, they say, is too big to manage. But even if a team can deliver the goods on time, it’s still possible for it to be too small.

If a piece of work is only a few weeks for one or two people, isolating them can be dangerous. They may be autonomous, and it may look like they won’t disrupt other workstreams, but they are also siloed:

• Knowledge about technology details fails to get spread to others who may need to support it;
• The bus factor for that technology is dangerously small;
• There’s no visibility of poor choices (e.g. technical or design decisions) which may later impact others;
• People outside the team who may be able to solve problems are less likely to see them;
• There is little control over prioritisation.

This last point is worth explaining more. If a workstream has just two developers then they are committed to that for a good period — adding or removing a person is disruptive. But if the work is folded into that of a team of seven or eight — and they work on it as a real team — then they can subtly shift priorities each day. It may take 20-30% of their time on average, but they can add or reduce extra pairs of hands fluidly, and continually balance it with their other responsibilities.

Small teams are great if the deliverable allow them, but smaller is not always better.