Your Team is too BIG (Scrum)

Team sizes,  I’ve been around a number of projects and yet again the size of some Scrum teams never ceases to amaze me.  A recent problem project I landed on had 20 people in the stand up – I observed the following:

  1. People talked, some clearly and a lot not so clearly – it was very hard to hear 70% of the team members
  2. The team members gave an update – hardly any of the updates resulted in team engagement and interaction
  3. The board did not reflect reality
  4. Everyone was talking to the Scrum Master
  5. The team members looked disengaged and body language was poor
  6. A lot of things were ‘stuck in test’, mainly because the stories were not flowing through at a consistent rate

This team has been together for over 18 months, it wasn’t acting as effectively as some of the smaller teams I’ve managed.  In my view, teams of this size have a number of structural issues they have to overcome in order to succeed. I term this diseconomies of team scale.

Risk Area 1: Communication & Relationships

Its really hard to make a group of individuals collectively act as a team. These are people that don’t know each other and have been thrown together. Relationships and mutual respect are hard earned in terms of time and effort, this becomes a lot more difficult to achieve as a team size increases.

Group Comms

Illustration from article Group Size and complexity

There has been plenty written about the communication overhead as a team grows, but from my observations there is a little more to it than that…

Risk Area 2: Responsibility Dilution & Fragmentation

The problem with large team sizes is that team responsibility becomes devolved and diluted amongst members.  Roles naturally become over specialised and siloed.  This is a particular issue when a team isn’t performing and members retreat to their core set of skills. When roles are siloed, a natural consequence is for important items to fall between the cracks and for delivery to fail.  It also becomes difficult for individuals to show their actual value and it becomes easier for weaker and lazy members to hide.

What actually happens when teams become too large is that the team naturally starts to fragment, and they tend to start fragmenting along their primary core skill sets – testers become separate from developers from BA’s.  Large teams naturally start to reduce relationship complexity by splitting into smaller units they can communicate within, silos start to form.

A Team with a large number of members will also find it harder to take collative responsibility for a team deliverables, or failure to deliver.  Teams must be given an objective for something they feel empowered and able to deliver, this is easier to achieve if individuals feel empowered to influence the outcome of their team. Individuals influence within larger teams is naturally diluted.

Risk Area 3:  Individual Accountability to Team

One of the most striking things I’ve noticed about smaller team sizes is that team members don’t just do their core job.  They are confident enough to help others, which they know will aid the team achieve their goal.  They don’t feel accountable to an individual – they are accountable to their team.  The team knows their value and team members are confident in each of their abilities.  In larger teams, its becomes harder to justify value by helping others, or doing those things that fall between the cracks.

Risk Area 4:  Impediments to Performance

This is a personal one, but I find it easier with a smaller team size to identify the root cause of impediments.

Risk Area 5:  Finite capacity of individuals

A personal theory, but I’m theorising that individual members of a team have a finite capacity to store information about what each other do, how to manage relationships, interactions and how to communicate.  When a team is over a certain size, team effectiveness starts to diminish as that capacity is overloaded.

The Ideal?

I’ve deliberately kept away from a team of X is the ideal size, because it depends on the context.  My experience is that anything above 11 is a warning sign.  Its up to the Scrum Master or Delivery Manager to recognise the signs and work out how to split the team into a smaller teams.  Each of the teams must be allowed to deliver regular incremental and measurable value – that value should primarily be business value, but can also be value delivered to the service of other teams.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s