Model: Agile Fluency = ‘scale out’, making value streams smaller, until they fit into one team. Model: Scaled Agile Framework (SAFe) = ‘scale up’, adding more people to the same value stream.


In Model: Agile Fluency the distinction is clearly visible when we look through the lens of team composition. Model: Agile Fluency is scaling out. It creates small teams that are self-sufficient. Slicing the value stream smaller where needed. Changing the organisation’s structure. (including business people’s!) So everything in the organisation is aligned to these smaller value streams. It’s hard work:

  • slicing value streams as small as possible
  • bringing business expertise into the team
  • bringing business decision making into the team

Model: Scaled Agile Framework (SAFe) seems to want the benefits of Model: Agile Fluency’s third zone ‘optimising’. But without wanting to change the organisation structure for the business. It seems like they try to keep teams small. But they do this without the right ‘value boundaries’. (compare with Model: Service Boundaries) They don’t try to create a smaller value streams. So it’s impossible for each team to entirely own one or more value streams. This is visible from their concept of ‘release train’

They seems to try to at least align their ‘Release Train’ around value streams.

The Agile Release Train (ART) is a long-lived team of Agile teams
[...]
one or more solutions in a value stream.

They keep the teams inside a train, so at least one team does not have parts of multiple, of those large value streams. But not even this ’team of teams’ completely owns a value stream. Which makes me wonder: how many dependencies are there between different release trains?

Each is a virtual organization (typically 50 – 125 people) that plans, commits, develops, and deploys together.

From a service point of view (with service defined as ‘deployed together’) that means the entire ‘release train’ is one service. It may be spread over

  • multiple code bases
  • multiple teams
  • multiple separate servers

But there is so much coupling between each of those, that they need to be deployed together. So all that is one service. It sounds like what people would call a Model: distributed monolith This prohibits each team from moving at their own pace. And dependency between teams slows everything down.


Compare this to a small team in Model: Agile Fluency’s Agile’s Promise (zone 3)

  • that owns their value stream completely
  • that can deliver at their market’s (value stream’s) cadence
  • that can reconsider, react, reinvent what they are building at any time
  • that does not have any external dependencies to wait on

Now this sounds scalable!


It sounds like, Model: Scaled Agile Framework (SAFe) is trying to ‘scale upwards’, adding more people to the same value stream. While Model: Agile Fluency is trying to ‘scale outwards’, making value streams smaller, until they fit into one team.

And scaling out, scales much better than scaling up. ./resources/opinion-scaled-agile-framework-safe-scales-the-wro.resources/screenshot.png (slide edited from: Video: The Future of Software Engineering - Mary Poppendieck)