SAFe impressions from a LeSS Practitioner

I'm just now sitting through a 4-day SAFe 4.0 SPC course with Dean Leffingwell.
While I would not dare call myself a SAFe expert, I can at least say that I'm no longer making baseless assumptions about SAFe, but based on firsthand information from the source. Of course, being a CLP and aspiring CLT, I see SAFe through the biased goggles of a LeSS Practitioner. That does not mean I came to the course to bash it or nitpick, but to learn new/better ways of developing software and helping others to do so, from others who are doing that.

Here are some observations I made:

What I like

• There's a big level of overlap with LeSS. Examples? Systems Thinking, Optimize the Whole, Get Rid of Queues (where possible), Focus on Customer Value, Lean Thinking, Transparency. 
• SAFe emphasizes "U-Curve optimization", i.e. it suggests doing the best possible thing, which may be a compromize when the cost of further flexible outweighs the benefits thereof. That doesn't absolve you of actively seeking ways to reduce the costs caused by your inflexibility!
• SAFe suggests Co-Located Feature teams. It concedes that major structural impediments often can't be resolved on a short notice, so it offers a way to start with such maladies still in place.
• The "Dependency Map" on the Program Board (that scary red spider web) is NOT intended to actually help track and manage dependencies (though it can be used for that if you're masochistic) The primary goal is to create visibility so that people start thinking about resolving that mess.
• The "Coordination" part of SAFe are functions, not roles: No denying that a big picture and delivery capability are needed, and SAFe is not prescriptive about how exactly that's getting done.
• SAFe does not actually suggest having a separate System Team, but won't stop you from doing that if you can't do otherwise, 
• SAFe isn't really as concerned with what the teams do and how they work, as long as that's agile and follows a reliable cadence. But SAFe is concerned that everyone understands the impact of their actions on the overall (huge) system.
• SAFe addresses the entire Middle Management Layer in a huge corporation and provides them with a perspective, rather than stating "From now on, you're optional" (which reads to many as: disposable).
• One main concern of SAFe is reliable mid-term and long-term oganizational predictability, where "mid-term" is a Program Increment of 3 month, and long-term 2 or more thereof. Of course, non-development activities at a large scale need to have some reliability. Preparing a primetime TV campaign also takes effort.
• SAFe does actively address the issues of Enterprise Budgeting rather than taking the easy way out by descoping it.
• There is no "Big Batch Delivery": SAFe suggests "Release anytime", but concedes that for companies who previously could hardly release twice a year, release at Sprint's End is already a lofty goal. Again, it's about compromizing based on reality.
• A Program Increment is 5 Sprints, one of which is an IP Sprint (Innovation + Planning). The main purpose of this "non-development" Sprint is to engage mid-term forecasting and systematizing innovation. It's NOT a "hardening Sprint" or anything coming out of not really working agile.

Neutral

• You can boil down Essential SAFe to the Agile Release Train ("ART"). Not much magic there. We see the same in LeSS, although we call it the Product Group.
• SAFe is about as prescriptive as Scrum, in the sense that "you can customize it, but that's not SAFe". No need to get religious about calling it anyhow "un-agile" because of that.
• SAFe is actually not for everyone - it targets huge organizations who have trouble delivering, and for those companies it will be a way out of the quagmire.
• The "Value Stream" level of SAFe is not even interesting for Product Groups are less than 100 people. A Value Stream level synchronization actually only occurs when multiple E2E value streams, each bigger than 50 developers, coincide in 1 product. In LeSS, that's Requirement Areas.

Scrum Masters

• SAFe interprets the Scrum Master as facilitator and nanny of the team: the guy who has to get running when someone needs something - an HPQC (yuck!) license, for example.
• SAFe suggests using a "Scrum of Scrums" where Scrum Masters communicate impediments to each other, in the absence of teams. That's not so Gemba.
• SAFe actually suggests to try making Project Managers into Scrum Masters if at all possible. Some Scrum practitioners may have some animosities with that.
• Dean actually stated "Scrum Masters aren't really masters of Scrum after a 2-day course", so SAFe provides an environment that doesn't expect them to be, although it encourages them to learn more.

Product Owner

• SAFe' Product Owners are simply fakes. They are the bottom level in a 3-4 player hierarchy of Portfolio Managers, Solution Managers, Product Managers and finally Product Owners. They all do the bidding of so-called "business owners" who make the real shots. This is actually in conflict with the Scrum Guide!
• SAFe actually suggests making Business Analysts into PO's (not people from the business!). Some Scrum practitioners may have some animosities with that, as well.
• Dean actually stated "Product Owners don't own the Product, but it's a specific term that's widely used in the industry, so we stick with it for simplicity sake".

Teams:

• SAFe gives teams a lot of leeway as long as they keep the System (i.e. the Release train) rolling and actually keeps the organization out of their way as long as they are on board. SAFe might occasionally feel highly constraining when teams are unaware of their position as a cog in a much larger gear.
• SAFe emphasizes something called "subtle control", i.e. managers stay in charge, teams are NOT empowered or self-organized beyond where management lets them go. That actually does make sense until teams (who have never worked autonomously before) have learned to bear their responsibility. It takes a good coach to understand when this control is due and when it's undue.
• The first implementation of SAFe might not change the basic line structure of the organization, but rather "virtualize" the ART on top with team members still reporting into their original line. What this means for team autonomy, and therefore, decisive capability, depends on the organization.

Extra Roles:

• The Product Manager is not an "extra". They exist for exactly the same reason why APO's exist in LeSS - because you can't manage hundreds of PBI's in real time.
• Dean meets the idea of whether we need an RTE (i.e. Super-Scrum-Master) and Architect with an empirical statement of "Experience has shown that it's a good idea" rather than a religious "It's mandatory". 

Comparing SAFe with LeSS

SAFe doesn't really compare to LeSS: LeSS implies a Product Group below 72 people (no more than 8 teams, 6+/-3 people per team) while SAFe doesn't even have much of a case for less than 50 people. The comparison is, if anything, with LeSS Huge, which would be more concerned with Product Groups of hundreds or thousands of people.

SAFe concedes that Scrum isn't for everyone and that some teams may be better off running Kanban with synchronization points. In that aspect, it is more flexible than LeSS, which is Scrum.
On the other hand, Less does not have certain elements of the ART such as the "Architectural Runway", making it more flexible in those aspects.

Organizations who don't even understand why they should invest time into a Nemawashi will be better off trying SAFe. During this process of making an informed decision (which LeSS strongly advises), they might or might not discover LeSS to be more suitable.

In either case, the organization must take care that their optimization goals are compatible with the adjustments and outcomes suggested.

In my opinion, any discussion "SAFe vs. LeSS" is not a question about the frameworks, but about the current and intended future state of an organization considering an agile transition. There is no "better" or "worse" without having a specific company as the basis for a comparison.

My personal, biased take on SAFe

• SAFe definitely has merit for improving organizations who just can't understand agility yet. It's a good incubator for agile practices and mindset.
• It surely looks fairly easy to sell, because they've invested a lot into streamlining the sales process (i.e. convincing managers to give it a shot). Every SPC has had a basic Sales training. I find that valuable, even for other purposes.
• SAFe comes bundled with mutual adoption support - an SPC never has to fear of being left alone. Dean emphasized that you should always work together with other SPC's as a team during a SAFe Enterprise Transformation. I love the idea. It increases reliability and creates a meta-feedback loop.
• I pity the "Product Owners" and "Scrum Masters" in a SAFe environment. One thing is certain: if an organization would offer me a SM/PO position, I'd now be very, very keen to discover whether they are using SAFe, and if so, what they made of it ...

Summary

SAFe is a quantum leap ahead for companies who are still stuck in the Stone Age of Waterfall Project Organization, reporting Watermelons year after year.

On the other hand, it is probably unnecessary weight for companies that have mastered agile delivery on an organizational level already. But even then, it may be good looking into SAFe just to get a different perspective and maybe learn something new.

Unlike Scrum, which pretty much suggests "We'll train your CSM, then have fun learning through Inspect and Adapt", SAFe clearly suggests taking calculated risks while having continued SPC support until the Train runs smoothly. That does boost management confidence in the framework.