I am probably 95% in line with this, SAFe is mostly terrible, but there are some nuggets in there that I think are good. Mostly around the cadence and checkpoints on progress in delivery. (Yes, we can argue whether some of these things originated with SAFe, but it's how I was originally exposed, so that's how my mental model is mapped.)

- Quarters (every 12 weeks): Big ticket things that should move the business forward. This requires Engineering participation because items like technical debt, system re-architectures, pipeline improvements, etc. should be on the table. - PI (every 3-4 weeks): Light checkin on progress to current items. A ballpark estimate on what can be delivered in the upcoming PI given the current constraints (capacity, quality, etc.). This works out to 3-4 checkpoints per quarter. - Sprint (every 1-2 weeks): Real commitments to tangible requirements are made here. If thorough discovery leads to changes to the ballpark estimates or development is delayed for other reasons, it is communicated at the PI checkpoint and forecasts can be adjusted.

(imo) SAFe is just a solution to problems that may or may not actually exist - eager-beaver middle management-types adopt it chiefly because they think it makes them look good, but also because Product/Engineering teams don't commit-escalate-communicate well.

I encourage folks to take a step back and ignore the specific SAFe guidance, but do consider the value of the inputs & outcomes.