The Immense Risks of Superficial Knowledge Gained From Frameworks Like SAFe
In brief
Why fluency in a framework like SAFe isn't the same as skill, what that gap costs teams, and what Shu-Ha-Ri explains about the trap of stopping there.
A two-day certification course does not make someone a skilled agile practitioner. It makes them fluent in a vocabulary. Complete the training, and confidence usually arrives faster than competence does — and that gap is where a lot of expensive dysfunction quietly lives.
The pattern is clearest in people who've completed SAFe (Scaled Agile Framework) certification and carry the title for it. Some of the most SAFe-fluent people I've worked with, across a range of organizations, follow the rules closely, by the book, and underneath the vocabulary, what results is close to old-fashioned waterfall planning. The terms are new. The approach to locking a plan and holding a team to it, regardless of what changes, usually isn't.
Sit in enough SAFe Program Increment (PI) planning sessions across enough organizations, and a version of the same thing repeats: big, upfront planning mapped three months out, with teams committing to the plan regardless of what changes. Ask what's supposed to happen when priorities shift mid-quarter, and the answers thin out fast. The ceremony runs on schedule; the judgment about why it exists rarely shows up in the room.
None of this makes frameworks worthless. Used well, a framework works less like a rulebook and more like a set of creative constraints: structure that makes coordinating a group of people easier, not a substitute for understanding why it exists. SAFe draws on real, established practices, but packages them so people learn how the pieces snap together without learning what each one is actually for, or when a different one fits the context better. Skill is the second kind of knowledge; fluency is usually only the first.
There's a line from the statistician George Box worth borrowing here: “All models are wrong, but some are useful.” A framework is a model: a simplified stand-in for how work actually happens on a specific team, in a specific context. It will never fully match the reality it's modeling. What separates fluency from skill is knowing where and how the model doesn't fit — a step past what Box said outright, but the natural next question his line leaves open.
Fluency without skill has real costs. Trust is one: leaders who've completed the official training start believing they understand outcomes they've only memorized vocabulary for, and teams feel that gap before anyone says so. Flexibility is another: a team that followed the ceremonies precisely but never learned the reasoning behind them can't respond when a situation changes, though that was the entire point. What's left is talking the talk of agility while walking an entirely different walk: waterfall planning in agile vocabulary, called agile because the terminology says so.
Underneath most of this sits something close to what's commonly called the Dunning-Kruger effect: a little structured knowledge producing outsized confidence. That idea gets thrown around loosely enough, and misapplied often enough, that I hold it lightly myself and could be misusing it here too. Still, the shape is familiar: training feels like a lot, right up until reality asks a question the framework never prepared anyone to answer.
The clearest way I've found to explain the difference between fluency and skill borrows a framework of its own: Shu-Ha-Ri, a model from Japanese martial arts describing how someone moves from beginner to mastery. Applying it to agile is its own small act of borrowing — plenty of others have done the same outside its original home, and I'll own that honestly rather than pretend the metaphor is native to this field.
Shu is the copying stage: follow the form exactly as taught, without asking why, because the rules give you something solid to stand on before you understand them. Ha is where a practitioner starts breaking from the form on purpose, testing the principles underneath it against what actually holds up. Ri is fluency: the rules have dissolved into judgment, and a practitioner in Ri reads what a situation needs instead of running a memorized sequence.
Most explanations stop there, as a straight line from novice to master. I'd add a loop usually left out: Ri circles back to Shu. A genuinely skilled practitioner deliberately returns to beginner's mind, picking up a new practice or a new team and moving back through Shu on purpose, because staying humble enough to start over is part of what mastery looks like. Rather than a ladder climbed once, it's a loop, run continuously.
The thesis here: SAFe is very good at keeping people in Shu, at best somewhere in Ha, and it rarely moves anyone further. Certification teaches the form well; it doesn't teach when to break from it, and nothing rewards anyone for trying. It almost feels like it tries to trap you in Shu rather than move you through it. What marks a skilled practitioner is understanding the principles underneath the rules well enough to know when they stop applying, and having a toolbox well beyond SAFe to reach for instead.
There's a career-level version of the same trap, and the stakes are higher than a bad planning meeting. I've watched people who built an entire professional identity around one framework lose their jobs and struggle to find the next one, unsure what they should even be doing in a market that no longer asks for it. What was mandatory at one organization is optional or gone at the next, and a practitioner whose entire value rested on one system's fluency finds it doesn't transfer. A career can't be built on attaching to whatever's hot at the moment. Hot doesn't last, and neither does the market for someone who only knows one way to do it.
Treating any single framework as one tool in a larger toolbox, rather than the whole toolbox, is what keeps that risk from applying — taking whatever's genuinely good out of SAFe, or Scrum, or Kanban, and actually embodying it, building it into judgment that travels from job to job instead of stopping at a certification. That's close to what agile was supposed to mean before it became something people mainly get certified in.
None of this is a knock on the people sitting in the training. A short course was never going to produce real mastery on its own: no framework's onboarding could. The real question is what happens after: whether the certificate becomes a floor to build real judgment on, or a ceiling nobody notices they've stopped climbing toward.
If you're leading a transformation and suspect your organization sounds agile without being agile — the ceremonies run, the vocabulary is right, nothing actually bends — an outside read can tell you faster than another quarter of it will.