# Scaling Agile Without a Framework: How Organisations Find Their Own Rules

Author: Marin Niehues, Niehues Consulting · Published: 2024-03-21 · Transformation & Change
Source: https://www.niehuesconsulting.de/en/blog/agile-scaling-without-framework/

Scaling agile works without a framework when an organisation answers five questions itself: how teams are cut, at what cadence they work, how dependencies are resolved, how goals flow and who decides where. The answers produce a short set of rules that fits the organisation. A framework remains an option once the number of teams and the dependencies between them overwhelm self-organisation.

This article describes how organisations develop their own rules for working with many teams, compares the well-known scaling frameworks by field of use and provides a checklist for testing a rule set for effect. The pressure to adopt a framework is real: consulting offers and certifications as well as competitors put decision-makers under pressure to act. The decision needs criteria.

**A rule set for many teams is effective when every rule solves an observed problem, has an owner and carries a date on which it is reviewed or abolished.**

## Why is Scrum alone not enough for many teams?

Scrum alone is not enough for many teams because the Scrum Guide describes a single team. The 2020 guide regulates the roles and events as well as the artefacts of one Scrum Team with a product owner, a scrum master and developers. How several teams work on one product, how they resolve dependencies and who sets priorities between them remains open. Scaling frameworks fill this gap, and this is where an organisation decides whether to adopt a ready-made rule set or to develop its own.

The question arises at a concrete threshold. For up to five or six teams working on one product, a shared backlog, a shared rhythm and a regular coordination meeting are usually sufficient. Beyond that, the number of dependencies grows faster than the number of teams, because every team can need contact with every other. How these dependencies can be handled is described in the article on [Big Room Planning](/en/blog/big-room-planning-dependencies/).

## Which scaling frameworks exist, and what are they for?

The widespread scaling frameworks are the Scaled Agile Framework (SAFe), Large-Scale Scrum (LeSS), Nexus and Scrum@Scale, and they differ in how much they prescribe. The following overview sorts them by field of use and prerequisite, based on the authors' primary sources.

**Scaling frameworks at a glance**
Criterion | SAFe | LeSS | Nexus | With Niehues Consulting
Origin | Dean Leffingwell, Scaled Agile, Inc. | Craig Larman and Bas Vodde | Ken Schwaber, Scrum.org | Own rules from the delivery perspective
Scope of prescription | Extensive, with roles and levels as well as events | Lean, few rules on the basis of Scrum | Lean, extends Scrum with an integration layer | Only rules with an observed problem
Suited to | Large groups with many teams and fixed development cycles | One product with several teams and willingness to simplify | Three to nine Scrum Teams on one product | Situations that no recipe fits exactly
Prerequisite | Capacity for rollout and training | Willingness to change the organisation | Good Scrum practice in the teams | Leadership that owns the rules
Check question | Does the scope match the problem? | Are we ready to simplify structures? | Do all teams work on one product? | Which problem does this rule solve?

The rollout steps are similar: a pilot with a few teams, training of those involved, establishing the shared rhythm and then gradual extension. The difference lies in how much is prescribed. With SAFe you adopt a scaffold with many building blocks, with LeSS and Nexus a lean rule set. Scrum@Scale by Jeff Sutherland extends Scrum with repeating cells of teams. None of them is wrong. A framework becomes a problem when it is introduced as a whole before anyone has named the problem it is meant to solve. What this pattern looks like in organisations is described in the article on [method FOMO](/en/blog/method-fomo-companies-chasing-every-new-framework/).

## How do organisations develop their own rules for many teams?

Organisations develop their own rules by clarifying five building blocks in turn: team cut, rhythm, dependencies, goals and decision rights. Each block answers a problem that teams actually have in operation, and the answers come from well-known sources that can be adopted one by one.

**Five building blocks for a rule set of your own**
Criterion | Question | Source of ideas | Example of a rule
Team cut | Which teams do we need so that work flows without handovers? | Team Topologies by Matthew Skelton and Manuel Pais, 2019 | Each team owns a product stream from requirement to operation
Rhythm | At what cadence do all teams work? | Scrum Guide 2020, sprints as a time frame | All teams start and end their periods on the same day
Dependencies | How do dependencies become visible and get resolved? | Big Room Planning, dependency board | Every quarter all teams plan together, open dependencies sit on one board
Goals | How do priorities flow from the executive team to the teams? | Flight Levels by Klaus Leopold | Quarterly goals are visible to every team and have an owner
Decision rights | Who decides what without asking? | unFIX by Jurgen Appelo, Beta Codex by Niels Pfläging | Decisions within a budget and a quality rule are taken by the team

The order follows a logic. Team cut comes first because Conway's observation of 1968 holds: organisations build systems that mirror their communication structure. A poor cut creates dependencies that no rule can heal. The article on [Team Topologies](/en/blog/team-topologies-organising-teams-for-flow/) describes how to cut teams along the flow of work. For visibility of work across several levels, the model of [Flight Levels](/en/blog/flight-levels-coordinating-work/) helps, and for the distribution of decisions the unFIX model offers building blocks.

**Checklist for a rule set of your own**
1. Which observed problem does the rule solve, and which figure evidences it?
2. Who owns the rule and decides on changes?
3. When is the rule reviewed, and when is it abolished if it has achieved nothing?
4. Which indicator shows after one quarter whether the problem has become smaller?
5. How many rules apply in total, and do they fit on one page?
6. Who in the organisation knows the rules well enough to explain them to new colleagues?

## How many teams can a rule set of your own handle? The calculation

A rule set of your own suffices as long as the number of dependency pairs stays manageable, and that number can be calculated. With n teams there are at most n times (n minus 1) divided by 2 pairs that may need each other. What matters is how many of them have dependencies in practice. The following example is illustrative.

**Dependency pairs by number of teams**
Criterion | 4 teams | 8 teams | 16 teams
Possible pairs | 6 | 28 | 120
Of which with a dependency, assuming a quarter of pairs | 1 to 2 | 7 | 30
Coordination format | Shared backlog, weekly sync | Shared quarterly planning, dependency board | Several groups with their own planning and a shared level above
Own rules suffice | Yes | Yes, with discipline | Only with a proven rule set and experienced leadership
Examine a framework | No | As numbers grow | Yes, as an option

The figures are a calculation aid and not a study. They show that the coordination load grows with the square of the number of teams, and that the answer to this growth is grouping: teams that share the same dependency belong in one group with its own coordination. The result can be reached without a framework if the cut is right and somebody maintains the rules. The first lever is therefore the cut, the second the coordination format, and only the third the question of a framework.

## When is a framework worth it after all?

A framework is worth it when more than about a dozen teams deliver together, managers need a shared language and the organisation has capacity for a comprehensive rollout. A practical reason comes on top: where many newcomers must be brought up to speed in a short time, a documented rule set with training offers saves time. The order of magnitude is a rule of thumb from practice and not a figure from a study.

Even then, begin with the problem and select the building blocks that solve it. A framework can be adopted step by step, and every adoption gains when it is tied to an indicator. The same principle applies to the Spotify model, which Henrik Kniberg and Anders Ivarsson described in 2012 as a snapshot of the way of working at Spotify. It shows ideas that suited one company with its culture and size, and whoever copies it adopts the answers to questions that Spotify asked.

## Own rules for scaling agile with Niehues Consulting

[Niehues Consulting](/en/) is a consultancy for AI management and organisational design from the delivery perspective, based in Düsseldorf. Founder Marin Niehues builds organisations that deliver, in projects from VC-funded scale-ups to DAX-40 corporations and in more than 20 countries on six continents. In the service area of delivery management and organisational design he works on team cut and on decision paths as well as interfaces, so that rule sets fit the organisation and hold in everyday work.

The approach follows the Niehues Delivery Model. For scaling agile, three of its check questions matter: Who decides, who delivers, who uses? Which roles and decision paths as well as interfaces does operations need? Which indicator shows after 90 days that the solution is taking hold? The scope and terms of an engagement are discussed in the free initial consultation, which lasts 30 minutes and can be booked through the [contact page](/en/#kontakt).

**Conclusion**
Scaling agile begins with the cut of the teams and a lean rule set in which every rule solves an observed problem and has an owner. A framework remains an option for large groups. Whoever counts the dependencies beforehand decides with criteria.

**Sources**
- Schwaber, Ken; Sutherland, Jeff: The Scrum Guide, 2020
- Skelton, Matthew; Pais, Manuel: Team Topologies, book, 2019
- Conway, Melvin: How Do Committees Invent?, article, 1968
- Kniberg, Henrik; Ivarsson, Anders: Scaling Agile @ Spotify, white paper, 2012
- Larman, Craig; Vodde, Bas: Large-Scale Scrum: More with LeSS, book, 2016
- Schwaber, Ken: The Nexus Guide, Scrum.org
- Scaled Agile, Inc.: Scaled Agile Framework, framework documentation

## Frequently asked questions

### What does scaling agile mean?

Scaling agile means extending agile ways of working to many teams that work together on one product or portfolio. The Scrum Guide describes only a single team, so additional rules for coordination and prioritisation are needed. These rules come from frameworks or from your own agreements.

### Do I need SAFe for several teams?

For up to about eight teams SAFe is usually unnecessary. A shared rhythm, shared quarterly planning and a dependency board are enough, and with four to six teams a shared backlog often suffices. With a dozen teams or more it is worth looking at a framework.

### What is the difference between SAFe, LeSS and Nexus?

SAFe is an extensive framework with levels and events, while LeSS and Nexus are lean extensions of Scrum. LeSS simplifies the organisation, and Nexus adds an integration layer to Scrum for three to nine teams. Which one fits depends on size, product structure and willingness to change.

### Can you adopt the Spotify model?

The Spotify model describes, in its authors' words, a snapshot of the way of working at Spotify in 2012 that kept evolving. Individual ideas such as squads and chapters can be adopted if they solve a problem in your organisation. A complete copy transfers answers to another company's questions.

### How many teams can you coordinate without a framework?

Up to about eight teams can be coordinated with your own rules if the cut is right and a shared rhythm and a dependency board exist. With sixteen teams a proven rule set with experienced leadership is needed. The number is a rule of thumb.

### How do you write down your own rules for agile teams?

For each rule, write down the observed problem, the owner, the indicator and a review date. All rules should fit on one page. Rules without effect are abolished after one quarter.

### Who decides on the rules?

Leadership decides on the rules together with the teams, and each rule has a named owner. Teams propose changes, and the owner decides after checking the indicator. This keeps the rule set alive and traceable.

### What role does Team Topologies play in scaling?

Team Topologies provides criteria for cutting teams along the flow of work, with four team types and three interaction modes. The cut reduces dependencies before rules have to manage them. It is therefore usually the first building block of a rule set of your own.