Four is The Perfect Team Size

The most successful teams that I have been have all been small. In fact, I've long believed that four was the perfect team size (three the minimum, and five the max). Of course, this was simply a gut instinct. It has been experience. I never thought to look up an research on the matter.

I was talking with my co-workers today and about fell over myself when one of the mentioned that the optiomal team size was three to five. I asked him why he felt this and he said, "Well, I found some research that says so." The look on my face must have been priceless. Eagerly, I asked him to give me the papers. He kindly told me to google "Optimal Team Size". I asked him what made him look it up and he replied, "I wanted to know the optimal group size for role playing games."

Here are the best articles that I found. Enjoy reading! All of it gave me lots of information to chew on.

The most telling quote was one by Steve McConnell. He not only advocates a small team, but relates what we've always known: code quality is dependent on the qaulity of the programmer. Methodology plays a little role in all of that. It's all about the people. Check it out:

According to Capers Jones's "Program Quality and Programmer Productivity" (IBM Technical Report TR 02.764, Jan. 1977), on small projects, construction errors make up about 75% of all errors found. Methodology has less predominance, and the biggest influence on program quality is the skill of the individual writing the program.

On typical larger projects, construction errors taper off to about 50% of total errors, while requirements and architecture errors make up the difference. Presumably, this is related to the fact that proportionately more time is spent in requirements development and architecture on large projects, so the opportunity for mistakes in those activities is proportionately larger.

I thought it was cool that there was research out there to prove my gut instincts.