Optimal Team Size
Author: Menno R. van Dijk MSc.
Date: May, 2012
Summary & Introduction
Exactly how small should our small autonomous teams be?
This is the question manager of the central back-office of a large Dutch retail bank asked me, when I proposed the idea of autonomous team to him. At the time, I was working on a project to introduce customer focus and to realise same-day processing in his organisation. I came up with an innovative organisation design, in which small teams are responsible for their work for that day, i.e. all customer request of a certain type that the bank had received that day. After a successful pilot, the organisation wanted to introduce this way of working for all (ca. 400) employees. That’s when this question came up…
From experience, I knew that the teams shouldn’t be too big: the pilots were done with teams of 5 – 7 persons. However, factual substantiation was needed. A quick search showed me that a lot of research had been done on Agile / Scrum teams, so that is where I started. And this article is the result: a literature search on the optimal team size for autonomous teams.
My conclusion is: Organisational design isn’t an exact science. As an engineer, I would have loved to have found statistically sound measurements on the effectiveness of teams of different sizes – but in truth, I think that team size isn’t the main driver for team effectiveness. However, if your customer, the type of work your customer asks you to do, requires your organisation to work in small teams, I would suggest – as I did to the manager of the banking back office: small teams consist of 5 to 9 persons. Or, If the flexibility of your workforce allows this, as it did in the case of the banking back office: flexible team size, ranging from 5 on slow days to 9 on a busy day.
At the moment of writing, banking back office has implemented the new way of working, and has asked me to do a ‘check-up’ on the effectiveness of the new organisation. I can’t wait to start: Ï wonder what I will find, but I bet that it will be inspiration for several articles on CoOperationalExcellence.nl!
This article will focus on the importance of two critical factors to be considered when deciding how to structure Scrum teams:
- keeping teams small
- orienting each team around the delivery of end-to-end functionality
- looking at the importance of having the right people on each team
- not overloading individuals by forcing them to split time among too many teams
Or, in short: Optimal Team Size.
Team size in Agile and Scrum
The term Scrum [in Rugby] refers to the strategy used for getting an out-of-play ball back into play. As in a rugby match, development teams in Scrum are organized to have holistic movement, have continuous interaction among team members, and have interacting core team members. Among the team members, Scrum Master (SM) is the person who does administrative work, such as arranging the daily Scrum meeting and location, and removing any production impediments.1
Asking for the optimal Team size is always somewhat tricky: it needs to be clear if the complete Scrum Team is concerned or the Team of Developers.
The Scrum Guide states: “The optimal size for a Team is seven people, plus or minus two”, referring to the Scrum Team. In the PSM I assessment the question undeniably refers to the “Team (of Developers)” but has the same answer, i.e. 7+/- 2.2
After this, it gets quite confusing: the Guide does say that the Team has seven people, plus or minus two, referring only to the Team of developers. The Scrum Team consists of the ScrumMaster, Product Owner, and the Team of developers. However, the phrase Team if often misconstrued to mean Scrum Team. And, to make matters worse, there are some instances where the programmers asserted that only they were developer, and QA, Design, Analysis, documentation were all something else.2
It is perhaps a myth, but an enduring one, that people and their pets resemble one another. The same has been said of products and the teams that build them.
“The system being produced will tend to have a structure that mirrors the structure of the group that is producing it, whether or not this was intended. One should take advantage of this fact and then deliberately design the group structure so as to achieve the desired system structure.” (Conway 1968; commonly referred to as “Conway’s Law”)
If it is true that a product reflects the structure of the team that built it, then an important decision for any Scrum project is how to organize those individuals into teams. Factoring into this decision are considerations of team size, familiarity with the domain, the channels of communication, the technical design of the system, individual experience levels, the technologies involved, the newness of those technologies, where team members are located, competitive and market pressures, expectations about project schedule, and much more. To be honest, there are some advantages to large teams. Large teams may include members with more diverse skills, experiences, and approaches. Large teams are not as much at risk to the loss of a key person. They may also provide more opportunities for individuals to specialize in a technology or a subset of the application.3
What Lean companies are doing
Another interesting take on this subject is to look at companies that have adopted Lean as their way of working. When we look at what these companies are doing, we find that there are even more advantages to small teams. Companies like Valeo, Gee, Sewell, Briliance, Foton are considering below advantages for forming Small team of 7(± 2) members.
Less social loafing. Social loafing is the tendency for people to exert less effort when they believe there are others who will pick up the slack. Members of small teams are less prone to social loafing. Social loafing was first demonstrated by psychologist Max Ringelmann in the 1920s when he measured the pressure exerted by individuals and teams pulling on a rope. Groups of three exerted only two-and-a-half times (not three times) the average individual pressure. Groups of eight exhibited less than four times the individual average. Ringelmann’s and related studies have shown that individual effort is inversely related to team size (Stangor 2004, 220).
Constructive interaction:. Stephen Robbins, author of Essentials of Organizational Behavior, a best-selling textbook on organizational behavior, has concluded that teams of more than 10 to 12 people have a difficult time establishing feelings of trust, mutual accountability, and cohesiveness. Without these, constructive interaction is difficult (2005).
Less time is spent coordinating: Small teams spend less time coordinating the efforts of team members. This is true both in the aggregate and as a percentage of total project time. As a simple example, we all know that the effort just to plan a meeting for a large team can be overwhelming.
No fade into the background. With large teams, there is lower participation in group activities and discussions. Similarly, the disparity in the amount of participation among team members increases. The problems can prevent a group of individuals from jelling into a cohesive, high-performing team.
Small teams are more satisfying: With a small team, one person’s contributions are more visible and meaningful. This is perhaps one reason why research has shown that participation on a large team is less satisfying to team members (Steiner 1972).
Harmful over-specialization is less likely to occur. On a large project, individuals are more likely to take on distinct roles (Shaw 1960). For example, one developer chooses to work only on the user interface. This creates wasteful hand-offs of work between team members and reduces the amount of learning that occurs when individuals are more willing and likely to work beyond specific job roles.3
Given the strength of these advantages to small teams, we would expect small teams to be more productive than large teams. Doug Putnam of QSM found exactly those after studying 491 projects with team sizes from 1 to 20 people. Since 1978 QSM has been collecting data on software productivity and estimates. The company maintains the software development industry’s most thorough metrics database, including data on application size, effort, industry, and more. As such, the QSM database is uniquely valuable for comparing different types of projects.4
People have been trying to answer this question for ages, and there seems to be little consensus. At the SPA 2009 conference, Joseph Pelrine told his audience that the sizes 5, 15 and 150 have been mentioned in (or can be derived from) scientific research, as being optimal sizes for social groups.
The agile movement, with Scrum as the leading method at this time, often mentions a preferred team size of 7 plus or minus 2 (which is just a software developer’s way of saying between 5 and 9).
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. And be aware that they might want to reconsider things when the environment (or the set of personalities in the team) changes again.4
Scrum was getting popular almost at the same time as Mary Poppendieck was theoreticizing the various aspects of Lean. In a way both Scrum and Lean have their origin in complex adaptive systems theory. The origins of Scrum are best explained by Jeff Sutherland in one of his blog post. The conclusion in this post point to the fact that although Scrum can be in some ways viewed as a partial Lean Process, it is not a descendent of Lean. Also, if the concepts of Lean are applied within the Scrum framework, the results would be akin to what companies like Toyota have been able to achieve in product development.
As Marry Poppendieck expained in a Lean Agile Scrum Conference in Zürich in 2010, Scrum is basically a method of accomplishing work through cadenced iterations. Kanban is a method of accomplishing work through limiting work-in-process and managing flow. Some work (especially creative work) is more effectively managed with iterations, while other work (especially naturally sequential work) is more naturally managed with Kanban. Generally, you would use one or the other of these techniques, but not both at the same time for the same work. Determining which workflow management technique is best for a give situation should be done through experiments and system-level measurement of results.8
Quality Circles or Kaizen Teams
One of the most publicized aspects of the Japanese approach to quality management is the idea of Quality Circles or Kaizen teams. Professor John Oakland (a leading authority on quality) defines a Quality Circle/Kaizen Team as a group of workers who do similar work and who meet:
- In normal working time
- Under the leadership of their supervisor
- To identify, analyse and solve “work-related” problems
- To recommend solutions to management
Evidence of successful Quality Circles suggests that there are no formal rules about how to organize them. However, the following guidelines are often suggested, very close to SCRUM Team formations Ideas: –
- The circle should not get too large – otherwise it becomes difficult for some circle team members to contribute effectively.
- Meetings should be help away from the work area – so that team members are free from distraction
- The length and frequency of quality circle meetings will vary – but when a new circle is formed, it is advised to meet for about one hour, once per week. Thereafter, the nature of the quality problems to be solved should determine how often the circle needs to meet
- Quality circles should make sure that each meeting has a clear agenda and objective
- The circle should not be afraid to call on outside or expert help if needed6
As we can see, whether or not Scrum tends towards Lean is driven by what the team and stakeholders value while implementing Scrum. In fact, there’s really nothing to stop you from using Scrum to schedule a more rigorous workflow like the SEI Process.
The Scrum method offers management good visibility and predictability not only about the software under development but also about Products and Service being on Progress. It inherently motivates people and builds ultra-productive teams mostly due to the Small Team size, facilitate Funnel Focus, Ownership, Autonomy, Team Attitude and Continuous improvement. Conversely, customers benefit from the method because they can see, touch, and feel the product each step of the way. It’s much easier to take a look at the running software and decide on requirements along the way, rather than try to imagine all of them upfront. Since customers give concrete feedback during development, requirements can be added and changed anytime into the product backlog, no one cribs!
As we can see, all the strands of Scrum’s DNA are equally important. It’s a method that works because it is built around the nitty-gritty of the two complex things that matter most when it comes to building great software — the software itself and the humans who build it. Manufacturing and Service Organization has the similar fact sheet.7
Organisational design isn’t an exact science. As an engineer, I would have loved to have found statistically sound measurements on the effectiveness of team sizes – but in truth, I think that team size isn’t the main driver for team effectiveness. However, if your customer, the type of work your customer asks you to do, requires your organisation to work in small teams, I would suggest – as I did to the manager of the banking back office: small teams consist of 5 to 9 persons. Or, If the flexibility of your workforce allows this, as it did in the case of the banking back office: flexible team sizes, ranging from 5 on slow days to 9 on a busy day.
At the moment of writing, banking back office has implemented the new way of working, and has asked me to do a ‘check-up’ on effectiveness of the new organisation. I can’t wait to start: Ï wonder what I will find, but I bet that it will be inspiration for several articles on CoOperationalExcellence.nl!
- Wikipedia: Scrum (Rugby) Section
- Gunther Verheven and Ken Schwaber in Scrum.Org. Discussion on “Team Size” in Software Industry
- “Succeeding with Agile” by Mike Cohn
- “Succeeding with Agile Software Development Using Scrum: Team Structure” in http://www.informit.com/articles/
- 5. What is the optimal size of a team? In NooP.NL
- Om Band Stated in “http://www.scrumalliance.org/articles/325-why-scrum-works” is working with software development for last 12 years and currently working with SAP Labs. He has previously worked with LG Soft, Aztec software (now Mindetree) and Sun Microsyst.
- Published at http://www.scrum-breakfast.com