A lot of things about Scrum-based software development are set in stone, such as the roles involved and the kinds of meetings teams must hold. However, there are some things that can vary from project to project and company to company. One of those is team size. So, what factors influence the optimal team size, and how do you determine the right size for your project?
Optimal Team Size
The recommended size of the team is around seven members, give or take a couple depending on the nature of the project. According to the Scrum guidelines, teams of larger sizes require too much effort for communication. Teams of smaller sizes may not have sufficient qualifications or the capacity to complete work in a timely manner.
When forming a development team, it is important to consider the needs of the team, and not just random numbers. Here are some factors to consider:
- Cross functionality: The team should have the skill set to build the product.
- Availability: Ideally, each team member is working on just one project at a time.
- Stability: The members of the team spend a significant amount of time being a part of this team and must be reliable.
- Diversity of reasoning and experience: A wide array of ideas, backgrounds, beliefs, and life experiences might be useful to call into existence creativity and versatility of approaches.
- Psychological safety: The working environment within the team should be favorable so that the team members are able to share ideas.
- Equality in communication: Each team member should be able to speak their mind and be heard.
- Openness to new ideas and desire to learn.
It may be tempting to increase quality, capacity, and diversity of ideas by simply adding more people to the team. But be careful: Each member adds some productivity to the team, but each member also increases the communication load. Here, a well-known formula is applied: N (N – 1) / 2.
This formula shows how many interactions there will be within teams of various sizes. N refers to the number of people on the team. So, in a team of 5, there will be 10 interactions. This means 10 different combinations of communication among the team members. In a team of 7 members, there will be 21 interaction, and in a team of 9 members, there will be 36 interactions.
As you see, an increase in team size from 5 to 7 members almost doubles the communication load, which can have a negative impact on productivity after a certain point. When planning team size, be sure to take the communication load into account.
To avoid this pitfall, understaffing the team initially with the intent of growing it later may seem like a clever solution. But before you go that route, consider Brooks’s Law, an observation about software project management that warns, "Adding manpower to a late software project makes it later." That does not mean that team should not grow if necessary, but it’s important to remember that growth does not happen fast.
When new members are added, the team inevitably puts effort into bringing them up to speed, briefing them on the progress, goals, approaches, and nuances of the project. The team members invest their time into sharing knowledge and synching with the new arrival, showing how the work is organized. And all that time not spent developing the project means the work is slowed down, overall.
In short, there is no one “right” team size for a software development project. Instead, it’s up to each product owner and scrum master to carefully weigh the needs and complexity of the project versus the abilities and temperaments of their available developers and put together the right — and right sized — team for the job.
Key Roles on a Software Development Team
That said, every development team needs a certain combination of roles in order to succeed. In the classical understanding of Scrum, there are three basic roles:
Product Owner
The product owner is a “connecting link” between the development team and the client. The goal of the product owner is to guide the development team toward creating the most valuable product possible to achieve the client’s goals.
Scrum Master
The scrum master is the servant-leader of the team. The goal of the scrum master is to help the team maximize its effectiveness by removing impediments, driving progress, educating and motivating the team, and helping the product owner.
Development Team
The development team consists of the specialists who carry out the development activities on the product. This includes a handful of specific roles:
- Project manager: Oversees the big picture process of a project, including logistics, timeline, budgets, and risks. (The project manager and scrum master may be the same person or different people.)
- Business analyst: Works with the client to dig into the business processes and goals to define objectives and requirements for the new software to ensure the product is in alignment with the client’s vision.
- Software architect: While the business analyst approaches the project form a big-picture business perspective, the software architect approaches it from a software perspective, making high-level technical decisions, such as which technologies to use.
- Designers: UI and UX designers are responsible for the user experience of a project. These players leverage user interviews, market research, and design expertise to ensure end users—whether internal or external—have a great experience with the product.
- Developers: These are the team members who are actually writing the code—the engineers bringing the vision and design to life.
- Quality Assurance: Separate from the developers, these code experts are in charge of testing the software at every step of development, finding and fixing any bugs before they turn into major problems.
The number of developers on the team may vary by project, but according to the Scrum Guide, every development team should possess the following qualities and characteristics:
- Self-organizing. Nobody, including the scrum master and the product owner, can tell the team how to transform the product backlog into a working product.
- Multi-functional. Possess the necessary qualifications and experience to produce a working product.
- Accountable. The whole team — not any individual team member — is responsible for the work result.
Does putting together the right, and right-sized, team still seem like a daunting task? At Algothic, we’re obsessed with laying the perfect foundation for every client’s project, and we’ll guide you in understanding who you need on your team and how robust that team needs to be.
