Questions for an Enterprise Architect
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Is Five the Optimal Team Size?
Posted by Vikas Hazrati on Apr 14, 2009
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.
- This article is part of a featured topic series on Agile
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
RelatedVendorContent
18 agile and lean practices for effective software development governance
Case Study: IBM's Agile Transformation
A practical guide to choosing the right agile tools
agility@scale eKit: 10 Principles, Scaling Model, Metrics, Collaboration
Related Sponsor
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
Multiple Teams?
by
Udi Dahan
Posted
Re: Multiple Teams?
by
Vikas Hazrati
Posted
Re: Multiple Teams?
by
Ronald Miura
Posted
Re: Multiple Teams?
by
Vikas Hazrati
Posted
Re: Multiple Teams?
by
Udi Dahan
Posted
What is optimal?
by
Ian Williams
Posted
Re: What is optimal?
by
Vikas Hazrati
Posted
Re: What is optimal?
by
Udi Dahan
Posted
typo
by
nicolas dermine
Posted
Re: typo
by
Vikas Hazrati
Posted
Test coverage for reusing across team
by
Vinay Dayananda
Posted
Re: Test coverage for reusing across team
by
Vinay Dayananda
Posted
Define communication channels
by
Mattijas Larsson
Posted
Re: Define communication channels
by
Shane Hastie
Posted
Re: Define communication channels
by
Udi Dahan
Posted
Re: Define communication channels
by
Mattijas Larsson
Posted
And this is new?
by
Robert Barnes
Posted
hmm, it depends
by
Jason Little
Posted
-
Some projects are just too big for even the best 7 people on the planet to do.
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 -
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.
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. -
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 :) -
I think one of the underlying issues with the post is that it does not address what is optimal. Time to market is often a key factor - and more important than development cost. The cost of development might be relatively insignficant compared to the additional revenue or cost saving of the project. So running a team that in itself is less efficient might be irrelevant in the larger measure of cost/benefit of the project.
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. -
Hi,
I believe Jurgen's last name is spellt 'Appelo'.
cheers,
nico -
I agree with the main discussion in the article about not writing reusable code until there is a need. But there is an option of having(managing) reusable code across project(only when there is a probability of code redundency or functional redundency) by having test coverage. So whenever someone in the project uses code used as a utility, he has to write a test for that usage so that if someone changes the reused code(utility), then the test fails indicating that there is a break of a functionality that is using the utility.
-
sorry this belongs to some other discussion.
-
"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."
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 -
My understanding of the growth of communications channels is it is the number of POSSIBLE communications links between nodes (people on the team).
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 -
Matt,
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. -
hmm nice catch ;) but I guess inter team communication would be limited to something like a Scrum of Scrums which might not be that bad.
What are your recommendations and observations on the teams on which you have worked? -
Good to see some updated statistics. But the really interesting question is, "Why do we persist with these large teams". Nothing in this article was a surprise to me - there have been similar papers and the results of team size have been well documented since I started in the industry - on System 360 with PL/I in 1968! Brook's law - adding more people to a late software project makes it later" was published in 1974, and demonstrations such as Harlan Mill's "Chief Programmer Team" in the early 70's should have nailed it. Yet 30 or 40 years later we continue to employ large teams and Waterfall methodology, in spite of the massive evidence that this is the worst way to develop software. Why? Are managers especially slow learners? Or is the reason more subtle.
Robert Barnes -
Thanks Nicolas, corrected the typo.
-
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. -
It depends on the team structures I described above.
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. -
For larger projects, I would recommend against self-organization unless the team has already worked together enough, and on those kinds of projects, to know what will and won't work.
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". -
Udi,
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. -
In an ideal world where this team would only be working on one project at a time, I would agree that a team size of 5 (not including the scrummaster and PO) is a good size. We have a small team of 4 developers and it's great for dedicated projects and focused work but throw in supporting the existing application and it gets very difficult very quickly. It can be extremely difficult to get an actual work done without constant sprint interruptions when your team can't focus on the project.
18 comments
Watch Thread Reply