How to Optimize Agile Team Size for Efficiency and Effectiveness

You start a new software project, and you ask yourself about the best number of developers for an agile team?

Amdahl’s Law provides a simple model to get insights about the effectiveness of your team. It doesn’t matter if you are working with kanban or scrum because it works independent of any agile methodology. In the best case, you know more about how optimal a team could work together. It is also possible to compare different team sizes with different parameters so that there is more insight about team effectiveness.

To begin with my question: I have been in this situation multiple times so that I started to research on this topic. For example, I was asked how many developers with what kind of skill set would be needed for the project. Or I got the question about the impact of one additional developer. Therefore, I was looking for a more data-driven approach instead providing just a feeling.

In this blog article I want to explain how this approach could work, and I will explain how it can be used in your daily work. Before that, we must discuss the challenge when it comes to scaling an agile team.

The Hidden Pitfalls of Scaling Agile Teams

The agile manifesto most important claim is people over process. This claim should lead to more exchange of knowledge within the team. However, it comes with a price. Exchange of knowledge in larger teams costs more time than in smaller teams.

It is also important to acknowledge that agile teams have to do social interaction as well. Everyone has a need to talk about personal concerns and private issues to stay healthy. My impression is, it is sometimes ignored in this equation. However, it is super important for team hygiene, and it is a fact that this just happen in every team.

The figure below shows the amount of touchpoints between team members. It is increasing exponentially with the number of team members. To get a better understanding, here a real-world example: When four team members have a gathering, they do six handshakes. In case of ten people, they do 45 handshakes instead.

This figure is interesting because it illustrates that bigger team size does not necessarily mean higher throughput of work. It also means, more distraction and more effort on the essentials of agile methodology — people collaboration and exchange of domain knowledge. The consequence is that individual team members increase their cognitive load and the price is that their output will decrease.

My observation is that the spread of knowledge decreases constantly over time. An agile team must explicitly invest into knowledge transfer otherwise their performance slows down. I have experienced that this investment reduces the risk of failure within a project.

On short-term, a team can boost their productivity by individual task without much collaboration. However, long-term, it means that less knowledge is distributed in the team. This is a high risk for a project, especially when important team members die out on short notice.

It is worthy to mention that “work in progress” (WIP) limits are also crucial for success of an agile team. However, this article should focus on the size of a team and for that reason, it is just mentioned for completeness.

To summarize how to avoid common pitfalls:

• Agile teams must do knowledge exchange on regular bases
• Agile teams need stable and balanced team size
• Larger teams does not lead to faster and better output
• Without work in progress (WIP) limits, any setup of an agile team will be in trouble

As a next step, the questions arise how to monitor this knowledge exchange. I found an approach to monitor the amount of shared work as a substitute of monitoring knowledge exchange. This approach is shared in the section below.

Amdahl’s Law: The Key to Efficient Agile Team Scaling

Amdahl’s law is often used in parallel computing to predict theoretical speedup when using multiple processors. But it can be also used to estimate a speedup of an agile team. Amount of people is used instead of processors. Of course, such formula is a very simplified model.

Amdahl’s law has an assumption that each task has a fixed length. In the real world, it does not apply very often. In a very innovative project with a lot of uncertainty, this is rarely the case. Nevertheless, we can work well with this assumption as long as result is seen as a best case scenario. For example, if the potential speed-up is a factor of 1.5, it is very likely that this factor will be lower than 1.5.

The formula is defined as

$$ S = \frac{1}{(1 - s) + \frac{s}{w}} $$

where

• $S$ is the potential speed-up factor
• $w$ is the amount of worker ($w > 0$)
• $s$ is the amount of shared work between ($0 \le s \le 1$).

For example: If the team contains of four people ($w = 4$) and the amount of shared work is about $s = 0.4$, then the speed-up factor is $S = \frac{1}{(1 - 0.4) + \frac{0.4}{4}} \approx 1.43$.

Some weaknesses must be considered as well. One disadvantage is the assumption that every task has a fix size. Another issue is that any team dynamics is not reflected. I have observed that team’s performance is highly influenced by social relationships.

As a next step, an estimation of the amount of shared work is needed. In the next section, I suggest an approach which can be also extended to reduce the risk of unique skills in your team.

Strategies for Effective Agile Team Scaling

The problem is, how to know what kind of work my team is doing? The answer to that is pretty simple. In my case, I just asked my team!

So far I have two different approaches for that. My first approach is to schedule one-on-one meetings with the team members. In those one-on-one meetings, I take notes about their answer towards this question. I like this approach, especially when I must bootstrap a new team or when I take over an existing team as a manager but without knowing them well.

Another approach, which can be done additionally, is to do a survey. When the team knows my style of work, I prefer this variant because it is less time-consuming than individual conversations.

When I capture team’s daily routines, I make sure that these tasks are as broad as possible. That means that I do not just search for tasks that require specific technical skills of a special discipline. I am also considering tasks that might overlap with the role of a Product owner or the Scrum Master. For example my list of shared work contains things like creating database model, running database migration, fixing CI/CD pipeline and monitoring production. But moderating daily standup, writing bug ticket and verify bug are also part of this list.

In the second step, I ask the team which work item can be taken over by another person in the team. When I do a survey, I provide a multi-selection form.

In case of individual talks, I have the possibility to ask more in detail how to improve the situation if it turns out that no work can be distributed in this team. If the response is a no work can be shared, it is often a signal for me that the team is in trouble regarding collaboration.

The final step is to estimate amount of shared work. With this data, we can calculate the portion of shared work of Amdahl’s Law. Example: If 8 of 20 tasks were labeled as sharable task, the amount of shared work is $s = \frac{8}{20} = 0.4$.

Before I do this exercise, I usually do my own brainstorming because I learned that the result of my proposed survey could be very surprising. With my own evaluation upfront, I can check how robust they survey is.

It could be interesting to repeat a survey about shared work on regular bases. It is a simple monitoring of how well knowledge exchange is going within the agile team. I suggest set the frequency to minimum one quarter and to simplify the survey. Otherwise, people get tire, and the result is less resilient.

Summary

In this blog post, I have shown my approach to find the most effective and most efficient size of an agile team. Obviously, there are more things to consider. For example, it is necessary to observe closely team dynamics.

For beginning a project or when additional people are considered to join a team, I think this is a robust estimator of the impact to the team in a long-run. Another advantage is that a list of work items can be used to mitigate risk of a project.

How have you dealt with such question? How do you evaluate most effective and most efficient team size of an agile team? I would highly appreciate it if you drop a comment below.