Agile: Increasing team sizes
A fairly common trend on nearly every project I’ve worked on is that at some stage the client will ask for more people to be added to the team in order to 'improve' the velocity.
Some of the most common arguments against doing so are that it will initially slow down the team’s velocity as the new members learn the domain, code base and get to know the other members of the team.
My colleague Frank Trindade wrote a blog post about 18 months ago where he described his observations of the above happening on a team he’d been working on.
Frank also identifies the following consequence of increasing a team’s size which I think is perhaps even more important:
the decrease of communication levels brought by the addition of new nodes
The majority of teams that I’ve worked on have had 15 or less people but there have been a couple of exceptions including my current team.
We currently have somewhere around 25 people working in Pune and then perhaps another 10 in Chicago so it’s the biggest team that I’ve worked on. Having said that I do recognise that it’s quite small in size compared to some of the other projects in India.
The following are some of the consequences with respect to communication that I’ve noticed. These are applicable as we increase team size and also just generally when having larger teams.
Standup takes longer
This is somewhat inevitable since there are more people taking part. It’s therefore much easier to lose focus on what other people are saying.
We’ve managed to reduce the time to something more reasonable by not having any discussions in the stand up, instead taking them offline.
Other meetings are much more difficult to control with more people in and I think it requires quite a skilful facilitator to allow everyone to take part and still ensure that the meeting doesn’t overrun.
Technical decision consensus
Getting consensus on any technical approach is much more difficult than when there are just a few developers on the team.
Technical discussions seem to take way longer than I’m used to because we try to ensure that everyone gets to express their opinion.
There are also more people available to then disagree with that opinion which tends to mean that we go around in circles more frequently.
I’ve found that there are rarely more than 3 or 4 ways to solve any problem so a lot of the time people are expressing similar opinions in a slightly different way.
When the team gets this big I don’t think it makes sense to include everyone in all technical decisions. My current thinking is that having a group of 3 or 4 people involved in each one is more than enough.
Greater distance between team members
I think the optimal setup for a software team is to have all the team members working on a single table - this means we can have around 12 members per team.
That way everyone is within talking distance of each other and communication remains smooth.
Once we have more people than that we need another table which means that there are 2 rows of people in between people on the far side of each table.
In The Organisation and Architecture of Innovation the authors include the following diagram which I think is quite revealing:
Although the authors are talking about bigger distances, I think the amount of communication is less if we are separated even by this little amount of space.
You now need to take into account the number of people that you might be disrupting by shouting across the tables which was less of an issue before.
In summary
Adding people to a team may increase the velocity but it’s unlikely to lead to an improvement which is directly proportional to the number of people added.
From my experience it might make more sense to take a bit longer building the product or application rather than aiming at a strict time deadline with more people.
These are just surface observations - I’m sure others who have worked for longer in big teams would be able to point out a whole range of other consequences.
About the author
I'm currently working on short form content at ClickHouse. I publish short 5 minute videos showing how to solve data problems on YouTube @LearnDataWithMark. I previously worked on graph analytics at Neo4j, where I also co-authored the O'Reilly Graph Algorithms Book with Amy Hodler.