It has become fashionable on LinkedIn to bash Agile frameworks. It’s easy engagement bait. You see the posts daily: “SAFe is just waterfall in disguise,” or “Scrum is dead.”

If you are currently working in an organization where “Agile” feels bloated, slow, and meeting-heavy, those criticisms probably resonate deeply. You feel the transformation fatigue.

But as an active Engineering Manager and SPC who practices in Fortune 50 environments, I have to offer a hard truth that many consultants won’t tell you:

The framework isn’t your problem. Your cut-and-paste implementation is.

The “Cargo Cult” Transformation

The fastest way to fail at any Agile transformation—whether you are adopting basic Scrum or full-blown SAFe—is to take your existing, dysfunctional, siloed organizational structure and simply rename things.

Many companies “adopt Agile” by telling their Project Managers they are now “Scrum Masters,” renaming their PMO department to the “LACE” (Lean-Agile Center of Excellence), and calling their massive 100-page requirements documents “Features.”

Nothing fundamentally changed about how work flows or how decisions are made. The culture remained exactly the same; only the vocabulary changed. That isn’t Agile. That is bureaucracy with better branding.

When implemented with intent, frameworks are powerful mechanisms for aligning complex organizations toward a common goal. When implemented poorly, they are just expensive noise.

A Note on Scaling Frameworks (SAFe vs. LeSS)

When a single Scrum team isn’t enough, organizations look to scaling frameworks to coordinate efforts. The two most common players here are the Scaled Agile Framework (SAFe®) and Large-Scale Scrum (LeSS). They approach the problem from different directions:

• SAFe® provides a comprehensive, structured blueprint for enterprises with high complexity and compliance needs. It offers roles and artifacts for every level of the organization.

• Large-Scale Scrum (LeSS) takes a “less is more” approach, trying to apply the simplicity of single-team Scrum to dozens of teams, removing as much organizational structure as possible.

Neither is inherently “better.” The failure I see isn’t choosing the wrong one; it’s choosing one and then ignoring its core principles. A LeSS implementation that keeps its massive management hierarchy will fail just as hard as a SAFe implementation that ignores Lean-Agile leadership.

The Real Challenge: New Habits Under Pressure

The hardest part of any transformation isn’t learning the new jargon; it’s building new muscle memory.

In a calm environment, it’s easy for a leadership team to say, “We trust the teams to plan their own work.” But what happens when a major production incident occurs, or a Q4 revenue target is missed?

Pressure reveals culture.

Under pressure, human beings revert to their oldest, most deeply ingrained habits. For most seasoned executives and managers, that habit is “command and control.” The moment the heat turns up, the “empowered teams” facade crumbles, and leadership starts demanding hourly status updates, dictating solutions, and micromanaging delivery.

A successful Agile implementation requires a deliberate, disciplined commitment from leadership to act differently when it is hardest to do so. It’s about recognizing that impulse to revert to the old ways, pausing, and choosing the new, uncomfortable path of trust and decentralization. If you don’t practice the new habits under pressure, they will never stick.

3 Signs of a “Bad Agile” Implementation

How do you know if you are falling into the trap of a surface-level transformation? Here are three practitioner-observed signs that your implementation needs a reboot.

1. Your Planning Events are just massive status meetings. Whether it’s SAFe PI Planning or a simple Sprint Planning, these events are supposed to be about cross-team collaboration, negotiation, and alignment.

• The Reality Check: If leadership spends Day 1 talking at the teams for hours, and teams spend Day 2 frantically trying to shove pre-committed scope into buckets without any real authority to push back, you have missed the point. If there is no negotiation, there is no agility.

2. You admire dependencies instead of breaking them. I walk into many program rooms and see boards covered in so much red dependency yarn that it looks like a conspiracy theorist’s basement wall.

• The Reality Check: The goal isn’t to visualize a thousand dependencies and then hire people to manage them every week. The goal is to visualize the pain so you are forced to architect the dependencies out of existence. If your dependency count isn’t going down over time, you aren’t improving flow.

3. The teams changed, but leadership didn’t. This is the most common failure point. We train the developers, Scrum Masters, and Product Owners on new ways of working, but senior leadership continues to operate the exact same way.

• The Reality Check: If executives are still demanding fixed-scope, fixed-date Gantt charts 18 months out—while simultaneously demanding the teams “be more Agile”—the transformation is dead on arrival. You cannot have Agile teams reporting up into a Waterfall funding and governance model.

Don’t Blame the Tool

If these signs sound familiar, don’t throw the baby out with the bathwater. Abandoning SAFe for another framework, or unstructured chaos, won’t fix the underlying cultural issues.

You don’t need a new framework; you need a better implementation, and the discipline to stick with new habits when the pressure is on.

At Perimeter Designs, we don’t just teach the textbook definitions. As active practitioners, we help organizations reboot their implementations to focus on what matters: the flow of value, not just the adherence to process. Let’s get your transformation back on track.