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…)

Shouldn’t your ability to build great products IMPROVE as you scale, rather than stall out?

Introducing The Product-Oriented Portfolio Agility Trail Map -

A practical, no-fluff email course where leaders of growing organizations and practicing portfolio leaders will learn the foundational practices of multiple-product/portfolio product-orientation and agility so they can start evolving from a feature factory managing scattered investments to creating a product-oriented mega-lab that drives growth, value, and resilience.

    You'll Get The Trail Map Over 7 Days. Unsubscribe at any time

    Scaling w/ Agility Insights For Leaders

    Are You Struggling to Scale Your Organization?
    Need agility but dubious of process BS/dogma?

    I can help you think through scaling challenges and develop/grow organizations using product and agility principles and practices.

    Subscribe for thoughtful, reflective, pragmatic, principled takes on how to approach scaling your organization leveraging the essence (rather than theater) of product operating models, agile practices and frameworks, and business operating systems such as EOS and Scaling-up.

    (Not sure? Browse the archive)


    I respect your privacy. Unsubscribe at any time.

    Has Scaling Up Made Your Slower?
    Regain Organizational Traction At Scale

      Chart Your Path To A Product-Oriented Agile Portfolio