Get certified - Transform your world of work today

Close

Agile Scaling and Dunbar's Number

21 June 2017


As an Agile coach, I have been fortunate to advise and instruct enterprise customers from Europe to the Middle East and Australia in their Agile transformations. They all had a common pain point: They could get their teams to become Agile, but how could they get their programs, portfolios, and thus their entire organization and enterprise to become Agile?

To address this question and help the organizations during this phase of the transformation, any one of several Agile scaling frameworks can be used, such as SAFe (Scaled Agile Framework), LeSS (Large Scale Scrum), Nexus, Scrum of Scrums systems, and Spotify's framework. Each has been successfully implemented by various organizations. These frameworks are remarkable guidelines for any organization to embrace in scaling Agile for their own specific business and growth needs. But I believe these frameworks also have a correlation with Dunbar's number.
 

Dunbar's number and Agile scaling frameworks

Dunbar's number was coined by Robin Dunbar, an anthropologist and evolutionary psychologist. The idea is that the number 150 is useful to understand as the approximate maximum number of individuals with whom a person can maintain a stable relationship.

This number is reflected, more or less closely, in many of the following Agile scaling frameworks:
  • SAFe — The Agile Release Train, which is a performing cross-functional group of individuals, is composed of up to a maximum of 125 practitioners.
  • LeSS — To scale Agile, the cap is eight Agile cross-functional teams, up to a maximum of 72 practitioners. Another framework was defined, LeSS Huge, to cater to larger portfolios, but the fundamental guideline remains, which is to cap to size to enable a performing unit.
  • Nexus — To scale Agile, the cap is nine feature teams that would total 81 practitioners.
  • Spotify — For the tribe (the name for sustaining and performing cross-functional groups of individuals) to realize a business value, it should not be more than 100 practitioners.
I would say that a subtle correlation exists between Scaling Agile and Dunbar's number. That is, while 150 itself is not some exact magic number in Agile, the concept exists of capping the number of people with whom a team player can effectively engage, even in scaling situations.
 

The economics

Questions have been raised about whether these frameworks can be practically implemented, given the current scenario of tightening visa laws and regulations in countries such as the U.S., Australia, and Singapore, as well as the challenging macroeconomic conditions facing the software industry. In many organizations that are both product- and service-based, I have noticed that when a project comes in, practitioners are sourced from various verticals, competencies, and even centers of excellence to form a project team. After the project is done, the practitioners return to their respective areas and wait for another project. Sadly, if there's no project in the pipeline, many practitioners are asked to leave, which makes scaling Agile difficult.

I'd like to examine whether Dunbar's number can be a solution, or even a potential nascent step, to addressing this complex macroeconomic situation.

Let us assume that an organization has a few thousand practitioners who are all aligned with technology-based and skills-based verticals. When a project comes to a delivery cost center, sourcing and adjourning occur at the end of the project, since every project, by definition, has an end date. Based on the approach, when this hypothetical organization, with its long-term business vision goals, has a cluster of practitioners based on Dunbar's number as aligned to business vision goals or business vision subgoals, funding is allocated to the business goals. Therefore, this organization can be visualized as several Dunbar-number teams aligned to business vision goals or subgoals of the organization. Whatever the vision, it has no expiry date or, at least, it has a long-term one. The cluster of Dunbar-number teams can coordinate among themselves, using any Agile scaling framework or just Lean management practices, and each Dunbar-number team can be subdivided into a cluster of Agile teams, which are concept-to-cash and cross-functional.

Even when an organization's business goals change or die down, Dunbar-number teams can be groomed for new business goals with much less lead time, since they already gel, self-organize, and work on the technology stack, which would not drastically change in relation to the changes in the organization's business goals. They can even be groomed for a new technology stack, because they already embrace a culture of self-organization.

Also, in the worst-case scenario in which the organization's business goal has died down to the extent that downsizing is the only option, then these Dunbar-number teams can be loaned or even acquired by other organizations, as many organizations will pick a performing team. In challenging times, competition is good but collaboration is better. Similarly to the way that the Agile Manifesto emphasizes customer collaboration over contract negotiation, we can use the Dunbar-number teams to give organizations the competitive edge to ensure improved lead times in sourcing new avenues or, in tougher times, to collaborate with the competition itself to build a sustaining IT ecosystem.
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 3 (2 ratings)

Comments

Tim Baffa, CSM, 6/21/2017 8:48:29 AM
There is plenty of research and material touting the benefits of stable teams. You run into trouble treating talented and creative people as interchangeable parts...
Reinhard Patels, CSM, 7/1/2017 3:19:20 PM
@Vishal Venkatesan and @Tim Baffa - this is exactly what we want to avoid by asking for dedicated team members, and by also explicitly stating e.g. in SAFe that a program/RT as part of a Value Stream is a potentially endlessly running unit.
Any change in the consistency of this unit creates interference and requires another phase of learning and fine tuning (similar to any car/race car engine). This change is (as any change) unavoidable for various reasons and causes, and needs to be addressed as any other change - incl. defining necessary extra measures and pointing out the consequences to short and long term goals.
And we talk about "swarming teams". As kind of insect hive of very intelligent individuals.
It is in the nature of things that also combined with larger numbers (like 100+) people lose their "individual faces" and customers and managers alike see them all as interchangeable parts.
Together with the fact that many program members just embed themselves into such a "hive" (simply subjugate to the group, which is just a replacement to the old micro-management ways - just now maybe a group is telling me what to do instead of a single manager, but still I am "safe" without real individual responsibility) this all maintains the old mindset of "interchangeable parts".
And this is indeed a major issue (sometimes not right there at the beginning but rather building up over time) to be overcome. I would have said "avoided", but in my experience this cannot be completely avoided in larger (+ transformed) structures. It will continuously build up over time and needs to be addressed on occasion.
Reinhard Patels, CSM, 7/1/2017 3:42:33 PM
In general - the Dunbar's number is "just" an observation that roughly correlates with another observation (already by the old Greek philosophers) and confirmed also by modern Psychology (incl. management training) and Biology (incl. brain research) :
Our brain is built to be able to handle as many parallel processes/activities peers as the human has digits on one hand (so, 5) and with some training and practice on 2 hands (so, 10). Any interface for a human containing more than 10 variable but directly connected parts will cause problems. Then the attention and efficiency for the individual parts will decline ultra-rapidly, and the handling of these parts will become also very erroneous.

Very, VERY few people can effectively handle more than 10 things directly in parallel.
That is also the reason why we recommend Agile teams (but any form of teams, really) to be not larger than 10 - give or take 1 or 2 depending on the circumstances. Bigger teams will have no chance to self-organize. Or, if attempted, they usually split themselves automatically into some sub-units inside the "team".
And therefore also no manager should have more than 10 direct peers, and if the management team gets really bigger than that, there should be a split and a hierarchy level extension with proper delegation.

Now, our brain also supports this by allowing us about 2 levels of peer to peer connection : 1. the direct peers (as mentioned above), and 2. the peers of peers with a much looser connection. We still know them individually and perceive them as part of our "tribe". This is where Dunbar's number comes in.
And you can say from 1. purely mathematical this would be 10x10 = 100 or maybe with some stretch 12x12 = 144.
This correlates pretty well with the observation of Dunbar's number of about 150, when we start to lose the ability to recognize the individual faces and names (and roles).

E.g. SAFe size limits emerge from such mathematical calculations (plus some buffer for "extras", which comes also from considering Dunbar's number). Because peer and peer-to-peer relationships are similar and connected, it correlates.
Vishal Venkatesan, CSM, 7/14/2017 12:08:55 AM
Thanks All, this article is just a view point that Dunbar Number matches most scaling frameworks, any Dunbar number team would have multiple performing Agile teams

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe