When a team practicing agile software development is growing, one common question that arises is the optimal size for a development team. While some argue that smaller teams are more effective, others believe that larger teams can be equally successful if managed properly. In this article, we will explore the advantages and disadvantages we encountered with our agile teams on the larger side (7-10+ people)
One advantage of larger agile teams is that the skill sets in a team are more diverse. With a larger team, you can have specialists in different areas and technologies, unite their knowledge at zero cost. This can lead to more efficient problem-solving and a higher-quality product, as the sum of the entire skill set of the large team is available at all times.
Another advantage is that larger teams can work on multiple (connected) features simultaneously, which can increase the speed of development. This is particularly useful for complex parallel features that each require the input of multiple overlapping team members.
However, there obviously are disadvantages to having a large agile team. One major disadvantage is that communication becomes more difficult as the team size increases. With more people, it can be challenging to keep everyone on the same page and ensure that everyone’s ideas are heard, which leads to to internal confusion, people feeling overheard or not responsible for the outcome and delays in the development process.
Another disadvantage is that larger teams can be more difficult to manage. It can be challenging to coordinate the activities of a large group of people and ensure that everyone is able to work towards a common goal. This can lead to wasted time of members having a hard time applying their particular skill set in a given sprint and again a general lack of accountability, resulting in a general decline of productivity.
While larger agile teams have the potential to be highly effective, in my experience they rarely are. They also present challenges in terms of communication and management, which simply are practically inexistent in smaller teams.
Generally speaking, the ideal team size will depend on the team members, their skill set and level of seniority, the specific project and the processes applied.
From our experience in the last 5 years, with our development process which is strongly focussed on collaboration and knowledge distribution, we found the optimal team size to be between 4 and 6 team members. Smaller teams struggle with the process. Pair programming and reviews of PRs suffer disproportionately from absent team members due to holidays, sick days or even team members with part time contracts. Larger teams suffer from the disadvantages regarding organization, communication and accountability mentioned above, each of them exponentially increasing, especially when moving into the double digits.
The most important thing that we learned during the last few years is to remain flexible and open to change also at the fundamental level of team membership and organization. Only during the last year we split our development team three times, merged teams twice and each time resulted in predominantly positive feedback. Members both subjectively felt more productive, and objectively measuring output and defect rate, we produced better software in the same time, after an initial dip due to an adaptation phase.
A second, maybe not so obvious outcome may be that by splitting a team, the area of responsibility gets narrower. In a product as vast as NetEye it is literally impossible to be an expert in all components. In this regard splitting not only the team, but also the area of competence of the team in two or more non-overlapping parts, lead to people feeling less overwhelmed and gaining more expert domain knowledge of “their” part of the product, which – again – results in higher productivity and better solutions.
Benjamin Gröber
Author
