All the Scrum fans are going to jump on this. They will say "you don't understand Scrum", or "you are siding with traditional hierarchical approaches", etc.

It's tough to criticize something that so many people have invested so much in (Scrum). They become vicious.

But the author is right. Scrum doesn't scale - that's why they had to invent Enterprise Scrum. Scrum is about a little team creating a simple little product that one PO can wrap their head around.

SAFe is about building complex systems - like turbine engines or tractors - things that have not only tens of independently operating computers in them with embedded real time software, but that have real moving parts, and that send massive amounts of real time data back to data centers for telematics. Sorry, but Scrum does not work for that.

Like Scrum - or Agile in general - the problem is less with the practices that it defines: the problem is with how people adopt them. SAFe suggests a set of practices. You don't have to use them all. They are just ideas.

I personally don't like the PI planning ceremony: I think it is an expensive waste of time and energy. There are better ways to achieve cross-team collaboration and integration (that's a long topic so I won't go into it). But I do like SAFe's Lean Portfolio, which they borrowed from elsewhere - nothing wrong with that.

If you view SAFe as a prescriptive process, that's your problem - not SAFe's problem. Yet so many Scrum fans view Scrum as something to be followed to the letter - exactly the complaint they make about SAFe for being to prescriptive.

The best approach, IMO, is to view ALL of these methodologies/frameworks as mere sets of ideas, and from those, compose your own approach. And treat it as a learning journey - not a process change.