Why small Scrum teams rock

Why is it that the rules of Scrum limit team size to between 3 and 9 people? Surely, the more people on our team the better? More people get through more work?

That is certainly true is some cases. For instance, if we need to phone 5,000 people to sell them loft insulation, more people manning the phones will get us there quicker.

Unfortunately, software development doesn’t work like that.

One often quoted study by Lawrence Putnam and Ware Myers looked at nearly 500 medium-sized software projects. Their conclusion? Teams with 9 and 20 members require four times as many man-months as a team between 3 and 7 members for a project of the same size!

Many years before that study, Freed Brooks came to the same conclusion in his book The Mythical Man Month. That’s where he coined Brook’s law:

“Adding manpower to a late software project makes it later”

Let’s take a closer look at a Scrum team specifically to see why a small is better.

1. Self-organisation is easier for a small team

In Scrum, we rely on the team to self-organise to solve the problem at hand. They are the experts and no one tells them how to do their work. That’s how we make sure work is done in the most efficient way.

For self-organisation to work, everyone on the team must be able to see what’s going on. A team member won’t be able to offer their help to someone if they don’t know that a) that person has a problem and b) it’s a problem where they are likely to be able help.

Self-organisation also requires people to know each other fairly well. When you know your team mates and their skills, you know who you can ask for help with a particular issue. You also feel that you can ask for that help. In return, you will know when others might benefit from you offering your help. And, of cause, knowing other’s little quirks makes it easier to know how and when to talk to each other.

When the team is growing bigger, it gets harder to build those close relationships. A team of four will contain 6 relationships between team members. A team of eight will contain 28. The latter team will either need to spend a lot more time talking to each other or we’ll end up with much shallower relationships.

To address the problem, a team may unconsciously or consciously end up splitting into sub-teams, grouping together with people they know better or know they work well with.

When this happens, it becomes harder to work towards a shared goal. Remember how we said that self-organisation requires people to know what’s going on. With sub-teams or groupings within the team, they effectively end up needing to coordinate their work with another team, with all the extra complexity that entails.

2. Scrum causes less overhead when the team is smaller

Let’s make one thing clear: meetings are wasteful! They are expensive and don’t produce anything we can ship. That applies even to our cherished Scrum events. As we’re in the business of getting things done, we need to make sure we spend as little time as possible in meetings.

That is, as little time as possible while still getting the shared understanding, coordination and feedback the meetings are there to provide.

A big Scrum team will see more time lost to meetings and discussions than a small team. We can illustrate that through a simple example.

Let’s say our team has got four members and that they can complete three user stories per person per sprint. That gives us 12 stories in total to talk about in our sprint planning meeting.

Now, let’s double the size of the team! Rather than four people talking about 12 stories, we will have eight people talking about 24 stories. If we spend the same amount of time talking about each story, we have suddenly quadrupled the number of person-hours spent in the planning meeting!

Similar effects apply to every activity throughout our sprint. We’ll be stuck between a rock and a hard place. Either, we will spend a lot more time talking or we can’t talk as much about each item. The latter may seem preferable but it comes at the cost of not being able to collaborate around the details.

3. Small teams can rely on conversations over written documentation

If we believe in the agile manifesto, we believe that face-to-conversation is the most effective way to convey information.

User stories is great way to put this principle into practice. The written part of a user story is just a very small part of it. Instead, we focus on creating a shared understanding through conversation. This is what makes user stories such a powerful tool.

Not only does this approach reduce the amount of time we spend writing documents instead of delivering value. It actually also reduces the risk of misunderstandings.

The problem with written documents is that two people can read the same statement and understand it in different ways. In contrast, when we talk about something, we can ask questions, make clarifications and even draw scribbles on a whiteboard to make sure we’re all genuinely on the same page.

Unfortunately, if our team is big, we’re likely to start seeing challenges with this approach.

If we assume a big team gets through more stories than a small one (which would be the whole point), they will have more stories to discuss. More stories mean more details to remember. However, as each team member would be less likely to work on any given story, they’d have less reason to engage in those discussions and remember the details.

We will end up having to write more things down to make sure people don’t forget. Suddenly, we’ve taken a big step back towards a world of written requirement specifications.

4. On a small team, each person’s contribution becomes more important

Sometimes, we may observe that people on large teams don’t work as hard as those on smaller teams. This phenomenon is often referred to as “social loafing”. The suggestion is that given a half a chance, people will slack. In a large team, it’s easier to hide and hence, people will slack more.

This explanation makes me rather uncomfortable. I think the explanation has got a lot more to do with motivation.

When we’re part of a small team, we can easily see how the success of the team is depending on our contribution. Our work is important. Feeling that we’re doing important work is not only good but necessary for our motivation. In a bigger team, our relative contribution will be much smaller. There are more people around us to pick up the slack. Our work is less important and we get less motivated.

Less motivated people get less done. As simple as that.

Where do we go from here?

The ideal team size will be different 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 must. Just saying “We need to get through the work quicker so we need more people” probably isn’t a sufficiently good reason. The result might even end up being quite the opposite. And don’t get tempted 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.

Thanks for reading this post! If you found it useful, it would be awesome if you spread the word by hitting the 💚 button.

And if you’ve got a few minutes to spare, it would mean a lot to me if you would complete my short survey about Scrum. ⬅⬅⬅

I first published this post on my personal blog Magnus Dahlgren — Thoughts from a Scrum Master.