Etiqueta: development

Enlarge

Much has been said about the Scrum team size or Agile team size, almost every client, boss, and collaborator with whom I have worked asks this question at some point: how many people do we include in the teams? The Scrum Guide sheds very little light on this, suggesting 10 or fewer members per team in its latest update, but giving us no context or reasons for these numbers.

The Scrum Team Size is More Than a Number

The truth is that there is no universally correct number of members to ensure optimal performance in a team, but what we know is that a Scrum team must consider certain factors that should include, beyond numbers:

• Cross-Functional team. Sufficient skills and capabilities to build the product,
• Dedicated team members. Dedicated members to one, and only one, team,
• Consistent membership. Stable and long-term membership within the team^[1],
• Diversity of thought. A reasonable wide range of attitudes, beliefs, genders, and thinking patterns^[2].

Now, the above points already represent a challenge for some organizations, but at least they enjoy an important consensus, however, they are not the only ones. Once the team is formed, there are other important factors that high-performance teams must address, among others:

• Psychological safety. A safe environment to share ideas and take risks^[3].
• Equal communication. The most expressive member should not communicate more than twice as much information as the quietest^[4].
• An open mind and willingness to learn^[5].
• Shared vision. Everyone knows and agrees on objectives^[6].
• Clear roles. Everyone knows their responsibilities and the expectations of their work^[7].
• External advice (coaching). In Scrum, this is done by the Scrum Master^[8].

And what does all this have to do with the size of the teams? Well, these factors don’t live isolated in a vacuum and just because I say so, so let’s explore the evidence so that together we discover what matters most to your team. After all, there is no universal answer 🙂

Many Numbers Everywhere

When we talk about the size of the teams within various organizations, the topic seems much more controversial and narrow to say the least. In the worst cases, staffing leaders respond by building teams guided by assumptions and even based on the burden caused by unrealistic dates and budgets and inadequate time horizons, thus harming the performance of teams and the organization itself in the medium and long term.

In the early days of Agile, the XP and Scrum texts suggested that the optimal size of members was 7 ± 2, applying George A. Miller’s number, later it was adjusted to 6 ± 3, today the suggested number is 10 or less according to the Scrum Guide.

The original support for the position of seven people, plus or minus two (7±2), comes from a well-known psychology study by research psychologist George A. Miller published in the 1950s, where according to the results of this study, there are limits on the amount of information we can process and retain in our heads.

More recently in 2010, Nelson Cowan claimed that Miller was too ambitious and that the ideal limit was only four and not seven^[9].

Also, Ikujiro Nonaka and Hirotaka Takeuchi were formulating the ideal team size after conducting research and creating new products at technology companies such as Fuji-Xerox, Canon, Honda, Epson, Brother, 3M, and Hewlett-Packard^[10].

Many others cite historical examples dating back to the Roman army, which used small military units of around 8 people. Others watch bonobos, one of the closest genetic relatives to humans, often splitting into groups of 6-7 to forage for a day. Both conveniently support the number 7±2, but since neither example is about teams doing knowledge work, the relevance of this to agility is limited.

As you can see, the topic has been discussed for some time and can be somewhat confusing, but thanks to this we have some clues, but it is worth having more sources to help us support our decision.

What Happens to Relationships When Teams Grow?

Enlarge

Within a team, each individual will have a connection with another individual, thereby creating a unique relationship; the bigger the team, the more the relationships. The equation that describes this is N(N-1)/2; but what does this mean? and how can it help us? To find out, let’s remember math problems from school and turn it into something we can use in real life.

The above equation tells us how many different relationships will exist within a team of a certain size, where N = the number of people in the team. So, in the first example graph of a team of 5 people, where N=5 we have 10 relationships: 10 different combinations of team members who are related to other members of the same team.

In the second example, where N=7, you have 21 relationships, and where N=9 in the third graph you have 36 relationships. Each pair of people represents a relationship, and that relationship defines how they collaborate. High-performance teams, by their nature, must have strong relationships between each of the team members in order to collaborate effectively.

Knowing this is important for you and your team because it’s true that each new person adds some individual productivity to the team, but it also increases communication overhead in the form of an exponentially growing number of relationships. To grow a team from 5 to 7 people, you need to more than double the number of relationships. To go from 7 to 9, it doesn’t quite double, but the jump is still big.

How expensive is it to maintain these relationships? Anecdotally, after studying the interactions of the members of several of my teams, I can say that in teams of 7 or 8 people, each day more than 90 minutes per person are spent interacting with other team members^[11]. This excludes time spent on techniques like pair programming. Part of the interaction is talking about work, but she also spends time socializing. This is good and important because it is the combination of work and socializing that builds resilience and the ability of a team to handle challenges effectively.

A general rule of thumb suggests that people typically have 3½ to 5 hours of productive time at work each day. As a team grows, we lose productivity or, more often, begin to withdraw socially rather than sacrifice productive time to interact with our peers because communication costs for each team member are becoming too high. We need strong relationships to become a high-performing team, but as the size of the group grows, we begin to avoid the interactions that build those relationships.

Therefore, the number of relationships between team members and the time investment they require should be a factor when choosing team size because it will influence productivity.

More People Make Lighter Work…But Only to a Point

What everyone wants to believe is if we go from 1 person to 2 people, or from 2 people to 4 people, we will get double the work done, even top managers of transnational organizations have raised this with me. But even so, we intuitively know that this is not true, but why?

In 1967, Amdahl’s Law was presented for the first time, which for those who are not systems or electronics engineers, tries to estimate how much speed gain can be obtained by executing computational tasks by running them in parallel parts. This means that sometimes there are computer programs that are viable to be worked on by multiple processors at the same time (e.g. parallel processing), but other parts must be taken care of one by one (e.g. serial programming).

Enlarge

The formula derived from Amdahl’s Law may seem intimidating, but it is much simpler than it seems:

Enlarge

If we take the 5 units of work and apply 3 processors to the parts that can be done concurrently (in parallel), it doesn’t take 1 and 2/3 units of time (5 divided by 3) to complete. Instead, 3 units are needed because 2 of the units of work can only be done by one (serial) processor. It’s certainly an improvement over time, but not as much as you’d expect at first glance.

Teamwork works in much the same way. In fact, if we convert everything to a graph we can get an idea of how efficient the increase in team members can be:

Enlarge

Enlarge

Let’s focus for now on the 80% line (the blue one, at the top) of the graph. Let’s be optimistic (and unrealistic) and assume that 80% of the work can be done by working in parallel. This suggests that the more people do it, the faster it will be over, right? Oh but wait. If we go from 1 person to 2 people, we don’t do twice as much work. To get an improvement of 2x the work completed, we actually need 3 people. 7 people only create a 3.2x improvement over 1 person. To do 4 times as much work as 1 person does, we would need 16 people!

What if even less work can be done at the same time (parallel)? What if 50% of the work needs to be done serially (green line on the graph)? Then with 9 people we still have only 1.8x speedup.

What is the solution? There is no easy solution, but there are things you can do to mitigate the effect of Amdahl’s Law:

• Make as much of the work as possible can be done in parallel. This may mean increasing cross skills and collaboration.
• Reduce dependencies between teams, so there are no bottlenecks or delays.
• Increase the speed of the overall work process by improving quality and practices.

Speed doesn’t come from sending more people to work and building bigger teams. It’s about building a high-performing team that is optimally sized for effectiveness, communication, and quality.

Research-Backed Evidence

American Sociological Association

The American Sociological Association published a study by Hackman JR, Vidmar NJ called “Effects of size and task type on group performance and member reactions”^[12].

Enlarge

In this study, they had participants complete a series of tasks: a combination of production (writing), discussion, and problem-solving. Participants were placed into different groups of 2 to 7. After completing each task, the volunteers were asked a series of questions, including two shown in this graphic: “was your group too small?” your group was too big? As you can see from the graph, groups around 4-5 in size seemed to have the least negative reaction. The frequently touched number is 4.6. The participants were college students, the tasks were cognitively loaded but not related to technology, development, etc., and the groups were not together long enough for a true “sense of team” to form. Nevertheless, it is an interesting fact.

In those days Hackman wrote the book Leading Teams, his rule of thumb for team size was 6^[13].

Social and Developmental Psychology Researcher Jennifer S. Mueller

Research psychologist Jennifer S. Mueller, academic, author, and research collaborator, was quoted in the article “Is Your Team Too Big? Too small? What is the correct number?:”

If companies are dealing with coordination tasks and motivational issues, and you ask, ‘What is your team size and what is optimal?’ that correlates to a team of six. “Above and beyond five, and you begin to see diminishing motivation,” says Mueller. “After the fifth person, you look for cliques. And the number of people who speak at any one time? That’s harder to manage in a group of five or more.”

From the Scrum Creators…nothing less

Based on studies by George A. Miller, and later work, Scrum creators Jeff Sutherland and Ken Schwaber showed the following levels of productivity creating their own research on team size:

And they added:

A small team from three to four people can be very autonomous when it follows guidelines, has a well-defined focus, and everyone is physically in the same space. His work is often consistent, responsible, aligned and well directed, and communication is fluid. Things are relatively easy when there are only a few people on the team. The problems seem to increase along with the number of team members.

Brook’s Law and Lawrence Putnam

The mythical Frederick Brooks to whom we owe the famous “Brooks’ Law” establishes that “adding manpower to a late software project makes it even later”. This is due to the learning curve, that is, you must train each person new to the product or technology, and you must learn all the related non-technical knowledge, including the business strategies that the product or software addresses ^[14].

According to important studies by renowned researchers such as Lawrence Putnam:

With an Agile Team:

In summary, if we have an optimal team, we can have productivity from 300 to 400%.

Putnam and Myers Hard Facts

Beyond our personal opinions, those of clients, bosses, and team members, we also have objective statistics. Putnam and Myers examined data from 491 software projects from a large corporation as reported in their article “Familiar Metric Management: Small is Beautiful Once Again“. These were projects with 35,000 – 90,000 lines of source code. They divided the projects into groups called buckets based on the number of people involved in the project: 1.5-3, 3-5, 5-7, 9-11, and 15-20. On average, the smaller groups (3-5, 5-7) took much less time (11.9 and 11.6 months, respectively) than the larger groups (17.1 and 16.29 months) to complete projects of similar size.

When you multiply the number of team members by the number of months, you get a graph that is even more impressive:

Enlarge

A team of 9 to 11 people took 2.5 to 3.5 times as long as teams of 5 to 7 and 3 to 5 to complete projects of a similar size. That suggests that the seven-plus teams in this dataset were just a way to spend money faster due to increased team size but reduced net return.

Evidence of Agile projects

Larry Maccherone, in his work through Rally, Tasktop and AgileCraft exposed in “Impact of Agile Quantified” in late 2014, has helped build large datasets on Agile team practices. His data shows:

Enlarge

Based on Larry’s data, it would appear that 1-3 teams are more productive but have lower quality. 3-5 teams are marginally more productive than 5-9 teams, although they may still be of slightly lower quality – the difference is small. Larry’s notes suggest that he thinks the entire range of 3 to 9 is fine [16]. The reason for the lower quality in the smaller teams is not obvious. Perhaps due to a lack of stability? Lack of diversity of thought and experience? Reduced cross-functionality? We cannot know, but it deserves consideration.

My experience

When clients, managers, etc. ask me how big Scrum teams should be, I don’t have a “correct” answer. But I try to share the above data, my personal opinions, and suggestions based on years of experience. And I won’t lie to you, there are organizations where bad habits are so ingrained that it’s hard to get that information across in a practical way (they don’t listen to it, they don’t take it into account enough, etc.). But I certainly try to make my suggestions based on evidence, simple logic, and common sense.

For example, larger teams spend more time building, more time normalizing, and therefore more time reaching high performance. Why? Because there are more relationships to negotiate. As we saw before, in a team of 5, there are 10 relationships that need to be formed, a team of 7 has 21 relationships, and so on. More relationships take more time to build and establish trust, so that should be taken into account when deciding on team size.

Assuming all else is equal (skills needed to get the job done, diversity of thought, etc.), the existing evidence supports the idea that teams of 4 to 6 work well in most situations. They take less time to train and are just as productive as larger teams. Also, teams of 5-7 can usually combine abilities enough to cover the loss of a team member.

Personally, I would only pick a team of 8 if other pressures, like the breadth of skills required, forced it to happen. I don’t recommend teams with more members, because the overhead costs outweigh the value of the additional person.

With teams of 10 or more, I recommend splitting into 2 teams. My own experience and that of other agile colleagues with scaling experience: Separate teams of 4 and 5 do more than their original large team.

With teams of 9 or more, I recommend splitting into 2 teams. My own experience mirrors that of other agilists using Scrum: separate teams of 4 and 5 do more than their original big team.

Why not 3 or less? Because it would result in very little diversity of thought and it would probably be very difficult to find 3 people with enough skills to get the job done on a complex project. There will also be very little collaboration, which correlates with the reduction in quality shown in Figure #2 (“Impact of Agile Quantified” data). And don’t forget the obvious 2v1 power issues that can make the journey more challenging for one team member.

All the focus has been on the number of people on the team, but the bigger question should be this: does the team have the ability to get to “Done” or “Done” at the end of each Sprint? If not, you’ll want to re-examine and reconfigure to achieve a more effective team size and most likely do a re-analysis to break down work into requirements, user stories, or the like.

[1] “The Impact of Lean and Agile Quantified” – Larry Maccherone showed that dedicated team members doubled productivity and stable teams (no turnover) improved productivity by 60%. https://www.infoq.com/presentations/agile-quantify

[2] Wilkinson, David. Group decision-making. What he said in The Oxford Review, Diciembre 2019

[3] “What Google Learned From Its Quest to Build the Perfect Team”: https://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html

[4] “The New Science of Building Great Teams” – Alex “Sandy” Pentland https://hbr.org/2012/04/the-new-science-of-building-great-teams/ar/pr and also “Evidence for a Collective Intelligence Factor in the Performance of Human Groups“

[5] The Wisdom of Teams: Creating the High-Performance Organization – Jon Katzenbach and Douglas Smith – indicates that potential skills are as important as the skills people currently have in predicting effectiveness.

[6] [7] [8] Wilkinson, David. Group decision-making. What he said in The Oxford Review, Diciembre 2019

[9] “The Magical Mystery Four: How Is Working Memory Capacity Limited, and Why?” – Nelson Cowan – https://www.psychologicalscience.org/journals/cd/19_1_inpress/Cowan_final.pdf?q=the-recall-of-information-from-working-memory

[10] Knowledge management https://en.wikipedia.org/wiki/Knowledge_management

[11] These are informal observations that anyone can get, but one of the most well-known investigations was done by the English magazine Nature Human Behavior in 2017.

[12] Stable reference: https://www.jstor.org/stable/2786271

[13] Familiar Metric Management – Small is Beautiful-Once Again – Lawrence H. Putnam and Ware Myers https://hbswk.hbs.edu/archive/2996.html

[14] The Mythical Man-Month: Essays on Software Engineering – Frederick Brooks https://en.wikipedia.org/wiki/The_Mythical_Man-Month

Related links:

Agile’s Origins and Values
The Agile Team Approach
What Scrum Master Certification to Choose?
Too Big to Scale – Optimal Scrum Team Size Guide

Some books to know more:

Emmanuel Herrera

IT professional with several years of experience in management and systems development with different goals within public and private sectors.

Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.

Some certifications include: PSM, PSPO, SSM.

internet80.com