One blogger recently wrote, "I suggest they put aside SAFe and instead focus on developing an Agile mindset within teams." I agree that diagrams such as SAFe can be daunting to development teams, and that most agile approaches work on getting the development teams to function effectively within themselves.
From one viewpoint, this make absolute sense. From another viewpoint, it promotes navel-gazing. It also encourages the introduction of the Business Analyst, a non-agile animal I first encountered years ago, used as an excuse to charge high consultant fees for someone who couldn't actually contribute to the development effort. This animal, in turn, has largely supplanted the Systems Analyst, that person who knew both the client space and the technical space extremely well. And one agile method, Scrum, has created that animal known as the Product Owner, who is supposed to avoid disruptions to the team but in fact usually is a bottleneck.
The navel-gazing and bottlenecks result from attempts to filter out complexity. Certainly over-complexity causes runaway projects and hampers getting useful code completed. But I disagree that SAFe automatically adds such complexity.
SAFe simply acknowledges complexities already in place, and tries to help manage them. Some of the entitites on the SAFe chart are regarded as unimportant, nonexistant, or some form of magic by many developers, but they still are real and have to be dealt with by somebody.
If you are a Spotify or Netflix, many of the elements on the SAFe chart may represent bloat. If you work with high technology systems-of-systems, however, then those entities are realities to be dealt with. Money doesn't come from thin air. Authority to spend that money is not an automatic entitlement. You don't debug workable architectures into being. Capital and Operational budgets don't disappear just because development teams don't manage them. Integration doesn't go smoothly simply because you wish it to or are a hot-shot code writer.
Early in my career, I worked on what now are regarded as "X teams." We owned all aspects of development, architecture, customer relationship, proposing, winning, spending, delivery, support, and so on. We had profit-loss responsibility, and a lot of leeway in making decisions -- or at least making recommendations -- about capital and operational expense. Most of the components in the SAFe diagram were part of daily life. We weren't insulated from them.
I would agree that junior developers probably should focus on learning to operate as an agile team. But a team that stops there stagnates and relegates most of its members to "code-slinger for life" status, which does not suite 100% of the coder population. Worse, it can encourage a career-long attitude as a order-taker, not a participant in creating business value.
I'm not at all proposing that SAFe is perfect - I have heartburn over a few elements - but the scope of its vision can be useful. Maybe the best approach to SAFe is not a binary good/bad evaluation, but a consideration of which elements are "immovable objects" in many business environments, and evaluating how to help developers mature their ability to comprehend and engage with the various components -- and maybe even take a hand in improving them.
A time-worn quote (almost worn out by now) goes, "All models are flawed; some happen to be useful." (George E. P. Box)
If used literally and inflexibly, SAFe can manifest its flaws pretty quickly. But used intelligently, it can be a useful model to consider how to scale agile for large systems/systems-of-systems while being cognizant of those external realities that impact the life of development teams.