Team sizes and communication pathways, wow what an eye opener.

Posted By on December 24, 2009 in Teams | 0 Comments

On a recent project of mine we set up a new team, I wanted to keep the team size within the scrum recommended team size of 5-7 plus or minus two but for various reasons the team was formed with 12 members all of whom were co-located.  I wasn’t entirely happy about this but thought OK its only three more than what scrum recommends so it should be OK.  At this stage I knew a little about communication pathways and team sizes but not a great deal.

So off we went and we started on our project after a short while I started to notice a few things.  Firstly the daily scrum started to take longer, they were more difficult to keep short and get concise answers to the three questions and I could start to see that sometimes people would zone out.  It was more difficult for me as scrum master to recognise things that were becoming bottlenecks or impediments.  Further into the project I started to notice 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 then added to the problems and communication was becoming an issue and people were becoming less aware of what others were doing and communication was suffering.  On top of this there were a lot of new members within the team so the team was also going through the forming, storming, norming stage that was adding to the problems.

We discussed these problems in our retrospective and we tried to split the team into two scrum teams for one sprint, but at the end of this felt after all it would be better to stay with the one larger team.  I also conducted a little research which really opened my eyes and allowed me to understand the theory behind the scrum recommended team size.

A chap called Fred Brookes devised 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 my smack between the eyes and I could start to understand some of the problems we were having.

So what did we do, well I could have mitigated the problem by removing people from the team but I choose not to do this, but 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 changed things about we also made our daily scrums more focused, but ultimately it was about communicating better within the team and being more focused with our communication.  Where as with a smaller team we didn’t need to focus too much on communication specifically as it was easier with less people, we found with a larger team that we had to work at our communication skills.

Now we are further down the line, our daily scrum rarely goes over 15 minutes, quite often they can be as little as 10, people don’t zone out, they are more focused and team members are much more aware of what other team members are doing, impediments are easier to recognise and communication is far more effective and we are all much happier about it although we still try to improve all the time.  I am sure as well that the team being more settled and familiar with each other has also helped having gone through the team forming stages.

In conclusion would I have a team size this big again, by choice no I wouldn’t but if I had too I would, would I go larger than 12 I very much doubt it. 

If you find yourself in this situation then by all means have a larger team but do it very much with your eyes wide open, be prepared for communication being more difficult, sub teams being created and then having to work hard to keep the information flowing through all of those communication pathways and most of all don’t underestimate the problems it can cause and the effort required to resolve them.

About Tom Reynolds

With over 25 years experience of working in IT, Tom prides himself on being a “passionate, self-driven, energetic Agile Coach, Trainer and Change Agent.” Tom has a proven track record delivering scalable enterprise software to major blue chip clients, as well as a proven ability to guide teams and organisations to help them to adapt to life in an Agile environment. Contact Tom

Leave a Reply

Your email address will not be published. Required fields are marked *