What is the optimal size of a software development team?

Question

What is the optimal size of a software development team? or Does size really matter?

It seems to be subjective, but my intention is to know 'What are the metrics' which decides team size?.

Answer 1

Research on team sizes and dynamics is a pretty well-developed field -- start with reading up about Dunbar's Number, e.g. at http://www.lifewithalacrity.com/2004/03/the_dunbar_numb.html .

Answer 2

Read The Mythical Man-Month.

Answer 3

According to me, 20 is the optimum size for most of the big enterprise level applications.

Deadlines & complexity of the application, according to me can be major factors in deciding the size of a team!

Answer 4

I depends on the size of the project, the type of project management used and the alignment of the moon on the 3rd Tuesday of every month.

Answer 5

I heard the productivity of a team grows equivalently to the square root of the members count. So, two people give you a productivity factor of 1.4, ten people give you a factor of 3.2 (and not ten). I suppose management and coordination within a team eat too much processing time.

P.S. "It's not the size, it's how you use it." (C) Austin Powers movie

Answer 6

I think exploring "the metrics that drive team size" will put you at a disadvantage. Team's are a rare and incredibly hard thing to create (e.g. read Peopleware, Software for Your Head and Art of Agile). Recently Jurgen has posted that the optimal team size is 5, but it is less than scientific.

I think you should be spending your time and brain power on what makes the group you have into a team and not so much on metrics. Metrics have their place, but focus should be placed on areas that have the most impact (think ROI).

Answer 7

The optimal size of a software development team is the one which produces the best results for your project and organizational culture. The more effective your ability to keep team members informed and in touch with each other about what's going on, and the easier it is for them to get the resources they need, the less overhead each person generates.

That's why the on-board shuttle group can get away with 22 people and perform incredible feats of human engineering, while most companies start to have communications trouble with groups larger than about five or so.

Answer 8

Well, first off, in most Agile teams, the golden number is said to be between 5 and nine members. Again, these are heuristics. In scrum, teams larger than 10, are considered to be a bit unmanageable, as the daily meeting tends to become more than the time boxed 15 minutes. Moreover, large teams tend to mutate into smaller informal teams. You may consider this to be "nature's" way of correcting itself.

As for how to decide what is the right size for you, I'd suggest you consider the following scenario, and see if it feels right for you:

1. Your teams are agile, and feature driven, as opposed to component-oriented teams (i.e. GUI team, service team, DB team, etc.)
2. Your team should be capable of completing entire features on their own (self sufficient). This means your team should have at least one person capable of completing every task required to get the feature done.
3. Ideally, besides your specialist (i.e. GUI designer, architect, DBA), you should have at least one other person qualified to do the job - even if not as well as the specialist.
4. Ideally, in my opinion, at any given moment the entire team should be working together on the top-priority feature. This means that you have enough team members to work on an average sized feature, no more, no less.
5. Consider whether or not your team is suited for Pair-Programming. This will greatly increase your internal quality and productivity.

Let's assume that the most common feature your team will have to includes the following tasks (for example):

• 1 story-point worth of GUI task
• 2-6 SP of BL tasks
• 1-2 DB tasks
• 1 SP for manual tests
• 1-2 SP of automating functional tests

You're unlikely to have more than 1 DBA and 1 QA tester on your team. In order to fully utilize your team members in their area of specialty, you'd want the following make: 1 GUI expert, 2-3 BL developers, 1 tester, and 1 DBA, for a total of 5-6 members.

This make will also set a cap on the amount of story-points your team can crank out in an iteration. If your company needs more, I'd suggest adding 1-2 developers, encouraging pair-programming and increasing productivity.

If you need to make a lot more than that, you may wish to build a second and third team of the same size.

Hope this helps, Assaf.

Answer 9

The smallest team capable of getting the job done in the time available. In my ideal project, there would be just one - me! That way everything is done consistently and well IMHO ;-) Of course, that is a luxury we don't always have.

The more people you add to a team, the more communication, meetings, management, standards-checking and peer reviewing are required to achieve the objective. The productivity per team member decreases as the team grows. That's what the Mythical Man Month is all about.

Answer 10

0

Most of the time its cheaper to buy than build. If you do your research you might be lucky and find a solution that is cheaper to buy than build.

Answer 11

I think it's somewhere between 1.4 and 1.7 people.