When initiation a project or some other activities same questions always arise: how the team should look like? Who should be included into a team? How many team members?
It is obvious that it is a critical decision on any development project is how to organize individuals into teams and success of the project might depend on it. Although team composition depends on a lot of things let’s investigate single one – number of team members.
So, how big the team should be? Are there any obvious advantages or disadvantages?
For everyone who is familiar with any agile methodology (SCRUM, XP and others) knows that the best size of the team is from 5 to 9. I tried to think of why these numbers are suggested, but not 11 or something else. According my experience of successful (and not only) projects I noticed that in the most cases problems were caused by not effective communication – not everyone understood requirements correctly, developers improperly coordinated their work, architectural decisions were not communicated to architects, management expectations were not clearly communicated, not enough transparency communicating risks and etc. As you might notice this list can grow very long. 🙂
p.s. of course communication is not the only thing to blame during failure, but it for sure appears among top reasons for the most cases.
So, if we agree with the assumption described above, there must be reasons for that.
There is less communication channels
It is always more difficult communicate any information to a larger group of people and it is obvious that each new team member introduces additional N-1 (where N is team size) new so called communication channels. It becomes obvious that while team increase it becomes more difficult to share information equally among team members and someone becomes left out. And if we assume that everybody communicates with everybody we get very simple formula to count number of potential communication channels. Communication channels = N*(N-1)/2
So, as you can see number of potential communication channels increases dramatically with each additional member, so we need always keep that in mind. Of course it is ideal case when everybody communicates with everybody (that’s why word “potential” is used), but even reducing this number by half, which looks more realistic, shows same dangerous tendency.
There is less „safety“. If we keep in mind that most people are lazy, we will notice that in larger teams people tend to show less effort since they believe there are others who will pick up task or take responsibility. But smaller teams are more open for communication and there are no places to hide and everyone just have to participate in everyday life. 🙂
There is more possibility for constructive work in a small team to occur, since it takes more time for bigger teams to get closer and set up good relations.
There is less coordination effort in small team. Coordination of tasks and responsibilities occurs much faster and easier in a smaller team. Every team member know who is doing what in most cases for small teams.
There is less specialization and results are more visible in small teams. Small teams are more universal comparing to big teams, and team members have better knowledge of the product they are working on. It is also very difficult to fake performance in small teams and person‘s contribution are more visible and meaningfull.
Conclusion
1. Keep in mind the size of the team when starting a project
2. Consider splitting existing teams
3. Do not take advantages of large team disadvantages (either company or project) 😉