When and How To Organize Your Agile Release Trains (ARTs)

The idea of bringing dependent teams together to collaborate better and minimize cross-dependency overhead isn’t unique to SAFe. It’s just a fractal of the pattern of an agile cross-functional team, which Agile hasn’t invented either, just leveraged.

Here’s how you might go about designing effective ARTs:

• Examine your work - what’s on the roadmap, what’s the vision, etc. - and how it will hit the different teams/groups in the organization.

• Look for ways to group teams that localize as much collaboration/dependencies as possible. It will never be perfect.

• These should be your ARTs (or Tribes, or scrum of scrums, or Product groups)

• Ideally, each of these should own a major strategic theme for the organization or a major product where they focus on the north star for that product and are empowered to explore, build, and deliver value in that area.

There will still be dependencies. Sometimes, even a lot. For most brownfield organizations where SAFe is considered, the architecture will look like iron spaghetti, people will be quite specialized, and to be honest, probably some of the groups you create won’t be ideal because of politics, siloes, and turf wars.

It’s tempting to add more and more processes to manage these dependencies across these ARTs/groups. SAFe even has patterns for doing that (Solution Trains etc. ) which makes it tempting.

Avoid that if possible.

Use these dependencies to start a conversation about (re)organizing around value.

Descale if you can. Scale if you must.

I’ve seen examples where a new ART was created to tackle a cross-cutting initiative because it made more sense than managing slices of it across multiple existing ARTs. It goes against the common principle of stable teams, but it’s a tradeoff sometimes worth making (no by-the-book prescription, just a set of principles to help guide you…)

The other thing to consider is architecture. Can we improve the architecture to break down some dependencies? Amazon avoided the need for ARTs through an edict to provide an API for everything so two-pizza teams can tackle their work with minimal/no dependencies on other teams.

Not many organizations are willing to do that. However, as leaders and practitioners, we should continue advocating for these interventions.

The bottom line is - creating an ART that brings together dependent teams might be the best you can do right now.

The north star is a topology where each agile team is as empowered and decoupled as possible, even within such an ART. And minimum situations where ARTs need to collaborate with others.

You might never get there, but keep trying if it makes economic sense.

PS In the Portfolio Agility Trail Map, I share a typical scenario where the portfolio lens is used to see the need for (re)organizing around value. This happens organically, almost inviting itself, rather than a big design upfront (you can imagine the change management benefits of that…)

Improving portfolio flow requires both the right practices and the right mindset. Explore Portfolio Agility advisory or let’s talk.