Why small Scrum teams rock

The more, the merrier, right? Well, not in Scrum.

Every time I’ve been working with a team bigger than the 3-9 people guideline, I’ve experienced how incredibly hard it can be to make Scrum work well in these conditions. And problems can start showing even with teams towards the higher end of what’s “allowed”! In this post, I will share the top 5 reasons I’ve seen why smaller is better.

1. Easier self-organisation

In Scrum, we rely on the team to self-organise to meet their sprint goals. No one tells them who should be doing what or how to do it.

For a team to be able to self-organise, though, everyone on the team needs to be able to see what’s going on, and they need to know each other’s skills and quirks fairly well. When the team is big, it gets harder to get that overview and build those close relationships.

2. Not as much Scrum overhead

A bigger team will hopefully get through more work. That’s the whole point. However, more work also means more stories to talk about in sprint planning, more updates in the daily stand-up and so on. Meetings start dragging on.

Not only do they get longer. They will be (and very much feel) less relevant to each team member. There will be too many things discussed that they won’t be working on. The solution is often to cut the level of details and split discussions into smaller groups, creating more challenges to that self-organisation.

3. Conversations over written documentation

In agile we value working software over comprehensive documentation and one example is how conversations about user stories beats having a detailed written specification. When we talk to each other, we can ask questions, discuss back and forth, make clarifications and even draw scribbles on a whiteboard to make sure we’re all genuinely on the same page.

The challenge, however, is to remember what we talked about and agreed. If we’ve only got a small number of stories, a couple of bullet points or a photo of our whiteboard scribbles can be all we need to remind ourselves later. The more stories, though, the harder it gets.

In a large team, with a lot of stories being discussed that we’re unlikely to be directly involved in, it is also natural to start paying less attention to the discussions. We end up needing more and more notes to know what to do. Far too often, those notes are slowly and painfully typed into Jira on the big screen while the team is reading Twitter on their phones under the table.

4. Avoiding sub-groups

With a large team, sub-teams often start forming, either consciously or unconsciously. A clear sign is when you start hearing phrases like “our part of the sprint goal”, “our stories” and so on. I’ve seen it so many times! Rather than everyone working on the most important stories, people split the stories between them and work on stories in a particular area.

Suddenly, they’re more or less working in a multi-team environment with the extra complexity that brings with it in terms of coordination, dependencies and so on.

5. Higher motivation

People get more done and do it to a higher standard when they are motivated. Work being meaningful is one of the most important factors contributing to that motivation.

Team members in a small team can easily see how the success of the team is depending on their contribution. Everyone is in it together. In a bigger team, each individual’s relative contribution is smaller and much less visible.

How to keep teams small

The ideal team size will differ from team to team and depend on the individual team members, their skills and the work they are working on.

So, what do we do? My 5 cents are:

• When you start a new team, make it a small team. You probably don’t need as many people as you think. Your ideal team size may well be four or five people — but make sure they have diverse enough skills to be able to deliver the work.

• Only add additional members to the team if you have to. Just saying “We need to get through the work quickly so we need more people” is probably not a sufficiently good reason. The result might even end up being quite the opposite. And don’t get tempted to go beyond the maximum size of 9.

• If your team is already so big that you aren’t getting the benefits of a small team described above, suggest an experiment to split into two teams for a couple of sprints and see whether it works better. It may or it may not.

27 September 2019 by Magnus Dahlgren

This work by Magnus Dahlgren is licensed under a Creative Commons Attribution 4.0 International License.