The four SAFe Core Values are alignment, transparency, respect for people, and relentless improvement. Scaled Agile describes them as the foundational beliefs that make the framework effective, which is easy to read as decoration and is not. Each one has a specific failure mode, and when a SAFe adoption stalls it is almost always traceable to one of these four having been skipped while the ceremonies were adopted.
Key Highlights
- The four SAFe Core Values are alignment, transparency, respect for people, and relentless improvement. Four, not five, and the count is examinable.
- Scaled Agile positions them as foundational beliefs underpinning the framework's effectiveness, rather than as aspirational statements.
- Alignment fails when teams plan on cadence but leadership direction keeps moving, which produces synchronised confusion.
- Transparency fails first and fastest, because it depends on what happens to people who report bad news.
- Respect for people is the value most often cited and least often structurally supported.
- Relentless improvement fails when Inspect and Adapt produces a list nobody is funded to act on.
Why four values rather than a longer list
Frameworks accumulate values. SAFe kept the list short for a practical reason: each of these four is a precondition for the mechanics to function, not a description of a pleasant workplace.
That is the test worth applying. If you removed alignment, PI Planning would still happen and would produce a plan pointing in several directions. If you removed transparency, the boards would still be updated and would show what people thought was safe to show. The ceremonies survive the loss of the values, which is exactly why adoptions can look correct and produce nothing.
Leaders are the audience for this section of Leading SAFe certification training, and the reason is that all four values are set by leadership behaviour rather than by team practice.
Alignment
What it means. Everyone working toward the same objectives, understood the same way, at every level from portfolio to team. Not agreement, and not consensus. Alignment means people can act independently and have their work still fit together.
Why the framework needs it. An Agile Release Train exists so many teams can deliver something integrated. If the teams are aligned to different interpretations of the same goal, the integration is where that surfaces, usually late.
What breaks without it. You get synchronised confusion. PI Planning runs, the room fills, teams plan on cadence, and they plan toward different understandings of what matters. The symptom is a train that hits its dates and delivers something nobody wanted, and it is frequently misdiagnosed as an execution problem when it is an alignment problem.
Where it actually fails. Almost always above the team. Teams align readily when direction is stable and clear. What breaks alignment is leadership changing priorities between planning events without changing the plan, so teams execute a stale objective while being measured against a new one.
The leadership behaviour that fixes it. Say the same thing in the same words to every level, and when priorities change, change them at the planning event rather than in the corridor.
Transparency
What it means. Making the real state of the work visible: progress, problems, risks and mistakes.
Why the framework needs it. Every inspect-and-adapt mechanism in SAFe assumes the inputs are honest. PI Planning depends on teams stating capacity truthfully. Inspect and Adapt depends on people naming what went wrong. If those inputs are managed rather than accurate, the whole empirical apparatus is processing fiction.
What breaks without it. Confidence detached from reality. Status stays green until the date it cannot, dependencies surface at integration rather than at planning, and PI Objectives get written to be achievable rather than to be useful.
Where it actually fails. This is the value most sensitive to leadership behaviour, and it fails for one reason above all others: what happens to the first person who reports bad news early. If that person is questioned, blamed or made to justify themselves in front of peers, the organisation has just taught everyone watching what visibility costs. No board configuration recovers from that.
The leadership behaviour that fixes it. Reward early bad news visibly. When a team surfaces a slip eight weeks out, the response has to be help, and it has to be public, because the audience is everyone who was watching to see what happens.
Respect for people
What it means. Treating people as the source of value rather than as capacity to be allocated. It extends to customers, partners and suppliers, not only employees.
Why the framework needs it. SAFe pushes decisions toward the people doing the work. That only functions if those people are treated as capable of making them.
What breaks without it. Compliance without commitment. Teams attend the events, complete the artefacts, and stop volunteering anything. It looks like adoption and is closer to the opposite, since the events are producing outputs without producing the thinking they exist to generate.
Where it actually fails. Not usually in stated intent. Almost every organisation says it respects its people. It fails structurally: reorganisations that treat teams as interchangeable resource, plans built on utilisation targets, and the recurring pattern of announcing a transformation to people rather than with them.
The uncomfortable version. Respect for people is the value most often quoted in transformation material and least often reflected in how the transformation itself is run. An adoption imposed on an organisation without asking it anything has already contradicted the value in its first act, and the teams notice immediately.
The leadership behaviour that fixes it. Let the people doing the work make the decisions about how it is done, including the ones you would have made differently. Our piece on Lean-Agile leadership covers what this requires in practice.
Relentless improvement
What it means. A standing assumption that the current way of working is improvable, backed by dedicated time and a mechanism to act.
Why the framework needs it. SAFe is not meant to be implemented and then left. Inspect and Adapt exists at the end of every Program Increment specifically to produce improvement items for the next one.
What breaks without it. The framework calcifies. The organisation adopts a configuration, declares the transformation complete, and runs those ceremonies unchanged for years while the problems they were meant to solve move elsewhere. Inspect and Adapt becomes a retrospective theatre where the same items are raised each PI and none are actioned.
Where it actually fails. Not in the workshop. Teams identify problems accurately and readily. It fails immediately afterwards, when improvement items compete with feature work for capacity and lose every time. An improvement backlog with no allocated capacity is a list of complaints.
The leadership behaviour that fixes it. Fund the improvement items. Put them in the PI as committed work rather than as an aspiration for spare time, since there is never spare time. A useful discipline is to cap it: one improvement item per team per Program Increment, committed and protected. Small and actually delivered beats a long list nobody touches, and it establishes that the workshop produces change rather than minutes.
The four together, in one table
| Value | Fails when | Symptom you will actually see |
| Alignment | Leadership changes direction between planning events | Teams hit dates, deliver the wrong thing |
| Transparency | Bad news is punished, even once | Status stays green until it cannot |
| Respect for people | Teams are treated as allocatable capacity | Compliance without commitment |
| Relentless improvement | Improvement work is unfunded | The same items raised every Inspect and Adapt |
How the values relate to the principles
People conflate these constantly, and the distinction is examinable as well as useful.
There are four Core Values and ten Lean-Agile Principles. The values are foundational beliefs: conditions that have to hold for the framework to function. The principles are reasoning tools: things you apply to a specific decision to work out what to do.
The practical difference is what you do with each. You cannot apply a value to a decision. Alignment does not tell you whether to split a Feature. But you can check whether a value is present, and its absence explains why decisions keep going wrong. A principle is the reverse: it does not describe a state of the organisation, it gives you a way to think about a choice in front of you.
That is why the values appear early in Leading SAFe certification training and the principles appear after. The values establish whether the framework can work here at all. The principles are how you operate it once it can. Our breakdown of the SAFe Lean-Agile principles covers the second half.
A short self-assessment
Four questions, one per value. They are more useful than a maturity model because each has an observable answer rather than a score.
Alignment. Ask three people at different levels what the most important objective is this Program Increment. If you get three different answers, you have an alignment problem, and no amount of planning discipline will fix it.
Transparency. Think of the last time someone reported a serious problem early. What happened to them. If you cannot think of an instance, that is itself the answer, because it means nobody has judged it safe to try.
Respect for people. Look at the last reorganisation or team change. Were the people affected consulted, or informed. The distinction is the whole value.
Relentless improvement. Open the last two Inspect and Adapt outputs. How many items from the first one were actioned before the second. If the answer is none, the workshop is producing a list rather than a change.
Most organisations fail at least two of these, which is normal and is not a reason to abandon the framework. It is a reason to fix the values before adding more ceremony, since ceremony layered on absent values is what produces the adoptions that look correct and deliver nothing.
Why this is a leadership subject rather than a team one
Every failure mode above originates above the team.
Teams do not cause misalignment; they inherit it. Teams do not choose to hide problems; they learn what visibility costs. Teams do not decide they are interchangeable resource. And teams do not decline to improve; they run out of capacity to do it.
This is the argument the whole Leading SAFe course rests on, and it is why the values sit in a leadership class rather than in team training. The framework's mechanics are not difficult. What is difficult is that they require leaders to behave differently before teams can, which is the reverse of how most transformations are sequenced.
The SAFe implementation roadmap puts leadership commitment early for exactly this reason, and the business agility framing that opens the course exists to make the case before any structure is introduced.
What each value looks like when it is working
The failure modes above are easier to spot than the healthy state, so it is worth naming what good actually looks like.
Alignment working looks like a team making a local decision without escalating, and that decision turning out to fit what everyone else was doing. That is the test. Alignment is not measured by how many people attended the planning event; it is measured by whether independent decisions cohere afterwards.
Transparency working looks like a problem being raised eight weeks before it would have bitten, by someone junior, without hedging. The tell is timing and seniority. Late bad news from senior people is normal in every organisation. Early bad news from anywhere is rare and diagnostic.
Respect for people working looks like teams pushing back on a plan and the plan changing. Not every time, and sometimes. An organisation where teams never successfully change a decision has the value on a poster and nowhere else.
Relentless improvement working looks like something visibly different between one Program Increment and the next. Not a longer improvement backlog. An actual change to how the work happens, traceable to a workshop.
None of these require a maturity assessment to observe. They are all things you can notice in an ordinary fortnight, which is what makes the four values a practical diagnostic rather than a values statement.
What this means for the exam
The values appear on the SAFe Agilist exam in two ways. The count and the names are recall questions, and both are easy marks that people occasionally lose by adding a fifth value that does not exist.
The more interesting appearance is in scenario questions, where a situation is described and you have to identify which value has been violated. Those are answerable if you know the failure modes rather than the definitions, which is the argument for reading this section as diagnosis rather than as a list.
The free Leading SAFe practice test covers both question types and takes a few minutes.
Why adoptions fail the values and keep the ceremonies
Worth naming the mechanism, because it is remarkably consistent across organisations that have nothing else in common.
Ceremonies are easy to adopt. They are visible, schedulable, and someone can be made accountable for running them. A transformation office can report that twelve trains are now holding PI Planning, and that is a true statement about activity.
Values are none of those things. Nobody can be assigned to deliver transparency. It cannot be scheduled. It has no completion date and it does not appear on a status report. So when a transformation is measured, and it always is, the ceremonies get measured because they are measurable.
The predictable result is an organisation eighteen months into an adoption with full event attendance, complete artefacts, and no change in outcomes. When that is diagnosed, the usual conclusion is that the framework does not work, or that more rigour is needed on the ceremonies. Both are wrong. The ceremonies were never the mechanism.
This is why the values sit at the front of the course rather than as an appendix, and why the SAFe implementation roadmap puts leadership commitment before any structural change. Getting that sequence wrong is the most expensive mistake available in a transformation, and it is extremely common.
Which value to fix first
If more than one is broken, and usually more than one is, the order matters.
Start with transparency. It is the precondition for diagnosing anything else. Without honest inputs you cannot tell whether your alignment problem is real or whether teams are simply reporting what they think you want. Every other measurement in the framework depends on it, which is why it is worth fixing before you attempt to measure anything.
Then alignment. Once information is accurate, misalignment becomes visible and correctable. Attempting alignment work while transparency is broken produces agreement in the room and divergence outside it.
Then relentless improvement. With honest information and a shared direction, the improvement mechanism has something real to work on. Fund the items and the loop starts turning.
Respect for people runs underneath all three rather than sitting in the sequence. It is not a phase you complete. It is the thing that determines whether the other three are achievable at all, because none of them survive an organisation that treats its teams as interchangeable.
The reason for that order is that each earlier value makes the next one diagnosable. Working them in reverse, which is the common instinct because improvement feels most actionable, produces improvement backlogs full of items generated from inaccurate information.
If you want to test your own grounding on how the values connect to the rest of the framework, the free Leading SAFe practice test covers both the recall and the scenario forms.
Where to take this next
The useful way to hold these four is as a diagnostic rather than as a poster. When an adoption is not producing what it promised, work through them in order and one will explain it. The ceremonies are almost never the problem.
If you are leading or about to lead an adoption, Leading SAFe certification training covers the values alongside the leadership behaviours they depend on, across two days and including the SAFe Agilist exam attempt. Current Leading SAFe certification costs are listed separately, and the course curriculum shows how the modules build toward the change work at the end.


























