"Agile" in a form that large corporations feel that it's safe to adopt "Agile" in. About 15 to 20 years late at that. It's really just the old big Corp consulting gigs but for Agile.
Don't get me wrong, SAFe does have agile concepts in it that make sense overall. But the whole "let's do a strict process and let's do it wrong and let's enforce it rigorously without thinking" is just corporate BS all over but this time with "Agile" written at the top instead of "Rational Unified Process" or whatever else your corporation might have paid consultants for before.
Like what exactly?
I will assume that you do accept that Agile overall has sensible elements. Here are some of those that do appear in SAFe. The way SAFe goes about packaging and advertising them: questionable to say the least. As would be customary when we're trying to appeal to a large corporation that wants to feel safe and minimize divergence from processes that can be applied by exchangeable cogs in the machine.
A release train
Continuously releasing functionality in small increments makes a lot of sense to me and is part of certain Agile principles. Kanban and WIP limits
Believe it or not, they mention this. Of course they do, they want to appeal to ops teams. Kanban makes a lot of sense to me. Personally I use it on my teams whenever I'm allowed/able to where we do away with Story Points and just size things about the same into vertical slices. Of course I'm in a constant fight w/ "corporate" about hard deadlines and the "need to estimate" and they don't understand lead and cycle time and how you can estimate using those w/ same-sized tasks sigh Refactoring
Yes, they include refactoring as a topic of note. Isn't that awesome? :P It's amazing how much text (and training you can sell I'm sure!) you can write on the simple fact that refactoring may be necessary at some point. XP refactoring mercilessly anyone?FAANGs operate at mega scale and have the luxury of enough time and resources to create customized methodologies which ideally suit their unique circumstances. But most software organizations can't afford to hire experts to build up custom methodologies (or they wouldn't know whom to hire even if they could afford it). The benefit of something like SAFe is that it's "good enough" for less sophisticated organizations to adopt off the shelf and move forward. And if you look inside the FAANGs you'll see that they essentially do follow many parts of SAFe although they tend to call things by different names and hide some of the gory details from lower-level ICs.
I haven't done any federal government work but I've seen large government contractors successfully apply SAFe. They aren't making sprint plans more than 3 months in the future.
Again, SAFe isn't anything particularly wonderful. It's just a reasonable starting point that represents accumulated industry best practices for large enterprises with a lot of complex moving parts. Much of the criticism is simply uninformed. Anyone who wants to criticize it should at least cite the relevant section (everything is publicly documented) and explain why that part is unnecessary or suboptimal from an overall business perspective.