“We need to accelerate the throughput for feature "z" – we’ll just add more developers to the Agile delivery team to achieve this!”
It seems so logical – good old-fashioned common-sense – add more people and they can clear through the work that much quicker. More developers will increase your sprint velocity …….
Not so fast – this reminds me of the maths problem posed by teacher Claire Longmoor to keep her students on their toes:
“An orchestra of 120 players takes 40 minutes to play Beethoven’s 9th Symphony. How long would it take for 60 players to play the symphony? Let P be number of players and T the time playing.”
This is a simple linear maths problem: reduction of people, means you need more time to make the final product – and the corollary would be that adding people would reduce the time needed. But we also know through other disciplines, from production planning to economics, on why additional contribution of inputs does not lead to a commensurate increase in output. It’s the law of diminishing returns, right?
Looking at software engineering as a discipline, in 1975 Fred Brooks arrived at the conclusion that adding ‘manpower’ very often exacerbated delays in already late projects in his book “The Mythical Man-Month: Essays on Software Engineering”. It offers an elegant insight as to why adding more people will rather increase your challenges and is unlikely to increase your team’s velocity. And like so many things, it comes down to the capacity for effective communication.
Startup founders revel in the closeness (and autonomy) of a small team, and will identify with the concept that as the team expands, communication becomes the greatest challenge in keeping all people in sync, despite the best of intentions. Communications is one of those things that does not benefit from scale. The same applies to Agile teams – as you include more members (read developers), additional lines of communication are required to keep the team in sync - the communication overhead.
For those that are mathematically inclined, there is a neat formula for sizing the communication overhead of the team: (n²-n)/2 where n is the size of the team. This is one of those challenges where a picture visually shows the challenge much more elegantly (Adam Konieska). As you add people to the team, there is an exponential effect on the communication channels, making it significantly more difficult to keep the team effective.
Is there an ideal Agile team size then? Most of the Agile literature shows that 7 +-2 developers is optimal - correlation: Brooks Law! Hit that communications productivity sweet spot – and optimise the teams throughput. Resist the anxiety – this is one of those times where less is more! Limit your Agile team sizes accordingly to meet your goals!