How did the team size effect the team?
After a short while on the project, I started to notice a few things;
- the daily scrum started to take longer, and were difficult to keep short
- it became difficult to get concise answers to the three questions of the Scrum
- I began to notice that sometimes people would zone out
- and it was more difficult for me, as Scrum Master, to recognise forthcoming bottlenecks or impediments.
Further into the project I noticed that the scrum was in fact becoming two scrums. In essence the team had naturally divided itself into two teams (A common problem with larger teams). This just added to the problems; communication was becoming an issue too and people were becoming less aware of what others were doing. On top of this, there were a lot of new members within the team – so to add to the problems, the team was also going through the forming, storming, norming process.
We discussed these problems in our retrospective and we tried to split the team into two scrum teams for one sprint. However, in the end it was felt that after all it would be better to stay in one larger team. Alongside this, I conducted some research that really opened my eyes and allowed me to understand the theory behind the scrum recommended team size.
The communication pathway equation
Fred Brooks, in his book The Mythical Man Month, shared the following equation to calculate the number of communication pathways; it is [n * (n-1)]/2.
If you run this for a team size of 5 you will get [5 * (5-1)]/2 = 10 communication pathways, as team sizes increase you get:
[7 * (7-1)]/2 = 21 communication pathways ( a 110% increase in pathways compared to 5 team members)
[9 * (9-1)]/2 = 36 communication pathways ( a 72% increase in pathways compared to 7 team members)
[12 * (12-1)/2 = 66 communication pathways ( a 85% increase in pathways compared to 9 team members)
When I looked at this, the size of the communication problem hit me smack between the eyes and I could start to understand some of the problems we were having.
Solving the communication problem
We could have mitigated the problem by removing people from the team. But, I instead choose to get the team working more effectively and we discussed this as a specific point in a retrospective. We examined how we conducted sprint planning and made changes. Additionally, we made our daily scrums more focused. But, ultimately it was about communicating better within the team, and being more focused with our communication. Whereas for a smaller team a focus on communication specifically isn’t as necessary – as it is easier with less people – we found with a larger team that we had to work at our communication skills.
Further down the line, our daily scrum rarely went over 15 minutes – quite often they could be as little as 10. People didn’t zone out, and they were more focused. Additionally, team members were much more aware of what other team members were doing, impediments were easier to recognise and communication was far more effective. The team was much happier, although we still looked to improve all the time. I am sure as well, that the now completed forming process within the team also helped.
To conclude
If you find yourself in this situation then by all means have a larger team but do it with your eyes wide open, be prepared for communication to be difficult, sub-teams being created and then having to work hard to keep the information flowing through all of those communication pathways. But, most of all don’t underestimate the problems it can cause and the effort required to resolve them.
Author: Tom Reynolds
