The idea of bringing dependent teams together to collaborate better and minimize cross-dependency overhead isn’t new.

It's a fractal of the pattern of an agile cross-functional team, which Agile hasn’t invented either, just leveraged.

Whether you call these Tribes, Scrum of Scrums, ARTs, doesn't change the essence - Organizing around value.

Here’s how you might go about it:

• 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 teams of teams (ARTs, Tribes, scrum of scrums, or Product groups)
• Ideally, each of these should own a significant strategic theme for the organization or a primary 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, the architecture will look like iron spaghetti, people will be pretty 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. Scaling frameworks such as SAFe even have 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 be able to fully descale, 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…)

​Read When and How To Organize Your Agile Release Trains (ARTs) On Your Browser​

​

Yours,

Yuval
​
​

Yuval Yeret​
Streamlining Product Innovation at Scale
Agile Fixer | Scaled Agile Fellow | Professional Scrum Trainer
​Let's connect on Linkedin​
​Let's find time to chat​
T: 617-356-7093