Is Five the Optimal Team Size?
- Share
-
- |
Read later
My Reading List
There have been a lot of discussions and debates over the optimal team size for maximum productivity. While most Agilists agree that smaller teams are more functional and productive as compared to larger teams however, defining the optimal team size is still a challenge.
Jeff Sutherland shared some statistics in favor of smaller teams where, the cost per function point of a team of size 7 was $566 and that of a team of size 14 was $2970. On similar lines, in response to a post on InfoQ, about team growth and productivity, Mishkin Berteig commented that
Imagine that you have just been "given" a software development group consisting of 100 developers. Now imagine that you are given a really important project to work on. Which would be better:
a) Get all 100 people working on the project (with good project management, leadership etc.), or...
b) Find the 7 strongest people in the group who are willing to work on the project (in other words, the seven strongest people that are actually interested in the project) and get them working on the project, fire the rest of them, and spend the savings on giving the 7 people the absolute best tools and environment they need and want, and spending the rest to make them happy/comfortable.
Personally, despite the severity of scenario b), I would definitely bet on it and not on scenario a).
Jurgen Appelo suggested that the optimal team size might just be 5. Five is the common number based on various studies around communication and team structures.
- Scrum recommends the team size to be 7 plus/minus 2. Hence the team can vary between 5 and 9
- According to Congnitive Edge, the human brain has co-evolved with social conditions and there is a natural limit on the number of social relationships a person can maintain. The study could easily be labeled as the rule of 5,15 and 150. 5 is linked to the natural limits of short term memory, 15 is the natural level of deep trust and 150 is the number of identities that a person can maintain in his head.
- Another study related to the Parkinson’s Law, suggested that any team size below 20 can work except 8. Above 20 there is a natural digression into subgroups and no consensus can be formed. With 8, people usually find themselves in deadlock situations over decisions.
Further adding suppoprt for a team of 5 with a comment on the Parkinson’s Law, PMHut suggested that
The more team members you have, the more communication channels you will have, and this thing goes exponentially. If you have 3 team members, then you will have 4 communication channels, if you have 4 then you have 9. I think the formula is m-1^2.
In my opinion, a small team of 4 or 5 is ideal.
Hence, given the above facts and studies a team size of 5 seems to satisfy all the conditions related to Scrum recommendations, Parkinson’s Law, natural limit of short term memory and favorable communication channels.
However, inspite of strong evidence in favor of a team of 5, Jurgen cautioned that instead of going with a recommendation on team size, the teams should first try to self organize and gradually arrive at an optimal team size. According to him,
When you need to structure a big project, don’t impose a “preferred” team size on people just because it is written in a book. Try to allow self-organization to do its job and let the people (within their real environment) figure out what their optimum is. Do they want to cut a team of seven into two teams of three and four? Sure, why not? Are they merging two teams into one big team of fifteen? Fine, let them see if that works.
Related Sponsor
Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.
Multiple Teams?
by
Udi Dahan
At that point, when you need to have more people, and multiple teams, this kind of guidance isn't particularly helpful.
There also isn't any discussion about the team makeup - broken down by skill (dev team, test team, dba team, etc) or cross-functional (each team with members from all disciplines - dev, test, db, etc).
There's also the issue of organizational dynamics to be taken into account, legacy to be maintained, etc that will impact the above. In green-field projects cross-functional teams tend to work best and minimize risk, yet brown-field in matrixed organization can bring constraints forcing skill-based teams.
As Conway's law states, the structure of the system will reflect the structure of the organization which built it. The corollary of that law is that to effectively change the architecture of a system, the organizational structure must be changed as well. This requires people to act as change agents - risky business for people inside certain organizations; external consultants often have better success not being perceived as a political threat.
As an architectural consultant I've seen the full gamut - there really is no silver bullet, not even 5 plus-minus 2.
Udi Dahan - The Software Simplist
Re: Multiple Teams?
by
Vikas Hazrati
This gets us to the problem of allocating the specialized functions like DBA etc that you talk about. There are several approaches that work for generalized-specialized functions. The one that we use is that the DBAs do not belong to any team but their services are used by multiple Scrum teams as and when required.
For the more traditional roles there is a suggested mapping defined here.
Again, there isn't a silver bullet. It would depend a lot on the people, environment both internal and external to the organization etc etc, to see what works for them.
Re: Multiple Teams?
by
Ronald Miura
I would agree with you Udi, you would need multiple teams for larger projects. I think Jurgen's proposal is to have a huge team split up into smaller teams of 5 people each.
And then, the 'maximum-maximum' number ends up on 5 teams of 5 people each? Inter-team communication suffers from the same constraints of individual communication :)
What is optimal?
by
Ian Williams
Imagine a project which saves a company $100,000 per month in operational costs. Delivering it 6 months earlier saves the company $600,000. Lets say developers cost this company $1000 per day. That means the project can deliver exactly the same result at 500 extra man days effort (that's additional, inefficient, effort) if they bring it in 6 months earlier and still be ahead of the game.
So although smaller teams within themselves might be more efficient - and hence companies ought to prefer them - they might not deliver results as quickly and the benefits of early delivery often outweigh the additional cost of doing so.
Test coverage for reusing across team
by
Vinay Dayananda
Re: Test coverage for reusing across team
by
Vinay Dayananda
Define communication channels
by
Mattijas Larsson
Can someone explain what "one communication channel" is here? I first thought it was the number of possible 1-to-1 communications possible in the team. That would equal the number of possible pairs in the team, which is not growing exponentially. A team of 3 has 3 channels, a team of 4 has 6 channels and so on, using the binomial coefficient.
Can some one clarify please.
Cheers,
Matt
Re: Define communication channels
by
Shane Hastie
2 nodes (people)A & B have one possible communication link: A-B
3 nodes A B C have 3 links: A-B B-C A-C
4 nodes A B C D have 6 links: A-B A-C A-D B-D B-C C-D
etc
I hope this helps ...
Shane
Re: Define communication channels
by
Udi Dahan
You can safely ignore the math. Like statistics, it is used to prove a foregone conclusion. People can perform many-to-many communication: overheard conversations, meetings, all that.
Re: Multiple Teams?
by
Vikas Hazrati
What are your recommendations and observations on the teams on which you have worked?
And this is new?
by
Robert Barnes
Robert Barnes
Re: What is optimal?
by
Vikas Hazrati
I think one of the underlying issues with the post is that it does not address what is optimal.
True, and that is what the conclusion is. Though 5 seems like a suitable number but the teams should try to self organize and arrive at an optimal number which works for them.
Jurgen cautioned that instead of going with a recommendation on team size, the teams should first try to self organize and gradually arrive at an optimal team size.
Re: Multiple Teams?
by
Udi Dahan
Skill based teams require huge amounts of communication as the software components they work on are necessarily tightly coupled (UI, BL, DAL, DB).
Cross-functional teams working on autonomous business services (SOA) require much (MUCH) less inter-team communication.
Re: What is optimal?
by
Udi Dahan
I've seen teams "self organize" in ways unsuitable to the project they're working on. All sorts of problems start popping up but the team doesn't necessarily have the experience (or perspective) to attribute those problems to their self-organization, so persists - and often fails as a result.
I would strongly recommend getting somebody in with experience in the project scale/style to avoid these kinds of costly self-organizing mistakes. As attributed above in Conway's law, both team structure/methodology and software architecture need to be put into alignment - something ignored by many "agile consultants".
Re: Define communication channels
by
Mattijas Larsson
yes, I agree that the actual maths can be ignored.
When I see a formula presented I want to understand it and see how I can make use of it. And there is a difference to claim that communication grows exponentially or by its dimensions.
hmm, it depends
by
Jason Little
Educational Content
Writing Usable APIs in Practice
Giovanni Asproni May 19, 2013
Concurrency in Clojure
Stuart Halloway May 17, 2013
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think