Having worked in tiny, small, medium, large and extra-large teams, I was reflecting on what size works best.  What I realised is that there isn't a magic number and it depends on several factors.

What is the ideal agile software development team size?  Generally, the number stated at between 5 to 8 people, but the ideal number depends on:

  • How many people the team leader can manage well
  • The kind of work done in the team
  • The age and personality of the team (not the team members!)
  • Who is considered part of the team

So rather than setting an arbitrary number, let's discuss what issues maybe affect the optimum team size and how one may be able to increase/decrease it if needed.

Determining the Perfect Team Size

"Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint."  The Scrum Guide

A high performing team can do A LOT of work.  I have been on a team of five, who were running circles around a team of close to 30 people.  At the right size, with the right people in the right context, the whole is far greater than the parts.

However, putting 5 people in a room and expecting them to do the work of 30 people magically isn't going to work (sometimes you are very lucky... but not often).  The first thing you need to consider when trying to work out how big you can make the team is how skilled is the person who is going to run it.

The team lead needs to spend enough quality time with everyone on the team to iron out all the personality issues early, remove any blockers and engage/nurture the team.  This work is on top of any work they need to do managing up and other duties.  We need to balance/consider;
How much time do they need to spend:

  • looking after each member of the team?
  • managing up? i.e. preparing reports, getting approvals etc.
  • working on tasks allocated to the team?

If the team lead can quickly (but still effectively) get through team nurturing duties and they don't need to spend much time on managing up and team's work tasks, then they can look after a bigger team.

The kind of work is also essential to consider.

  • Is the work easy to divide within the team?
  • Does the team need to handle BAU, project and emergency work?
  • Does the team have all the skills needed to complete the work assigned to them successfully?

These factors impact how large/small the team can be or what work to allocated to them.

Another aspect to consider is how well established is the team and are they an open or closed team?  If the team have been around for a while and have developed a friendly and open internal culture, then adding an extra member isn't a big deal.

Finally, when we talk about team size, we need to decide whom we count as being a member of the team.  This decision varies from organisation to organisation and may include people who float between several teams.

Managing Work

The size of the team influences the kind of management and tools used.  With a smaller team, complex processes and documentation may not add much value and cause frustration.  People don't like to do work, which they perceive has no value.

If the team is large, then having too few processes and tooling can also cause frustration and confusion.  I have seen $30 million worth of work managed with Post-it notes and index cards, and it was a mess.

The irony is when I have worked in small and high performing teams, we happily adopted and extensively used ticketing, wiki and source control systems because we found it very helpful.  We didn't have stand-ups, a board or regular meetings like showcases and iteration planning session.  The business stakeholder sat in the same office as the team, and we developed rituals that worked for us.

Team Cohesion

How formal processes in the team need to be, and how large a team can grow can be affected by team cohesion.  If the team gets along well and people like to work with each other, then gradually bringing in new people who gel well with the rest of the team should be successful.

If the team is too large, then people work in their silos with small pockets of collaboration here and there.  Remember that too large is not a magic number.  It could be 5 or 15 depending on many factors.

Once a team has fallen apart, it is hard to bring it back together.  Team activities like lunches and 'team-building exercises' can help but only if the issues that drove the team apart are resolved first.  If a team has drifted away because of an abusive manager or leadership issues within the company, then no amount of team-building can fix the problem until the root cause is fixed.

Ensure there is the Right Mix of Skills and Knowledge

A team should not be so small that the skills needed to complete its work aren't present.  If the team needs strong database skills and no-one on the team has those skills, then one needs to either:

  • bring someone into the team who has those skills (making the team bigger)
  • move the work that requires the skill to another team
  • train the team (not just one person) in the required skill

It is also essential to be aware that small teams do carry a 'bus factor' risk.  How many people could 'get hit by a bus' before the team/company would find it impossible/expensive to keep going.  I consulted for a company where a large chunk of the development team left suddenly, and no one knew how to maintain core systems.  It cost a lot of time and money to reverse engineer the stack.

Large teams can also carry a high 'bus factor' risk.  If there are only one or two people who know how to maintain and extend a system and they leave, then the company can be in real trouble.  It is vital to sit down and work out where risks exist in a team/company and fix them.

An interesting exercise is to ask "If Sam goes on holidays for 6 weeks, what would we have trouble doing?"  This exercise is a good way of working out what knowledge and accesses Sam has that might need to be shared.  It is more pleasant than asking "If Sam died/left... "

Roles included in the team

When we talk about team size, we need to define who is part of a team and what they role/s and responsibilities are.  A simple definition would be anyone who is doing work assigned to the team is part of the team.  However, there is work locating the work, defining the work, reviewing the work etc.,  are individuals who do those task part of the team?

It is also common to have individuals with specialist skills float between teams, i.e. the data expert or the QA consultant.  These people contribute to completing work done by the team but might not be there all the time and may have conflicting priorities.

Some teams are larger than they need to be because of a belief that one role equals one individual.  So there is a BA, QA, Engineers, Architect, IM, DevOps etc.  An individual can take on multiple roles, and in fact, I firmly believe that having people exposed to multiple functions makes them better at their primary role, i.e. having an Engineer do some BA and QA work makes them a better engineer.  The role Iteration Manager can be shared and rotated in the team.

Types of Work can Effect Team Size Sweet Spot

As discussed in 'Balancing BAU and Project Work',
there are different types of work that a team can be exposed to.  Each type of work has its advantages and disadvantages for the team.  BAU work is usually relatively short and discrete work that can be easily distributed amongst the team.  Project work is more involved and requires more extended periods of close collaboration, which might be more comfortable in a smaller team.

Ideally, the team has a mix of BAU and project work, and the people have turns solving BAU, project and emergency work.

Each Team has its Perfect Size.

Depending on the factors discussed above, i.e. leadership, kind of work, team cohesion and skills mix, a team has a natural optimum size.  If a team is too large or too small, then you see signs in the team, i.e. people start working in isolation or people are frustrated and unhappy because they don't have the skills to complete the work correctly.

Just because a team's optimal size is X at a certain point in time, doesn't mean it can't grow/shrink in the future.  If you want to grow the team, then you can proactively work enabling the team to grow, i.e. work with the team lead to get through more team management work and reduce their other duties, change the mix of work going into a team, help the team roll out more formal work management tools and processes etc.

Just remember to be observant and sensitive to the team.  If you try and help the team grow, see how the team reacts and whether you are helping the team or killing it.  You may need to slow down or try something different.  It is hard to get a team to come together and become high performing, and it is very easy to kill a high performing team.

How do you scale small teams to handle large and complex development work?  Each team can be small and specialised, looking after a part of the more extensive system.  Teams need to agree to upfront, how the system components will interact, and how those interactions will be documented/enforced.  Then each team can work on their part of the system.  It is also helpful to have people move between teams, but not so much that team cohesion is lost.

As a manager, how do I look after a large group of people?  If you are responsible for more people than can fit into a single team, then you need to split the group into teams of optimal size.  You then treat the team leads as part of your team, i.e. if there are six teams, then you have the six team leads directly report to you.  If the number of people reporting to you is too large, then you create a middle layer.  No manager should have more people directly reporting to them than they can comfortably manage, usually 5-8 people.