Scrum Team Size

One of the most important aspects of a Scrum team performing at their best is to get the size and composition of the team right. Size is simple, but it's importance is not generally recognized or explained. So I have taken it on myself to explain it here.

Composition is a bit trickier. Its not just about skill sets (which I already covered last year - see Agile Roles) but also about personalities and how members get along. Another consideration is how and how often teams should be reorganized. Due to lack of space and time I will leave the discussion of team composition until next week.

Scrum Team Size

I have worked in teams from a size of 3-4 to a team in the range of 14-18. In my experience a good Scrum team size is about five with a maximum of about seven. Depending on the people and the type of project you might be able to get away with a team size of nine.

I have read many books and articles on Scrum and the absolute maximum team size is always specified as either seven or nine. For example, I am currently reading an excellent book called Succeeding with Agile by Mike Cohn who says that the accepted rule is a team size of five to nine, but recommends (page 178) the less regimented rule of a team that you can feed with two pizzas. Mike mentions that this is a convention used at Amazon. (I'm not sure if this means that you can have a team larger than nine if you get larger pizzas or smaller developers:) Later on I will tell you how to split a team that is too big.

Scrum rules also give a minimum size of five, though I have also seen three mentioned. In an extreme case a small software company may have to make do with a team of three - two developers (one of whom acts as a part time Scrum Master) and a Product Owner (hopefully provided by the client).

Every Scrum article, book, expert and consultant emphasizes the importance of the team size, so don't question it! If you insist on questioning it, despite my advice, then I can give you several arguments which I explain in the next sections.

Social Loafing

Social loafing has been extensively studied starting with RingelMann about a century ago - see Ringelmann Effect.

I talked about this at length in my previous post.  In summary, social loafing is the effect that as more people work together to perform a task then the less effort each individual contributes to the task. The effect increases as the number of people increases but is measurable even with two people. Most studies show a pronounced drop when the group size reaches around seven to twelve people depending on the type of task.

Try to limit the size of Scrum teams if for no other reason than this.

Visibility

An important feature of Agile that counteracts social loafing is visibility.

Visibility was originally designed to assuage the fears of the customer. The PO (and other stakeholders) can, at a minimum, see that progress has been made at the end of each sprint. If they want even greater assuagement (is that a word :), they can examine the sprint board on a daily basis. Of course, the PO does not, and need not, know what each team member is doing but they can easily see progress as tasks move to "done" status.

peer pressure
counteracts
social loafing

However, visibility is also important within the team. In Scrum everyone in the team should know what everyone else is doing. This is essential if the team is to self-manage and self-organize effectively. It becomes very obvious when someone is not pulling their weight. The resulting peer pressure counteracts social loafing.

Obviously, as the team size gets bigger it becomes harder for team members to understand what everyone else in the team is doing. Studies have shown that even the most skilled multi-taskers can at most keep track of nine separate activities. My experience, and that of many others, is that a team of nine is the absolute maximum, while even seven is getting too big.

I have heard the argument that a Scrum team is like a sports team (such as a rugby team), and since a rugby team has 15 players you should be able to have a Scrum team of that size. (First, I would say that a rugby team is composed of two cooperating teams - the forwards and the backs - but I don't know enough about the sport to argue that further.) It's true that a Scrum team is a bit like a rugby team but the main difference is that individuals in sports team have much greater visibility - it is much more obvious what each player is doing. Another difference with sports, is that typically only a one or a few players are actively involved in the game at any time, whereas in a Scrum team everyone is working diligently all the time.

the major benefit
of the daily standup
is visibility

Scrum practices are important. In particular, the major benefit of the daily standup is visibility. This is why it is very important to make sure the standup is working properly as I discussed here a few years ago (see October 2012).

Remember, visibility is essential for counteracting social loafing. The team size should be small to facilitate this visibility otherwise team members can easily fade into the background.

CASE STUDY :)

A colleague once worked in a Scrum team that was far too big at a size of more than 20. As an "experiment" he tried several different strategies to avoid talking or saying anything useful at the daily standup. Due to the size of the team he found it very easy. Sometimes nobody would notice if he did not even attend!  This demonstrates how important a small team is for visibility.

Team Spirit

Having a good team spirit is another way to counter social loafing. Many of the principles and practices of Agile encourage the team to work closely together which fosters team spirit.

To invoke another sporting analogy consider times in relay events such as swimming, running, etc. According to the Ringelmann Effect, times of athletes in relay events should be slower than their times in individual events. However, it is not unusual for athletes to perform as well or even better in a relay. This is entirely due to team spirit.

There are many aspects of Agile that promote team spirit.

• focus on customer requirements
• having a clear and common understanding of team goals
• encouraging collaboration and having the team self-organize
• rewarding the team, rather than the individual team members
• encouraging open, honest communication
• empowerment and self-management
• motivation of team members to do their part
• team members feel that they are making a valuable contribution

Notwithstanding Agile practices, team spirit may be affected by other factors, such as the personalities of the team members (something I talk about next week), competition with other teams, etc.

team spirit decreases
the larger
the team becomes

My point here is that team spirit diminishes the larger the team becomes which is another reason not to have a large team.

Competitive Spirit

Talking about team spirit I recalled that another way to get teams motivated is to encourage a bit of inter-team rivalry. I have actually only seen this work well once, where I was working with 12 to 16 recent university graduates. There was an interesting coincidence in that the group was almost exactly split between electrical/electronic engineering and software engineering graduates. I split the group into two teams based on their degree and tried to objectively compare the performance of each team, even displaying graphs of work completed. This worked well to motivate the teams, at least for a while.

However, I recommend caution in using this approach. First, you probably shouldn't do this if the teams need to work together in any significant manner - it does not encourage collaboration. Also you must keep it friendly and be entirely honest and open about it, otherwise it will be seen as manipulative.

Over-Specialization

Another problem with a large team is that team members become prone to Production Line Mentality. With many developers there is too much opportunity to specialize in one particular aspect of the team's responsibilities. (The same can happen with entire teams as I discuss next week.) This leads to developers who are unwilling, even unable, to perform any tasks outside their area of expertise.

This has many undesirable consequences. First, there may be times when the specialization is not required and the specialist has nothing to do. Conversely, if the specialist leaves or has too much to do then there is often nobody with the experience in the area who can take over or help.

But the worst problem, in my opinion, is that specialists tend to concentrate on the their own narrow area of focus, rather than being aware of, and striving to achieve, the goals of the team.

Don't get me wrong. It is often very useful to have developers with specialist knowledge. However, they should be willing and able to work in other areas as required (On the other hand you should not waste their talents unless there is a very good reason.)

Coordination

So Scrum helps to counter social loafing, but there is another reason for the Ringelmann Effect besides social loafing. For complex tasks, such as software development, coordination overhead becomes an even more significant problem.

Complexity Grows Exponentially
as Team Size Increases

There are two aspects to coordination. First, there are technical issues to do with building the software - these are not addressed by splitting into smaller teams because there will still be a need for inter-team communication. It might be useful if there is a logical separation of tasks based on feature areas of the software so that the new teams can concentrate on different areas, but this does not reduce the need for coordination, just contains it within the separate teams.

The other issue of coordination is getting everyone on the team to work together to knock off the sprint tasks. This is where having two small teams instead of one large one can reduce coordination effort.

Some developers try to take this argument to the extreme, arguing for a "team" size of one. It's true that the most efficient way to produce software may be just to have one good developer go at it full-time, without interruptions. However, there are disadvantages to having too small a team as I will discuss next.

Minimum Size

So much for the maximum size - what about the minimum?

By extrapolation of the arguments above you might conclude that a team size of one or two is best. It's true that a lot of problems, especially of coordination, disappear when a single developer (or even two) works on a project. There is actually some validity in this argument - for example, there are many great pieces of software that have been created by one or two people.

But I think the main motivation for this argument is that most developers have the personality type that prefers to work alone. Moreover, industry training and years of behavioral conditioning have reinforced this preference. I don't have enough space to elaborate here but this is important enough to warrant a future post.

You probably already concede that for large projects using one very small team is silly. It might be most efficient to have one developer take five years on a project but in that time priorities may have changed. Even if inefficient, it is likely preferable, for example, to assemble a team of eight and complete it in one year. There is also increased risk due to the single point of failure.

On the other hand, if a large project is tackled by many small teams, then this is effectively the same as having one large non-communicative team. Unless you are able to split the work into many independent parts then you must encourage communication and collaboration by building teams of at least four.

So I recommend not having a team size smaller than four or five. If absolutely necessary you could have a team of two developers (one of which is a part-time Scrum Master) plus a Product Owner (possibly part-time and possibly supplied by the client).

Splitting Teams

The obvious question now is if you have a large or growing team, how do you split it?

Once a team gets to a size of 8 then you should look at splitting the team into two. One way to do this with a team composed of one PO, one SM and 6 developers is to create two teams of 5 which share their PO and SM and have three developers each. If you already have teams with shared members (for example two teams of 7) then you can look at splitting into three teams of 5.

I have heard the argument that sharing a PO or SM between teams means more work for them. But working with two small teams should not really create much more work for the PO/SM than one large team. But it *will* save a great deal of time for the other team members if they do not have to attend long standups, planning meetings, etc (as well as having all the other advantages of small teams that I mentioned above).

Shared PO  

Having a shared PO between two teams should not result in more work than a PO with one big team.

However, I do not recommend having a PO shared by more than two or three teams. This would just be too confusing.

Another argument I have sometimes heard, for not splitting a team, is that there is no natural way to separate a large team as they are all doing similar work. It doesn't matter, split it anyway. Two teams can even work from the same product backlog, as long as they have a shared PO. Of course, it is probably best to have an equal mix of experience, familiarity with Scrum, etc on both new teams.

A crucial point when splitting is to resist creating "component" teams (teams that create components for other teams to use). Each new team should have all the skills to create new features. In other words each team should be capable of completing any (or a large proportion) of tasks from the product backlog. This is another good example of DIRE since it gets people on the same team to work together towards the same goal. Not only does it promote customer focus, but avoids problems like external dependencies, over-specialization (as above), etc as I will explain next week when we look at team composition.

Conclusion

There are several effects detrimental to large teams. Generally these effects are seen in teams of any size but start to really kick-in once a team reaches about seven or eight people. These include:

• increase in social loafing
• reduction in team spirit
• coordination overhead
• inefficiencies due to over-specialization

At the other extreme, having very small "teams" of one or two people may address these problems, but to do this the work must be divided into many different tasks for each of the "teams". This introduces other problems:

• some tasks are not easily divided
• some tasks may take longer than others
• increased coordination between teams
• single points of failure

Moreover, when you have many small teams working together on a large project you effectively have one large loosely-coupled team, whence the large team problems start to rear their ugly heads again.

It seems that, even with their drawbacks, teams of size five to eight are the best size. The good news is that team spirit and many Agile practices will minimize these drawbacks. In particular, the visibility provided by Scrum's daily standup greatly reduces social loafing.