Every SAFe adoption gets changed. Can you say yours was changed on purpose?
A self-paced, on-demand course on changing SAFe deliberately — what the Framework already expects you to configure, which of its seven aspects a real customization touches, the four guardrails every proposal has to clear, and the blueprint that turns “we do it differently here” into a change with a reason, a benefit, and a way back.
Every adoption gets customized. The question is whether anyone decided to.
No organization runs a framework exactly as written, and none should have to. Context intervenes — the regulator you answer to, the size you actually are, the technology you already own, the culture and vocabulary you inherited — and the Framework has to meet it. That’s expected. Whole configurations exist for it: rename Business Value to Mission Value and Customer to Public Servant and you have SAFe for Government.
The problem is the customization nobody decided on. A practice dropped because the calendar was full. A role merged because somebody left and was never replaced. An event quietly shortened, then quietly skipped. Every one of those calls was reasonable on the day it was made. Together they add up to an operating model that still carries the name and no longer produces the outcome the name was standing for.
And the hard cases don’t announce themselves. Renaming Epic to Initiative so it fits the portfolio language you already use is a reasonable fit to context. Renaming Epic to Initiative so nobody has to change how portfolio work actually gets done is the same edit with the opposite result — and you cannot tell them apart by looking at the change. You can only tell by asking what it’s for.
This course is about asking that, every time, in a way somebody else can check.
What you’ll learn
Tell configuring from customizing.
How your ARTs are organized and staffed, which topologies you use, whether you run OKRs, what cadence you develop on, who acts as Business Owner — all decisions, none of them customizations. Learn where the Framework’s built-in range ends, so you stop asking permission for changes it already expects and start noticing the ones that genuinely alter an element’s definition.
Know when to customize, not just whether.
The same change is a good idea in year two and a bad one in week one. Learn to read where an organization is — before implementation, during it, or with real experience behind it — and why customizing early tends to remove the barriers to starting or remove the point of starting, with very little in between.
Name the aspect you’re actually changing.
Any system of work comes down to people, work, and activities, and SAFe decomposes into seven customizable aspects: roles, groups, work items, work artifacts, workflows, events, and practices. Naming the aspect is what turns “we want to do it differently” from an argument into a proposal — and makes it obvious when four separate asks are all pulling at the same one.
Put every proposal through the four guardrails.
Each one is a question, not a rule. Does this contradict the Lean-Agile Mindset, the Core Values, or the Principles? Is customizing the best answer here, or the easiest? Which outcome does it amplify — or is it protecting the status quo? And does it hold up systemically, or is it a local fix that breaks something downstream?
Fill in a customization blueprint.
One row per change, four steps to complete it: the need, the proposed customization and the aspect it touches, the guardrail validation, and the benefit with the measure that will show it. A proposal that cannot finish a row is not ready to be argued about, let alone rolled out.
Roll it out as an experiment, and leave a record.
Treat each customization as a hypothesis: the smallest rollout that proves or disproves it, the people who will explain it, the qualitative signal as well as the numbers, and an honest answer on whether it can be rolled back. Then write it down — a change log, a mapping from SAFe’s terms to yours, an updated Big Picture — so the next person inherits a decision instead of a mystery.
Who should take this course
This is for you if people bring you the exceptions.
You’re the SPC, coach, or consultant who gets asked whether the organization can skip this, merge that, or run it differently — and you want an answer you can defend in the room, rather than a reflexive no or a shrug.
This is for you if your adoption has already drifted.
What your organization does today and what the Framework describes aren’t the same thing, and nobody can quite say when that happened or who decided. You need a way to look at what’s actually running, keep what earns its place, and put the rest back on purpose.
This isn’t for you if you haven’t run an implementation yet.
Customizing is an advanced practice, and the Framework says so: it wants change agents who have been through this before and can see what a change will cost two elements away. If you’re still learning what the elements are and what they’re for, start there and come back when the question is how to fit them to your context.
How the course works
Enroll to get instant access at $49.
Start on your own schedule — no cohort, no deadlines, no time pressure.
Complete the course
by working through the lessons end to end: where configuring ends and customizing begins, when an organization is ready for it, the seven aspects a change can touch, the four guardrails, and the four-step process for taking a proposal from a stated need to a measurable benefit. You earn a completion badge upon finishing the course.
Apply it Monday morning
to a change your organization has already made. Start a blueprint and fill one row in backwards: name the aspect, write the need it was meant to serve, run it past the four guardrails, and state the benefit and the measure. If the row won’t complete, you’ve found the first customization worth revisiting — and you’ve started the change log you didn’t have.
A framework you changed on purpose is still a framework.
Fidelity for its own sake was never the point. The elements exist because they work together to produce something — predictable delivery, aligned funding, a room where the hard trade-off actually gets made — and the only question worth asking about any change is whether that outcome survives it. Every customization is really an experiment, whether or not anyone treats it as one. Run it as an experiment and it can unlock something the Framework as written could not. Skip the question and you get customization anyway; you just don’t get to choose which, and you don’t find out until the outcome is already gone.
