So, here’s a question:
What’s the ideal size of a software team?
Most people, I don’t care how long they’ve studied the “art” of software development, will come up with a vague answer. “Six to 10” some might say. “About Eight.” “No more than 12.” "Five or Six, I guess.” These are pretty common answers. If pressed to come up with a rationale behind them, you might hear some rumbling about Mythical Man Months, but other than that, nobody really knows why they think that “Roughly Six” is a good number for team size.
Let me take a different approach. Forget, for a minute, about software development. Forget that this is a programming blog.
What’s the ideal size of a team of humans organized to complete a common objective?
Looking at the whole of human existence, wherever humans have to organize to achieve objectives, they always organize in groups of four or five. Four is a bit more common than five. Three is less common. Six is much less common.
Where does this happen?
The military: the smallest unit in the military is the fire team. four to five people.
Baseball: Yes, baseball teams have 25 players on a roster and nine players on the field at a time. However, a team can be divided into smaller units based on their objectives on the field. The top of a baseball lineup is four players, from leadoff to cleanup. The infield is four players whose goal is to prevent balls from leaving the infield. The outfield is three players who all shag fly balls.
Basketball: Each team has five players on the court at a time.
Soccer: Four defenders. four midfielders. four forwards. The set of four is so important for Soccer, that even though they are limited to 11 players on the field (10 position, one goalie), players will move from team to team so that whichever task is most important at the time (defense, offense), that task will always have at least four (and sometimes five) players working towards it.
Music: The vast majority of bands have four or five members. three and six are uncommon. Rarity roughly increases with size. Not just with modern music- the string quartet has long been one of the most popular musical group types. Even in large orchestras, they’re broken down into smaller pieces. Two groups of five violins in First and Second violins. Two groups of four cellos. Three Clarinets. Three Bassoons. Four or five trumpets.
Families: Most families these days have four or five members. Families in history had more members, but that is because they were organized around disparate objectives. Families aimed towards four men (3 boys and one father) to tend the field, and four women (3 girls and one mother) to tend the house. Since humans used to die easily and sex is a coin toss, this ideal team was rarely achieved. However, it was clearly the goal.
Why Does this Happen?
Ok, enough with the non-software comparisons. It should be pretty obvious that the ideal size of a group of humans organized around a single objective is four or five (with three occasionally being preferred). So why do software teams so often exceed this number?
I think the reason is that it is hard to define roles for software developers. In a band, you have very clearly defined roles- one drummer, one or two guitarists, one or two vocalists, and one bassist. Very rarely is this arrangement deviated from. Similar in sports- each player has a very defined role- 3rd baseman, point guard, center forward, sweeper. In families the role is defined by age.
What about roles in a software development team? Sometimes you’ll have a senior developer, but the role division usually doesn’t go any farther than that. I’m quite convinced at this point that each member in a software team needs a clearly defined role, and the size of the team will naturally work itself out.
The roles probably depend on the type of project. For a database-backed web application a good setup might be: Lead, Quality, UI, Data. With each member in that team you have a really good definition of what the role of the person is. If a certain need isn’t being met properly by the defined roles, then you add another person. The existing members naturally resist adding new members when there isn’t a role for them. Team size reaches automatic stasis.
Now, this is obviously pure conjecture at this point. I look forward to putting it in practice and watching how this approach actually shakes out. In the mean time, has anyone had experience with software development with tightly defined roles? How did this effect team size?