How big is BIG? (development Team)

Question

I'm interested in what constitutes a big team and what ratio of developers, Architects, Testers, Managers etc.

Does anyone have any figures for team sizes on well known projects like windows or SQL Server for instance?

Answer 1

You may find the following article of interest.

http://www.qsm.com/process_01.html

But, to answer your question is difficult without understanding the process you are using. For example, the waterfall model will call for a larger team than the XP agile method.

I have been on a team with 13 members but that tends to break down into smaller teams each working on certain tasks. If the team is large enough that politics comes into play then it is too large. You may have a large number of people that can work well together, all focused on finishing the project, and not looking out for their own self-interests, and the large number may not cause a problem, but, that having those types of people are unlikely.

Anything larger than 9 people is probably too large as it will break up into smaller teams, so, if a team is large enough that it will break up into small teams, then just have the small teams be the team size, and realize that what you started with was too large.

Answer 2

Teams should be as big as necessary for the project at hand, when I read "big" I get the impression you are looking for "how much is too big". I worked for projects with hundreds of developers for a phone switch development but they were always allocated into teams of 5 or 6 with a team leader each - hardware, software, documentation, testing & QA, installation, training and so forth. For the teams themselves anything more than 5 becomes hard to manage.

Answer 3

If you ask Jeff Bezos, you optimally want a "two-pizza team": If you can't feed a team with two pizzas, it's too large. That limits you to five to seven people, depending on their appetites.

Answer 4

It depends on what you mean by "team". I worked for a large US bank on a .NET "team" of more than 60 developers, plus architects, managers, and QA.

My current "team" is roughly 12 developers of varying levels, a handful of QA, and one solutions architect.

But in both situations, I never work with more than ~3 people at a time. Usually only 1 or 2. So in that sense, we are broken into teams of 2-4 depending on the tasks at hand. For a single project, that seems to be about the limit.

Answer 5

I dream of the day when all the different stages of development are part of a single team, instead of having team "conveniently" broken by job description. This organizational view tends to lean processes heavily towards the dreadful waterfall (god I hate this process!).

But to answer your question, I think the team should not exceed 10ish people with a few more gravitating around it without being full time part of it (training, marketing, clients, implementation, support). In all 80% - 20% devs vs management/QA should tend towards good productivity. If your architects can also dig in the code a bit all the better. Frequent design reviews with the whole team should also allow everyone to have good oversight over the whole project and not just their pile of bananas.

Here is an example of team break down that had worked really good for me :

• 2 Sr devs that have a good grasp on architecture
• 4 Jr devs that can handle the grunt work
• 1 code ninja that can do some technological exploration (while also participating in the whole)
• 1 project manager, team lead, interface to the outside world to bring in the 2 pizzas
• 1 noisy QA guy to poke around the application, write acceptance tests etc. The noisy part was for the WTF/day metric. The quieter he was the better we did our job and the less ibuprofen we consumed.

Around this gravitated some clients on whom we did frequent usability testing.

ha the good old days !!!

Answer 6

Where I work uses Scrum and to have a 15 minute effective Standup, there can't be more than 6 or 7 developers along with a few other managers each taking about 1.5 minutes to fit within the time frame. The other managers include some end users of our systems, quality assurance, and the team lead to give a few examples.

I think if the team was much bigger, the work would have to be more finely defined as I have a little trouble already trying to keep in my head all the stuff of the current project.

Answer 7

What I've typically seen is a ratio of 2 developers for every 1 architect (analyst) and 1 QA (tester) - so 25% architect, 50% developers, 25% QA - depending on how the team is broken up

• functional - you would have 1 manager per area for every 6-9 people - so 1 for architects, 1 for developers 1 for QA min.
• project - you have 1 manager heading up every project, if the project exceeds 9 people you sub-divide with team leads (part manager/part architect or developer or tester)

A team usually changes over time - up front you'll have more Architects and then move to more developers and near end of project life more testers come on board.

I've managed teams from 6 up to 100 and the ratio is usually about the same.