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 (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.