Does SAFe make you slow and passive?

SAFe, the Scaled Agile Framework, promises to efficiently scale agile organizations. SAFe cultivates methods like Scrum, Kanban and Design Thinking into a logic that works in the context of a large enterprise. Sounds too good to be true? Yes, because most of the time it is not quite that simple.

Working with SAFe is a clear trend in large-scale companies. And with any trend, caution is advised. Not applied correctly, the supposedly agile framework can quickly make companies more complicated and sluggish. The pure opposite of the actual goal.

Why is SAFe slowing down organizations?

SAFe is a great orchestration framework. It seamlessly integrates with business strategy, derives it down to the feature level, and manages dependencies between different teams. However, product owners in particular often notice that even after implementing SAFe, their teams are not faster than before.

So, where did all the anticipated efficiency go?

Well: The fact that projects are not implemented with the desired speed is due to too many dependencies. These are very difficult to circumvent, especially in large corporations.

To "manage" the different Scrum teams' dependencies, SAFe visualizes the connections between the teams in the Product Increment Planning (PI Planning) and integrate them into their individual work planning. These dependency diagrams often look like London Heathrow's flight radar.

What happens? In the team-internal planning, those dependency stories are prioritized ahead of the team's own stories. This should avoid blockages.

So getting rid of other teams' dependencies has high priority. And as more dependencies I have to solve as a team, the less I get closer to my own goals. That slows teams down.

I have been observing this conflict for some time now. And the frustration about managing dependencies is also a trending topic in Agile blogs. Articles with titles like "Stop Managing Dependencies!" or "Eliminate Dependencies, Don't Manage Them" are not uncommon. So the question is: How do we eliminate these dependencies?

Not easy at all. But an approach that works is the following:

Only validated stories are allowed to produce any dependencies to other teams!

What does that mean in concrete terms? The product with the highest portfolio relevance has priority. But going a level deeper is key: What customer problem does a user story solve and what dependencies does it cause?

This quickly leads us to the follow-up question of whether a user story provides any customer benefit at all - and if so, how great is it?

We therefore consistently validate user stories before other teams are burdened with solving dependency stories. Otherwise, we run the risk that some complex product feature will not provide any customer benefit at all and that we will simply slow down other teams with our dependency story. In Kaizen, this is called "waste".

In the beginning product teams often know very little about their customers.

Especially when testing new products on the market, product teams initially know very little about their customers. This leads to wrong assumptions being made and features being built that are not interesting for any customers.

If interviews or surveys are conducted, this is certainly better than simply guessing. But there are also cases with substantial differences in user behaviour. This is especially true when the number of customers surveyed is rather small. The implication: we rely on a few customer statements. This can quickly lead to the development of irrelevant features.

The easiest way to avoid falling into this pit is to develop first all feature as "lean" as possible and with an MVP approach. After publishing, we then measure real user behaviour using product analytics such as Amplitude.

If a feature's relevance could be confirmed, it can be built in a "corporate SAFe manner". At that time requesting dependency stories that other teams have to solve are ok. However, waiting until the entire product has reached a certain maturity is recommended. Once this is achieved, we integrate several features at once. But not before!

With this approach, you only implement dependency stories that are relevant to your customers.