Part IV. Value, measurement and more than one team

More than one team: the minimum you need to add

Nexus, SAFe and Flight Levels without the catalogue

The deliveries collide

To meet the goal of retaining members, GymTonic set up a second team: bookings and payments, with Ismael as Product Owner. It made sense. GymApp couldn't keep up, and bookings were the heart of the app.

Three weeks later, the deliveries started to collide. The GymApp team was changing the booking screen to improve the waiting list while the payments team was changing the same screen for the new provider. Both used agents, both delivered fast and both broke each other's work. In one week there were four urgent fixes.

When you need to scale

You need to scale when one team can't keep up with developing a product, even after trying to push its productivity as far as it will go. If more teams join the work and they depend on each other, they have to coordinate to move forward without colliding.

The first question is not which framework to use, but how the teams are split. Teams are organised around the value stream, not around technical layers. A "screens" team and a "server" team have dependencies on every item. Two teams that each own a complete member journey have far fewer.

GymTonic had split well on paper, with bookings on one side and the app on the other, and badly in practice: both touched the booking screen.

Nexus, the minimum

Nexus is the simplest way to scale Scrum. It is designed for three to nine teams working on the same product, with a single Product Owner and a single Product Backlog. It adds little:

A Nexus Integration Team, responsible for making sure everyone's work is integrated into an Increment that works.
Shared Product Backlog refinement, where dependencies are detected before they reach the Sprint.
Short, shared events: one planning, one integration Daily Scrum, one Sprint Review and one Sprint Retrospective for everyone.

With two teams, GymTonic was below the formal minimum for Nexus, but its problem was exactly the one Nexus solves: nobody was responsible for integration.

SAFe, when there is a portfolio

SAFe makes sense when there are many teams, a portfolio of initiatives and budgets to decide. It groups teams into trains, which are value streams, and plans them together every few weeks in PI Planning.

With AI, PI Planning changes in one way: prototypes come into the room. What used to be a discussion about an idea can now be a discussion about something that works. That helps decision-making, as long as nobody mistakes a prototype for something validated.

Flight Levels, to see where things get stuck

Flight Levels is not a team framework, but a way of looking at where work is coordinated. It distinguishes three levels: operational (each team's work), coordination (what several teams have to coordinate) and strategic (which initiatives the company has and in what order).

Its value is diagnosis. Many blockages that look like a single team's problem sit at another level: two teams wait because nobody decides at the coordination level, or ten initiatives move forward at once because nobody says no at the strategic level.

Diagram. Where work is coordinated. Many blockages that look like a single team's problem sit at another level. Strategic: which initiatives and in what order; Coordination: what several teams coordinate; Operational: each team's work. Nexus: 3 to 9 teams, one product; SAFe: many teams and a portfolio. With AI each team makes more changes, and every change can collide with another: more coordination at the middle level, not less.

The release plan for several teams

With several teams, the release plan needs to show the dependencies. AI is very useful here: it can read everyone's backlogs, detect which items touch the same parts of the product and flag collisions before they happen. At GymTonic it would have seen during refinement that both teams were going to touch the booking screen.

What it doesn't decide is the order. What goes first when two teams need the same thing is a product decision, and the Product Owners make it together.

AI does not reduce coordination

It's worth dismantling one idea: that with AI you need less coordination because each team can do more on its own. The opposite happens. AI increases the number of changes, and every change can collide with another. More changes means more coordination, not less.

GymTonic solved it with little: a joint refinement every week, one person from each team responsible for integration and a written rule about who changes the booking screen. Urgent fixes dropped to one a month.

In short

Scale when there are dependencies that collide, not before. Organise teams around the value stream. Nexus for the minimum, SAFe when there is a portfolio and Flight Levels to see where things get stuck. AI detects the dependencies; people decide the order.

Try it this week

Draw your three flight levels and mark where each important decision is made. Wherever nobody is deciding, that's where the work gets stuck.