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

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.

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.

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.

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.

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.

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 describes how to cut teams along the flow of work. For visibility of work across several levels, the model of Flight Levels helps, and for the distribution of decisions the unFIX model offers building blocks.

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.

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