ART Design - and: Solving the wrong problems

It's amazing how good organizations are at solving the wrong problem, i.e. "doing the wrong thing righter". Here is a great example of how not to design an ART:

This was the outcome of a PI-Planning. Their planning Retrospective led people to conclude that "electronic tools are much better for developing a Program Board than physical boards, because the dependencies are way too difficult to correlate with all those strings floating around, falling off, getting intertwined and so on."

This Train operates based on the assumptions that they have the right ART, the right teams - and are working on the right things. Never did it cross anyone's minds that any of these assumptions might be wrong.

The wrong ART

The first question we need to ask ourselves: do we have the right Agile Release Train?
If there is an extensive dependence on people outside the Agile Release Train, or there's a massive capacity bottleneck within the ART, while people outside the ART do have capacity to do the blocked work, then we might want to slice the ART different.

The wrong teams

It's okay for teams to occasionally depend upon one another. It fosters learning and information exchange. Some Product Managers even go as far as to purposely define features in a way that "swarming" across teams allows the ART to generate value faster. When teams choose to split work  and collaborate in real time to maximize value generation, that's a plus.

What is not okay, and a clear indicator that we have the wrong teams: When no team can get any work done without relying on actions of other teams.

Even Component Teams should be able to release value straight into Production, when teams can only do piecemeal work, those are specialist teams that inhibit the flow of value.

I have seen more than once how teams, guided by experienced SPCs and insightful RTE's, have spontaneously used the PI-Planning to "disband and regroup" - reforming as teams capable of delivering end-to-end value: It's possible!

The wrong work

The above example is a clear example of what leads to doing the wrong work. With so many dependencies, "dependency management" is already a full-time job. It shouldn't be. It should be effortless.
The prime directive of dealing with dependencies is: "Minimize."

When I see two or three dependencies on a PI Planning board, I'm happy - it means, we have decent team constellations and the right skills in the teams.
When I see more than ten dependencies, I will express concerns about team constellation.
When I see more dependencies than features on the board, I would ask the ART to work on resolving their dependencies rather than figure out better ways to manage their dependencies.