17322084523_7ce372fd98_oDunbar’s number represents a theoretical limit on the number of people in a group that can maintain stable social relationships. Stable social relationships are needed to support application of Agile values, principles and techniques. Dunbar’s number is often quoted as 150 people. However, the limit for any individual group is a not only a reflection limits like Dunbar’s number but also context. If we accept there is some theoretical limit that we can’t scale past such as Dunbar’s number, we need to ask how other project or environmental factors further constrain the maximum number of people working on a problem.  Why go to the trouble of scaling up the number of people working a problem? Many Agilistas would suggest that a single small team is optimal. However, many problems will require a larger collation of teams to deliver value and functionality. Additional contextual drivers that modify the theoretical maximum number of people in a group or a team-of-teams include at least four factors. They are:

  1. Cohesion, or how well people stick together. There are many attributes that can generate cohesion. Examples include: big ideas, goals, nationalities, religions and even corporate identities. Cohesion fosters a common relationship, which helps make groups more willing to put forth effort to achieve an end. For example, it often is hard to achieve a cohesive group when members come from multiple external consultancies. Each organization involved in the group have a different set of organizational goals that will reduce cohesion unless they are subjugated to the project goal.  Reducing the number of people below Dunbar’s number makes the use of techniques like peer pressure to institutionalize a project vision to increase cohesion easier.
  2. Complexity is a measure of the number of properties for a project that are outside of the norm. The complexity of a problem reduces the optimal maximum number of people that can be bear because complexity generally requires either more control and coordination or alternately smaller teams to ensure collaboration.
  3. Uncertainty occurs when teams are searching for an answer to a business or technical problem. When a team needs to tackle an unknown business problem or new technology research is often required. Research generally is constrained to small teams with specialized skills reducing the optimal maximum group size for this type of endeavor well below Dunbar’s number. As concepts and ideas are discovered they can be rolled out more broadly to be fleshed out, prototyped and implemented increasing the group working on the project closer to Dunbar’s number.
  4. Dependencies between components often mean that work needs to be single threaded (or at least spread less broadly). Dependencies reduce the number of people or teams that can be effectively leveraged.

The idea of increasing the number of people and teams working on a project often appears to be a mechanism for delivering value more quickly. When adding people to is suggested remember the number of people working on a problem is a constraint than can not be dealt with by linearly increasing the number of people applied to a problem until you reach a limit such as Dunbar’s number.  Context directly impacts how large any group can before overhead and other constraints reduce effectiveness.    It is often said that you can’t get nine women to have a baby in a month. In addition to Dunbar’s number, context plays an important role in defining overall team size.

How many people is too many?

How many people is too many?

When determining how large an Agile program can be, one of the oft quoted “facts” is that the number of people involved in an Agile program is governed by Dunbar’s number. Dunbar’s number is the limit of the number of people in a group that can maintain stable social relationships. The term, social relationship is a reflection of regular interactions, the ability to recognize another member as part of the group or are committed to a common goal. These attributes are important to any project and are perhaps more important in Agile projects because they rely on team cohesion to minimize bureaucracy and control mechanisms.

The concept of Dunbar’s number is based on research originally performed through the observations of primates and then extended to humans in the early 1990’s. In June of 1992, Robin Dunbar  published “Neocortex size as a constraint on group size in primates” in the Journal of Human Evolution (Volume 22, Issue 6, June 1992, Pages 469–493). In the paper Dunbar noted a correlation between the size of a primate brain and the average social group size. From the abstract, Dunbar wrote:

Group size is found to be a function of relative neocortical volume, but the ecological variables are not. This is interpreted as evidence in favour of the social intellect theory and against the ecological theories. It is suggested that the number of neocortical neurons limits the organism’s information-processing capacity and that this then limits the number of relationships that an individual can monitor simultaneously. When a group’s size exceeds this limit, it becomes unstable and begins to fragment. This then places an upper limit on the size of groups which any given species can maintain as cohesive social units through time.

While group size of 150 is often quoted as Dunbar’s number, 150 is an approximation. As noted in the “Limits of Friendship” by Maria Konnikova (October 7, 2014) Dunbar’s number can range from 100 – 200 (ish) people based on factors such a social gregariousness. Other limits of group size have also been published for example Drs. Peter Killworth and Russell Bernard have published numbers in excess of 200 people.

Based on Dunbar’s number, the Scaled Agile Framework Enterprise (SAFe) suggests that the largest Agile release train (ART) should include approximately 150 people. The ART is supported by a framework (SAFe), hierarchy (release train engineer and Scrum masters) and bureaucracy (product management and product owners). Agile being practiced by a single team of 5 – 9 people would not require this degree of overhead to ensure coordination.

Scaling agile is a balancing act between the efficiency of team-level Agile techniques and the concessions made to control when Agile is scaled up to deal with larger efforts. Historically, very large projects tend to be less efficient. Capers Jones in Applied Software Measurement, Third Edition[1] (p295) indicates that productivity falls for all types of projects as they exceed 1,000 function point points. Function points are an ISO standard method of measuring software size based on a standard set of rules. Simply put the larger a project is in function points the larger the team (or team of teams) needed to deliver the project which yields the need for more control processes all other things being equal. He further makes the point (p 307) that as project size increases, so does the probability of cancellation.

Scaling Agile leverages many of the techniques used by team-level Agile, such as small team size, small batch sizes and Scrum. These techniques are are very lean but are perceived limit the amount of value that can be delivered within a specific period of time. As Agile projects grow in size additional techniques are needed to maintain control. Dunbar’s number (or similar ideas) provides a limit to try to avoid letting a piece of work become too large to manage. The number act as limit to the number of people involved in a piece of work. Applying additional constraints, such as releases or SAFe’s program increment, add a dimension of time as constraint. The combination of constraints on the number of people and the how long those people will be working provide an explicit constraint on how much work can be delivered.

1 Applied Software Measurement, Third Edition, T. Capers Jones, McGraw Hill, 2008