Competitive programming
That’s the thing that you and your human resources specialists should avoid at any costs. Creating competitive atmosphere and antagonizing people is one of the worst things that you can actually do to your team. The bigger group of people, the easier is to split them, and splitting them means less performance and more office drama. No one is saying that a little bit of competitive spirit could do any harm – encourage your employees to be the best they are possibly can be. But there is a thin line between positive competitive and hostile. The second one should be avoided at any cost.
The best and the easiest way to achieve this is good motivation system. Folks like to be awarded for good things that they’ve made. Maybe this week sprint went without any bumps on the road? Someone has found some major bug on their own and fixed it to save team a work? That seems like things that should me noticed and awarded.
Big challenges of big teams
The single biggest challenge is the influence of each team member. What I mean is that when you have a team of twenty developers and one gets sick you just reassign their work to another. Your project is not in any sort of danger and all will be delivered on time. When you only have four devs inhouse, that’s a quoter of your team down, you can reassign that work but prolong the project and interrupt flow.
Similarly I've seen projects derailed by ego and gate keepers. A gate keeper is someone who could probably be easily replaced from a skills perspective but has a highly specialized knowledge of a particular aspect of your project. This is the kind of person you could replace with kind of good script file. Any attempt for others to enter into their domain is blocked with excuses and delays. Prevent these people, if one exists go around them, train up a replacement and excise them as soon as possible.
Maybe smaller is better?
In general I would say small teams are an advantage, comradery, communication, efficiency. These teams are best for taking existing codebases and customizing with project specific code (using frameworks like ruby on rails or open source projects).
The disadvantages of a large team, particularly communication overhead, is highly dependent on project organization. Modern design utilizing component/aspect/service oriented architecture, integration teams and iterative development (building towards MVPs as Eugene recommended) neutralize the problems of large teams. One of the most known examples is the whole process of developing Windows 7. Before working on the project development team was huge but highly compartmentalized into small teams. I believe Microsoft had too many managers to developers but it worked, they delivered a massive project but it was of high quality and met user requirements.
