Team Size and Why It Matters

April 21, 2016

Originally posted to: engineering.skybettingandgaming.com

Team size varies massively across projects depending on various factors including urgency and nature of the work. The Scrum Guide suggests a size of seven (plus or minus two) works best; Jeff Bezos stands behind his famous “Two Pizza Team” rule, which describes a team that can be fed with two pizzas is a good sized one.

There are some benefits to bigger teams: More team members means a bigger pool of skills and experience - This could mean more diverse approaches to problems, and also less of an issue if some key member was absent. Big teams, however, have an increased overhead for both communication and coordination, which gives smaller teams a much greater advantage in many ways.

Big vs. Small

Here are some of the differences that I’ve noticed working in a small (~6 people) and large (>10 people) team:

1. Communication

Increasing communication between people is often thought of as the solution to better teamwork: if we have a big team where everyone communicates with each other, everyone will understand what everyone else is working on, reducing the impact of dependencies will mean the team will get better at what they do. In some situations this may hold some truth, but it doesn’t always work out as nicely in reality. If you compare a small social gathering you’ve been to with a larger party, you will notice that we simply struggle to keep up a meaningful conversation with everyone there at the same time, and this is exactly why you start seeing smaller conversations forming around the room.

In the worst case, everyone in the team must communicate with everyone else, and the number of connections between the team members becomes exponential.

Number of connections formula

This makes it hard to ensure everyone is on the same page: that they understand the process and is on board with the goal that they are working towards. It also makes it more difficult to build meaningful and trustworthy relationships with the rest of the team. As Stephen Robbins describes in Essentials of Organizational Behaviour, bigger teams have more difficulty establishing trust and mutual accountability between themselves. This is also backed up by Dunbar’s Numbers, which suggests the size limit of a group lies between 5-15 people for trusted friends.

A small team enables people to be part of a team where everyone can communicate efficiently, helping to build a team which is trusting and motivated.

2. Management

Have you ever been in a planning meeting with 10+ people? Or a retrospective with even more? It becomes significantly harder to coordinate a meeting with a large number of people, and often it also takes significantly longer to achieve the same thing. Large teams generate a lot of complexity which can be difficult to manage with process. Making sure everyone understands the current process’ policies, how they have been defined and importantly also in agreement to following them.

These effects can cause frustration and lack of belief in the process, where some ceremonies can feel too challenging to organise, or take too much time away from actual development.

Smaller teams help members stay in control of their ceremonies and process, making it easier to manage, and allowing the focus to be on development, improvement and working software.

3. Engagement

It’s important for a person to feel a part of the team they work in. Big teams make it more difficult for people to communicate effectively, to build trust, and to have a significant voice in discussions. This can lead to it being more difficult to be an engaged member. Social loafing is a phenomenon that also helps to describe a disadvantage to larger teams, which is where people exert less effort when working with a greater number of people as it feels less important for them to do so.

In a smaller team, people can feel like they have a much more significant part to play. People have more chance to have a say in how or what things are done.

4. Team Knowledge

In larger teams, silos of knowledge are much more likely to occur. This can be caused by multiple projects being worked on at the same time. Even if people are free to pick up any work in the backlog, they are likely not to switch between different work streams after they start. This is to avoid context-switching, along with the desire to finish a project once started. Secondly, it can occur due to the range of skills in the team. If someone has experience with database design, they will likely want to or be expected to pick up the database-related work. Although this allows people to specialise in areas, it also reinforces silos of knowledge and skills in the team. The easiest way to think about why this isn’t a great idea is the bus factor. This describes the number of team members that can be lost from a team (ie. hit by a bus) before it is unable to continue working.

“Will the project fail if this person is hit by a bus?” - Bus Factor (https://en.wikipedia.org/wiki/Bus_factor)

If you have a lot of knowledge concentrated in one person, and that person gets hit by a bus, the team will struggle!

A small team forces a greater shared responsibility for getting things done and learning about new things together. With less people, communication and relationships are stronger, making learning and sharing knowledge much easier.

Parting Words

If the aim is to build teams around motivated and engaged people, making it easy to learn and share, and most importantly ensure the team is happy, then small teams can help. If you work in a big team, just being aware of the challenges that it creates can help you make better decisions. Although it can be difficult to split existing teams down, especially if you always have projects on the go, the important thing is to just try it, measure it, and reflect. If you record metrics for your team, they can be a big indicator into how well your team is working together. Look for things like changes in relative velocity, tickets spending less time in planning columns, and less redo work. Don’t just look at quantitative data either, talk to each other after trying a smaller team and discuss what’s working well or not (this is when retrospectives come in useful).

And remember, a “Two Pizza” team will make it much cheaper for you to buy lunch for everyone!

Comments

comments powered by Disqus