In this article we present our rule of thumb for the sizing of solutions based on what an organisation can handle. Our primary goal is to make you aware of cognitive load theory and sociological considerations on organisational structure. Be aware that these are somewhat fuzzy theories, which are still debated and do not provide us with definitive answers. We are still convinced that taking these ideas into consideration helps in making organisations more effective. With our rule of thumb we hope to provide organisations a tool for conversation around how to effectively organize flows of work, without overloading and burning down teams.

We start with a short introduction of cognitive load theory and sociological considerations on organisational structure. We finish by examining the organisational structures defined by various agile frameworks.

This is the second iteration of this article. We have now defined the organisational construct in a more theoretical and framework/platform agnostic manner, where the first iteration was written around the three organizational constructs defined by SAFe [1]. We decided to dive into the various agile scaling frameworks/platforms that we are currently aware of an discover their approach to organisational constructs. We have added a table that summarizes this information. We have also added a section with the relevant sections from these frameworks/platforms.

Cognitive load theory

The history of cognitive load theory can be traced to the beginning of cognitive science in the 1950s and the work of George Armitage Miller. His classic paper “The magical number seven, plus or minus two: some limits on our capacity for processing information” [2], published in 1956, was perhaps the first to suggest our working memory capacity has inherent limits. His experimental results suggested that humans are generally able to hold only seven plus or minus two units of information in short-term memory.`

  • Cognition is the mental action or process of acquiring knowledge and understanding through thought, experience, and the senses.

  • Cognitive load is the amount of mental effort caused by factors such domain complexity, technology needed, and related overhead. There are broadly three types of cognitive load that are believed to circularly influence each other, according to work conducted in instructional design pedagogy:

    • Intrinsic cognitive load is the inherent level of difficulty associated with a specific instructional topic.

    • Extraneous cognitive load is generated by the manner in which information is presented to learners and is under the control of instructional designers.

    • Germane cognitive load refers to the working memory resources that the learner dedicates to managing the intrinsic cognitive load associated with the essential information for learning.

  • Cognitive capacity is the maximum cognitive load an organisational construct can handle.

Organisational structure

We consider an organisation to be an entity comprising a group of persons having a particular purpose. To be effective every organisation will organise itself in one or more organisational constructs. We start by looking at sociology for considerations on the size and cohesion of groups.

Group size

The number of people involved is an important characteristic of any grouping in which social behavior occurs. Large groupings have a tendency to divide into smaller subgroups.

Dyad [3]

A group of two persons is important either as a stand-alone group or as a building block of larger groupings. Both persons are able to retain their individuality as there is no fear that another may shift the balance of the group. An infant requires a caregiver in order to survive, so life begins in a pair relationship that is apt to influence later ones.

Triad [4]

A group of three persons is hard to maintain. After all, it is easier to deal with one other person than with two. Besides, two of the people in a triad are apt to find it easier to relate to each other than to the other partner. That can motivate the neglected party to drop out of the group. In history, three leaders have sometimes attempted to share political power in a triumvirate, with little long-term success. On the other hand, groups of three can be very stable if there is a leader and two followers, such as a family of a single parent and two children.

Tetrad [5]

A group of four persons tends to not last very long, with the notable exception of vocal and musical quartets. Two persons in the group are apt to find it more satisfying to relate to each other than to either of the other persons. If the other two feel left out, they have at least that in common. They may feel a need to counteract the advantage a pair has when acting together over an individual operating alone. The relationship becomes one of two pairs rather than an effective group of four members.

Cohesion

Herbert Arnold Thelen, in his 1949 paper “Group Dynamics in Instruction: Principle of Least Group Size” [6], proposed a principle that for members of groups to have maximum motivation to perform, the number of members in each should be the smallest "in which it is possible to have represented at a functional level all the social and achievement skills required for the particular required activity. Robert Melancton Metcalfe, in his 1983 presentation to the 3Com sales force [7], states that the financial value or influence of a telecommunications network is proportional to the square of the number of connected users of the system:

metcalfe’s law

As a group gets larger, adding another person has less effect on its characteristics. The communication overhead within a group increases as the number of persons in a group increases. It also takes some time for the person added to a group to become productive. The complexity of a team’s interactions grows as the team expands, making it crucial to understand the stages of team development, the impact of multiculturalism, and the role of communication styles. [8] [9]

A consideration at least in smaller groups, though, is whether the number of members is even or odd. Doing things together is easy if all those involved agree on what to do, or if the majority opinion is able to override objections without repelling the objectors. A group of six or eight members can split into two equal factions, so decision-making is not apt to be as easy as if the size were five, seven or nine. As groups get larger stalemates are less likely but still can be troublesome. If a group makes decisions by voting it can adopt a means of tie-breaking (requiring one vote more than 50% for a measure to be adopted, giving the presiding officer a tie-breaking vote, or deciding by coin toss). Even-sized small groups often experience lower cohesion than odd-sized small groups.

Robin Ian MacDonald Dunbar, in his 1992 paper “Neocortex size as a constraint on group size in primates” [10], defined the following ‘magic numbers’ of group sizes:

  • 5: Our best friends and closest support group

  • 15: The close friends we trust

  • 50: Persons we call friends or would invite to a group dinner

  • 150: Our stable relationships

  • 500: The number of not-so-close acquaintances we can keep

  • 1500: The number of persons we can name and recognize

Frederick Phillips Brooks, in his 1975 book “The Mythical Man-Month” [11], observed that under certain conditions, an incremental person when added to a project makes it take more, not less time. Adding more persons to a highly divisible task, such as cleaning rooms in a hotel, decreases the overall task duration (up to the point where additional workers get in each other’s way). However, other tasks including many specialties in software projects are less divisible; Brooks points out this limited divisibility with another example: while it takes one woman nine months to make one baby, "nine women can’t make a baby in one month".

Rule of thumb for sizing of solutions

As collaboration is expensive in terms of cognitive load, this puts a constraint on the size of every organisational construct. Every solution, and every autonomous part thereof, adds an amount of cognitive load to the organisational construct responsible for creating/changing/operating/running that solution, or autonomous part thereof.

Architects are expected to intentionally decompose solutions into autonomous parts. “Domain-Driven Design” [12] defines these as bounded contexts, which are isolated from each other and which are easier to change, test, and incrementally develop. This separation allows teams to autonomously focus on their specific bounded contexts without undue interference or complexity from other bounded contexts, which will produce solutions that can be independently designed and delivered. Team Topologies [13] offers an approach to designing team-of-teams organizations for fast flow of value. Team Topologies identifies 4 fundamental topologies and three core interaction modes, which explicitly guide inter-team interaction and help create well defined boundaries that reduce cognitive load for each team.

While there is a one-on-one-relation between an autonomous part and a team and a solution and a team-of-teams, be aware that the other way around a team can own multiple autonomous parts and a team-of-teams can own multiple solutions!

Whichever problem an organisation is solving, the solution should be questioned on how well its ‘cognitive load’ fits within the ‘cognitive capacity’ of the organisational constructs.

We have a rule of thumb for the sizing of solutions:

  • The ‘cognitive load’ of every autonomous part of a solution must not exceed the ‘cognitive capacity’ of a team.

  • The ‘cognitive load’ of a solution must not exceed the ‘cognitive capacity’ of a team-of-teams.

  • The ‘cognitive load’ of a large-scale solution must not exceed the ‘cognitive capacity’ of multiple team-of-teams.

"Less is more": Keep organisational constructs small and remember that in complex problem spaces, employing multiple smaller solutions reduces the overall cognitive load.

We hope this article starts a two way conversation within your organisation to prevent ‘cognitive overload’.

Key takeaways:

  1. Collaboration is an expensive type of interaction that limits the size of a team.

  2. Use “Team Topologies” to design organisational constructs (teams and teams-of-teams) which promote flow and focus and align communication structure and architecture.

  3. Use “Domain-Driven Design” to decompose solutions into clever bounded contexts:

    1. That match the organisational constructs

    2. That reduce the overall cognitive load by minimising the size and complexity of the solution

Organisational structures as defined by various agile frameworks

Deliverable

autonomous part of a solution

solution

large-scale solution

Multiple  Solutions

cognitive load

⇐

⇐

⇐

>

Organisational construct

one team

one team-of-teams

mulitple team-of-teams

N.A.

Agile Scaling Framework

Scrum

Scrum Team

(<10 persons)

N.A.

N.A.

N.A.

Scrum-of-scrums

Development Team

Scrum Team

(<10 persons)

N.A.

N.A.

Metascrum

Scrum Team

(<10 persons)

MetaScrum

N.A.

N.A.

SAFe

Agile Team

(<10 persons)

[Essential]

Agile Release Train

(50-125 persons / 5-15 Agile Teams)

[Large Solution/Portfolio)

Solution Train

(2+ Agile Release Trains)

[Full Configuration]

(2+ Solution Trains)

Less

Scrum Team

(<10 persons)

Less

(2-8 Scrum Teams)

Less Huge

(8+ Scrum Teams)

N.A.

Disciplined Agile Delivery

Small Agile Team

(2-15 persons)

Medium Sized Team

(25-30 persons)

Program

Medium-Sized

(12-50 persons)

Large-Sized

(35+ persons)

N.A.

N.A.

Nexus

Scrum Team

(<10 persons)

Nexus

3-9 Scrum Teams

+

Nexus Integration Team

N.A.

N.A.

Background info on the various agile frameworks

Scrum [14]

The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. In general, we have found that smaller teams communicate better and are more productive. If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.

The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. They are structured and empowered by the organization to manage their own work. Working in Sprints at a sustainable pace improves the Scrum Team’s focus and consistency.

The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. Scrum defines three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and the Scrum Master.

Scrum Team ⇐ 10 persons:

  • Team members

  • Scrum Master

  • 1 Product Owner

  • 1 Product (Goal)

  • 1 Product Backlog

  • 1 Sprint (across all Teams)

  • 1 (Potentially Shippable) Product Increment

Scrum of Scrums [15]

When a Scrum Team works on a single product with multiple Development Teams, unresolved dependencies within individual Development Teams create a shared challenge of the Scrum Team.

The Scrum of Scrums is a meeting to coordinate these unresolved dependencies and shared work, in which an ambassador from every Development Team participates.

Metascrum [16]

The Metascrum is a forum where the entire enterprise can align behind the Product Owners’ backlogs at every level of Scrum in the organization:

  • 1 MetaScrum Product Owner

  • Multiple Product Owners

  • Management

  • Other Stakeholders

SAFe [17]

SAFe integrates the power of Lean, Agile, and DevOps into a comprehensive operating system that helps enterprises thrive in the digital age by delivering innovative products and services faster, more predictably, and with higher quality.

Agile Team = < 10 persons

Agile Release Train (ART) = 50-125 persons/5-15 teams

A team of Agile Teams that align to a shared business and technology mission. Each is a virtual organization (typically 50 – 125 persons) that plans, commits, develops, and deploys together. ARTs are organized around the enterprise’s significant Development Value Streams and exist solely to realize the promise of that value by building and delivering Solutions that benefit the Customer. In addition to the Agile teams, the following roles aid the successful execution of the ART:

  • Release Train Engineer (RTE) is a servant leader who facilitates ART execution, impediment removal, risk and dependency management, and continuous improvement.

  • Product Management is largely responsible for ‘what gets built,’ as defined by the Vision, Roadmap, and new Features in the ART Backlog. They work with customers, teams, and Product Owners to understand and communicate their needs and participate in solution validation.

  • System Architect is an individual or team that defines the system’s overall architecture. They work at a level of abstraction above the teams and components and typically define Nonfunctional Requirements (NFRs), major system elements, subsystems, and interfaces.

  • Business Owners are key stakeholders of the ART, with final responsibility for the business outcomes of the train.

  • Customers are the ultimate economic buyers or value users of the solution.

In addition to these critical ART roles, the following functions play an essential part in ART success:

  • System Teams typically assist in building and maintaining development, continuous integration, and test environments.

  • Shared Services are specialists necessary for the success of an ART but cannot be dedicated to a specific train. They often include data security, information architects, site reliability engineering (SRE), database administrators (DBAs), and many more.

Solution Train = 2+ Agile Release Trains

The organizational construct used to build large solutions that requires the coordination of multiple ARTs and suppliers. In addition to the ARTs and Agile teams, the following roles aid the Solution Train’s successful execution:

  • Solution Management defines and supports building desirable, feasible, viable, and sustainable large-scale business solutions that meet customer needs over the solution’s significant lifespan. They represent the customer and business needs to the ARTs.

  • Solution Architects define and communicate a shared technical and architectural vision across the Solution Train to help ensure the solution under development is fit for its intended purpose. They work with the ART’s System Architects to help guide their portion of the solution’s design.

  • Solution Train Engineer (STE) is the coach for the Solution Train, facilitating and guiding the work of all ARTs and suppliers. The STE works with Release Train Engineers (RTEs) to facilitate ART execution and coordinate delivery.

  • Suppliers are internal or external organizations that develop and deliver components, subsystems, or services, which help Solution Trains deliver solutions to customers.

  • Business Owners are key stakeholders of the Solution Train, with final responsibility for the business outcomes. They, along with Solution Train leaders, may also serve as business owners for the Solution Train’s ARTs.

  • Customers are the buyers of the solution and ultimately determine value. When delivering in a supply chain, customers work closely with Solution Management and other key stakeholders to define and adjust the solution’s vision, intent, and delivery roadmap.

Due to their size and cost, large solution development attracts a lot of attention, heightening stakeholder involvement and increasing opinions, governance, and oversight. The Solution Train leadership team – Solution Managers, Architects, and STE – must be aligned and represent a consistent force to realize the solution’s vision. The STE should ensure this team has the time and space to form as a team and build cross-role transparency and trust. The following roles also play an essential part in the Solution Train’s success:

  • A System Team is typically formed for the Solution Train to address the integration issues across the ARTs. Individual ARTs may have their own Systems Teams. All System Teams share resources and align on common infrastructure and toolchains where possible.

  • Shared Services represent the specialty roles, persons, and services required for the success of the Solution Train, but that cannot be dedicated full-time. Sometimes, they may be devoted to the Solution Train and shared across the ARTs.

SAFe defines a number of configurations, which to adopt depends on your organization’s size, complexity, and need for strategic alignment:

Essential = 1 Agile Release Train = 50-125 persons/5-15 teams

Large Solution = 1 Solution Train = 2+ Agile Release Trains

Large Solution SAFe is for enterprises building large and complex solutions that do not require portfolio concerns.

Portfolio = 2+ Agile Release Trains

Full = 2+ Solution Trains

A SAFe Portfolio is a set of value streams that delivers a continuous flow of valuable solutions to customers within a common funding and governance model. The SAFe Portfolio consists of multiple Development Value Streams (DVS). Each DVS has a lean budget and consists of one or more Solutions and the persons who maintain and evolve those solutions. Typically, these persons are organized into Agile Teams, Agile Release Trains (ARTs), and Solution Trains. Additionally, the portfolio defines a set of Portfolio Epics representing significant solution development initiatives. The Portfolio Backlog captures those epics to enable governance of their investments’ discovery, risk, and MVP evidence. Portfolio epics may span multiple DVSs and require coordination using Value Stream Coordination practices.

  • Epic Owners take responsibility for guiding the collaborations needed to realize value from epics.

  • Enterprise Architects assist in ensuring Business Epics advance the overall enterprise technical architecture. For more technical Enabler Epics, they may also act as Epic Owners.

  • The Value Management Office (VMO) coordinates, supports, and encourages continuous improvement across the portfolio. To ensure the maximum flow of business value through each DVS, portfolio members apply Value Stream Management. The portfolio may also coordinate and apply Big Data practices to ensure optimal use, and that value is gained from the data collected and managed across the DVS.

LeSS [18]

LeSS is Scrum applied to many teams working together on one product.

Scrum Team = 3-9 persons

LeSS

  • 2-8 Scrum Teams

Less Huge

  • 8+ Scrum Teams

  • Multiple Requirement Areas

    • 1 Area Product Owner

    • 1 Area Product Backlog [Filter/view on Product Backlog]

    • 4-8 Teams

Disciplined Agile Delivery [19]

Scrum Team = 2+ persons

Program = Team of Scrum Teams

Scrum Teams can range in size from two persons to twenty to two hundred or more. Larger teams are typically formed to address more complex problems, and as a result large teams take on the challenges of greater domain complexity and/or greater technical complexity as described below. Team size tends to directly affect how you organize the team and how you coordinate within the team. For example, a large agile team of 600 will be organized into subteams and a leadership team will be required for coordination, something we capture in DA’s Program life cycle. A team of 50 will also be organized into subteams, although coordination will likely be simpler and possibly handled by a daily coordination meeting of representatives from each subteam (a technique referred tas a Scrum of Scrums). It is fairly straightforward to coordinate the activities of a team of 10 persons.

A program is a collection of related initiatives managed in a coordinated way to obtain benefits not available from managing them individually. A program team is typically organized as a team of teams, called sub-teams or squads. Structures are required to coordinate persons, requirements, and technical concerns within the overall program. Where a simple “scrum of scrums” may suffice coordination on small-to-medium sized programs (say up to five or six sub-teams) small-to-medium sized programs (say up to five or six sub-teams).

  • Small Agile Teams = 2-15 persons

    • Small DAD Team:

      • Team Members

      • Product Owner

      • Team Lead (an evolution of Scrum’s Scrum Master role) and the Architecture Owner are often, but not always, the same person on small teams.
        This can be challenging because good Team Leads need solid persons and leadership skills whereas good Architecture Owners need solid technical skills and knowledge of the existing infrastructure and it can be hard to find all of these in a single person.

    • Supporting Cast:

      • Technical Expert(s)

      • Domain Expert(s)

      • Independent Tester(s)

      • Integrator(s)

  • Medium Sized Teams = 25-30 persons

    • DAD Team:

      • Team Members

      • Product Owner

      • Team Lead

      • Architecture Owner

      • Specialist(s)

    • Supporting Cast:

      • Technical Expert(s)

      • Domain Expert(s)

      • Independent Tester(s)

  • Medium-Sized Team-of-Teams/Programs = 12-50 persons

    • DAD Subteam(s):

      • Team Members

      • Product Owner

      • Team Lead

      • Architecture Owner

      • Specialist(s)

    • Supporting Cast:

      • Technical Expert(s)

      • Domain Expert(s)

      • Independent Tester(s)

      • Integrator(s)

  • Large-Sized Team-of-Teams/Programs = 35+ persons

    • Leadership Team:

      • A Product Management (or Product Ownership) strategy where the Product Owners coordinate their activities

      • An Architecture (or Architecture Ownership) strategy where the Architecture Owners coordinate their activities

      • A Product Coordination (or Management) strategy where the Team Leads coordinate their activities.

      • An optional Program Manager/Coordinator, a specialist role, is responsible for coordinating the overall leadership team.

    • DAD Subteam(s):

      • Team Members

      • Product Owner

      • Team Lead

      • Architecture Owner

      • Specialist(s)

    • Supporting Cast:

      • Technical Expert(s)

      • Domain Expert(s)

      • Independent Tester(s)

      • Integrator(s)

Nexus [20]

Nexus

  • 3-9 Scrum Teams

  • Nexus Integration Team

    • 1 Product Owner

    • 1 Scrum Master

    • Appropriate members from the Scrum Teams (with the necessary skills and knowledge to help resolve the issues the Nexus faces at any point in time)

The Nexus Integration Team is accountable for ensuring that a done Integrated Increment (the combined work completed by a Nexus) is produced at least once a Sprint. It provides the focus that makes possible the accountability of multiple Scrum Teams to come together to create valuable, useful Increments, as prescribed in Scrum. Membership in the Nexus Integration Team takes precedence over individual Scrum Team membership. As long as their Nexus Integration Team responsibility is satisfied, they can work as team members of their respective Scrum Teams. This preference helps ensure that the work to resolve issues affecting multiple teams has priority.

Scrum@Scale [21]

Scrum Team = < 10 persons

  • Scrum of Scrums (SoS)

    • 4-5 Scrum Teams

    • Product Owner Team

      • Scrum of Scrums Master

      • Chief Product Owner

    • Metascrum

  • Scrum of Scrum of Scrums (SoSoS)

    • Multiple Scrum of Scrums

    • Executive Action Team

      • Scrum of Scrum of Scrums Master

      • Product Owner

    • Executive Metascrum

Crystal [22]

Various methodologies in the Crystal family also known as weights of the Crystal approach are represented by different colors of the spectrum:

  • Crystal Clear = 1-6 persons
    Suitable for short-term projects where members work out in a single workspace.

  • Crystal Yellow = 7-20 persons
    Feedback is taken from Real Users. This variant involves automated testing which resolves bugs faster and reduces the use of too much documentation.

  • Crystal Orange = 21-40 persons
    The team is split according to their functional skills. Here the project generally lasts for 1-2 years and the release is required every 3 to 4 months.

  • Crystal Orange Web = 21-40 persons
    Projects that have a continually evolving code base that is being used by the public. It is also similar to Crystal Orange but here they do not deal with a single project but a series of initiatives that require programming.

  • Crystal Red = 40-80 persons
    Teams can be formed and divided according to requirements.

  • Crystal Maroon = 80-200 persons
    Large-sized projects where methods are different and as per the requirement of the software.

  • Crystal Diamond & Sapphire
    This variant is used in large projects where there is a potential risk to human life.

Spotify Model [23]

Squads (typically 6-12 persons)

A Squad is similar to a Scrum team, and is designed to feel like a mini startup. They sit together, and they have all the skills and tools needed to design, develop, test, and release to production. They are a self organizing team and decide their own way of working – some use Scrum sprints, some use Kanban, some use a mix of these approaches. Each squad has a long term mission such as building and improving the Android client, creating the Spotify radio experience, scaling the backend systems, or providing payment solutions. A squad doesn’t have a formally appointed squad leader, but it does have a product owner.

Tribes ⇐ 100 persons

A tribe is a collection of squads that work in related areas – such as the music player, or backend infrastructure. The tribe can be seen as the “incubator” for the squad mini startups. , and have a fair degree of freedom and autonomy. Each tribe has a tribe lead who is responsible for providing the best possible habitat for the squads within that tribe. The squads in a tribe are all physically in the same office, normally right next to each othereach other, and the lounge areas nearby promote collaboration between the squads. Tribes are sized based on the concept of the “Dunbar number”, which says that most persons cannot maintain a social relationship with more than 100 persons or so (the number is actually larger for groups that are under intense survival pressure, which isn’t really the case at Spotify, believe it or not…​). When groups get too big, we start seeing more things like restrictive rules, bureaucracy, politics, extra layers of management, and other waste. So tribes are designed to be smaller than 100 persons or so.

Chapters and Guilds

This is the glue that keeps the company together, it gives us some economies of scale without sacrificing too much autonomy.

Chapter

The chapter is your small family of persons having similar skills and working within the same general competency area, within the same tribe.

Guild

A Guild is a more organic and wide reaching “community of interest”, a group of persons that want to share knowledge, tools, code, and practices. Chapters are always local to a Tribe, while a guild usually cuts across the whole organization. Some examples are: the web technology guild, the tester guild, the agile coach guild, etc.

shadow-left