Building a software team is a bit like cooking a meal. You can do it in a simple way, or you can do it in a complex way. Think of it a bit like roasting a shoulder of lamb. You could go the simple route, and season it with rosemary, or you could go the complex route and season it with rosemary, thyme, garlic, lemon, lime, sugar, ginger, tarragon, paprika, balsamic glaze, mint and chocolate. It might be the most amazing combination of flavours, or it could be a total disaster. Getting all of those flavours to blend together well is going to be challenging to say the least
Building a team is very similar. Instead of flavours you are merging personality traits, working habits and skills. The more people you add the harder it becomes to find a combination that works well. More people mean more ideas, more creativity, more conflicts and more messy human emotions. Over the past few decades a lot has been written on the subject of how big a team should be, and why bigger teams are not always a good idea. Amazon CEO Jeff Bezos famously likes two pizza teams, teams that can be fed with just two pizzas, and the classic book The Mythical Man Month gave us the now famous saying “adding more people to a late project just makes it later”. Scrum talks about the right scrum team size being 5-7 people at most. Since adding more people makes things too complex to be functional, stick with smaller teams.
I’d say that this is a pretty accepted conclusion in the world of software and programming, which is why I wish I could say I was surprised when I overheard someone recently talking about a project in their company:
You won’t believe how complex this project is. We have over 400 developers working on it, and that’s still not helping.
Four hundred people! 400! With that number of people I’m struggling to believe there is any chance the project won’t be beset by complexity. If you don’t believe me try and get 400 people to do something simple, let alone something as complex as a software project. What really makes me sad though is that this isn’t an isolated event. I’ve hard many stories of such large teams working on a project. The myth that more people means more speed is still very much alive and well. There is an idea ingrained in our thinking that says if some developers are good, then more developers must be better. And we all want to be better, so lets get more developers, because it’s, well, better!
Of course, no matter how hard you try, a team of 400 people is not a small team. It’s not a team you can feed with two pizzas. It’s too big to be a team that has any chance of working well together. So the typical response to being better by adding more developers is to create 10, 20, 30 40 or even 50 teams, all working all on the same project. Although the size of any one team is now small enough to avoid complexity, you end up having exactly the same problems between the teams. There are just too many teams for them to work well together.
So how do you deal with this? A number of agile development methodologies (like SAFe) teach how to scale the number of teams, I’m not convinced. The error is in the assuming that more developers is better when in fact it’s worse.
A few years ago I was working on a project that demonstrated this perfectly. A software component was being extended by a team of 15 people. The team had a list of critical features they needed to add, and the first one was expected to take 2-3 months. This was too long and so we went looking for alternative solutions. There was another, smaller team available. This time of just 2 people. They guessed how long it would take to build a system that copied all the existing feature and added all the needed features. Their guess was 3 months. In that time they thought they could reproduce all the work already done, and outpace the existing team in adding new features. They got the green light to go ahead, and in just 2 months had overtaken the existing team.
You can argue that the new team had some unfair advantages. You could say they were better developers, or that they had the freedom of working on a new code base rather than a legacy one. However neither of these arguments really explain why they were so much faster. That can only be explained by the way they were much more clearly aligned on what they were doing, and how they were not getting in each others way.
So what is the right scrum team size? As small as you can manage while having all the needed skills within the team.