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