Approval gates in Agile delivery teams

Question

Our business unit is currently transforming into an agile organization, forming long-lived product/process-centric teams - I will refer to them as squads. However, coming from a very governed, gated, waterfall model, there's some shared teams that currently are still required to give approval for changes. The most obvious of these gates are: Information Protection, Architecture

Ideally, we would have a representative of these teams in each of the squads, but

1. they don't have enough resources
2. there probably isn't enough work for them in a single squad to warrant a full-time resource

I'm seeing the following options

1. keep the gates as they are now. This would mean that every change will need to get formally improved by these teams, and the work can't start before that stamp of approval is received. Previously, they would give that approval on a project basis, now they would have to start doing that on feature or story level. I'm assuming that this will introduce a massive delay, which sounds very sub-optimal
2. try to convince the teams in having a representative in some recurring meetings, where they can either directly give the approval (per story/feature/epic) or identify some take-away work for them. Backlog Refinement is most likely the best moment for this. This would mean that these teams should at least make them available once per week, per squad. Not sure what should happen if they decide not to show up. It probably would mean that Definition of Ready is not met, and work can't start.
3. move the approval gate from "before the work starts" to "before the increment is released into production". This would allow squads to make assumptions regarding security, design, etc - and it will be up to the Architecture & Security Protection team to make sure they conduct a review at any time before it goes live. Maybe they can attend Sprint Review sessions, or they can conduct offline reviews however they see fit. The risk I'm seeing here is that their feedback might come quite late into the process, resulting in more rework than needed. Additionally, it also feels like a delay in creating value, just in a different part of the process.

Which of these options make most sense, or which option am I not thinking about? Are you working in similar set-ups, and do they work? All feedback and/or reading material is greatly appreciated!

Answer 1

If I had anything to say about it, I would aim for a variation of your option 2.

During the refinement meetings of each squad, a team member from the Architecture & Security Protection team joins the meeting to identify which stories need explicit approval from the Architecture & Security Protection team and which stories don't.

Then, when somebody starts to work on a story that needs explicit approval, they would first create a design and discuss that with the Architecture & Security Protection team before starting to write actual code.

In my perception, a large portion of the stories probably don't need the formal approval, because their changes don't touch on architectural or security issues.
For the stories that do need approval, the process can be made faster by preparing a proposal within the squad and reviewing that.

Answer 2

Scrum of Scrums facilitates cross-team coordination

Your second option:

try to convince the teams in having a representative in some recurring meetings

is a well established scaling approach called Scrum of Scrums. Here is one reference by Mike Cohn outlining this approach.

You are rightly perceiving the risk in the third option:

The risk I'm seeing here is that their feedback might come quite late into the process

I wouldn't recommend this approach at all. Trying to get approval even though the requirements are not known, is a formula for disaster.