Is SAFe just another name for Waterfall?

A strong accusation against SAFe is that it's only a different name for "Waterfall", i.e. while the structure and names are different - the underlying process (and corresponding problems) remain unchanged - so let's clarify how SAFe really changes your development process.

The Waterfall

Does SAFe permit you to continue running a dysfunctional Waterfall? The classic "Water-Scrum-Fall", a widely spread phenomenon:

The Water-Scrum-Fall: "Agile" is something else.

 Can you do that with SAFe? Yes. Then again, you'll be hard-pressed to find any type of statement that SAFe is actually encouraging this. So - why do people think SAFe is just Waterfall reloaded?

1. The PI Planning

As described in another article, the reason why there is a "PI Planning" is not to maintain the Plan->Build->Run cycle (aka. "Waterfall"), it is to create common understanding. PI Planning does not separate "planners" and "doers": Given a prioritized list of abstract, high-level stories ("features"), they decide autonomously what to do while exploring the "Why" together with others. The detailed "What" and "How" is deferred to the latest possible time where it makes sense - i.e. the Iteration (Sprint) Planning of the iteration when teams actually get around to the topic.

Highly empowered, autonomous teams make their own decisions regarding "What", "When" and "How". Managers serve as facilitators, not as authors. Teams propose the most feasible ideas. Teams agree with each other on the objectives. The output is a prioritized, value-based list of objectives for the overall PI - and an intitial short-term backlog for each team. Everyone knows full well that the backlogs can and will change, both in content - and in order. The teams commit to work towards common goals, not to complete specific activities.

PI Planning can not be compared at all with classic project planning.

2. Three-month increment

One of the biggest gripes with Waterfall is Three-Month (or slower) release cycles, inherent to the system: Typically, a stressful analysis phase is followed by a painful development phase, culminating in an excruciatingly painful test phase, where developers are fixing the problems of the current release while already working on the next release.

SAFe operates in small, integrated cycles and suggests applying Test-First implementation. As discussed in an article about releasing, SAFe builds on "Deliver Anytime", taking advantage of fast, integrated learning cycles. Creating batches of work, then sending them through a development process pipeline is not part of the SAFe model. In each Iteration (Sprint), teams refine, plan, build and deliver individual stories and small portions of value. There are no separate "Analysis / Development / Test" phases in SAFe.

A SAFe team should preferrably be arranged to be cross-functional, allowing a single team to ideate, design, implement and verify customer value autonomously. This reduces Work in Process (WIP), handovers and delay.

The PI Increment can not be compared with a Quarterly Release as the underlying process is not the same. 

3. Systems Team

A specific team deploying and operating the built product ("Operations") is a common pattern in Waterfall organizations. The consequence is a "throw over the fence" attitude ("works on my machine") and animosity between developers and operations.

SAFe strongly encourages DevOps practices, bringing the responsibility for operations directly into the teams. The buzzphrase "You build it, you run it" is also applicable in SAFe. Throwing stuff over the fence is not encouraged, as this creates communication gaps and a desync between work in progress among teams.

Then - what is the purose of the Systems Team?

Infrastructure
Teams are potentially challenged to provide a well-working delivery infrastructure, such as deployment pipeline and operating environment.
Especially early on in a transition, it makes more sense to have specific experts deal with infrastructure so that development teams can get around to deliver value and not constantly be distracted by working on base technology. As the Agile Release Train (ART) matures, the infrastructure stabilizes and the amount of maintenance work should decrease to a point where teams can handle it.

Solution Testing
Although this should not happen, occasionally developers or large systems are so focused on their work that they lose sight of the overall process. The question "Who maintains the Big Picture?" sometimes remains un-answered. In cases where developers work on individual microservices and lose sight of the end to end customer facing processes, there needs to be someone to ensure that the customer can actually use the new increment. This may require both exploring the product and automating standard test scenarios. Similar to the point above, as the ART matures, the amount of necessary manual oversight and undone test coverage should approach zero.

Long story short: The Systems Team is not doing work in a different phase. They do work that is outside the other teams' Definition of Done.

Summary

SAFe requires dramatic changes to the way developers work. While not everything is different from how things were done in the past, an ART works radically different from Waterfall. How massive those differences are - depends on how agile the teams are. Maturity and autonomy are the keys to success.