How a SAFe Agilist Handles Resistance

Most resistance to a SAFe adoption is accurate. The engineer who says the planning event is theatre has usually attended a planning event that was theatre. The manager who says nothing has changed except the vocabulary is often describing their organisation correctly. Treating resistance as a communication problem is the most common mistake a newly certified leader makes, and it converts people who were telling you something useful into people who have stopped bothering.

Key Highlights

• Resistance is usually evidence rather than obstruction, and the specific objection normally identifies a real defect in the implementation.
• The four sources are different and need different responses: people protecting autonomy, people protecting status, people who have seen this fail before, and people who are correct.
• Scaled Agile defines Lean-Agile Leadership as driving and sustaining change by empowering individuals and teams, which is incompatible with treating dissent as a compliance problem.
• Middle management resistance is the most consequential and the least discussed, because the framework genuinely reduces the coordinating role many of them hold.
• The response that fails most reliably is explaining the framework again, because the objection was rarely about understanding.
• An adoption with no visible dissent is usually one where people have concluded that objecting costs more than complying.

Why the first instinct is wrong

The certified leader's instinct when meeting resistance is to explain. The framework is well designed, the reasoning is sound, and the objection appears to come from not having understood it.

That instinct is wrong about half the time and expensive when it is.

Consider the two most common objections. Somebody says PI Planning is a waste of two days. Somebody says nothing has changed except the language. Both are framework-level criticisms in form. Both are, in most organisations, accurate descriptions of a specific local failure: a planning event where the plan was presented rather than built, or an adoption where the ceremonies changed and the funding did not.

Answering either with an explanation of what PI Planning is meant to produce misses the point entirely. The person knows what it is meant to produce. They are telling you it does not.

The productive response starts by establishing whether they are right, which is uncomfortable and much faster than the alternative.

The four sources, and what each one needs

People protecting autonomy. Usually engineers and teams who had discretion and now see planning cadence as a constraint on it. The objection sounds like the framework is bureaucratic overhead.

What they need is the boundary made explicit. SAFe constrains when teams plan and integrate, and it does not constrain how they build. Where an implementation has extended the constraint into technical decisions, the objection is correct and the implementation is wrong.

People protecting status. Usually managers whose coordinating role the framework reduces. Rarely stated directly, since nobody says they object because their job is diminished.

What they need is an honest conversation about what their role becomes. Evading this is the single biggest driver of quiet, sustained resistance in an adoption, because the person cannot raise the real objection and so raises others that cannot be resolved.

People who have seen this before. Veterans of two or three failed change programmes. The objection is that this will be like the last one.

What they need is not reassurance. It is the specific difference, and the only credible one is whether funding and governance are changing. If they are not, this person is right and telling them otherwise costs you their trust permanently.

People who are correct. The most valuable group and the one most often mishandled. They have identified a genuine defect: the Innovation and Planning Iteration is being used for carryover, improvement items are never funded, the System Demo is not integrated.

What they need is for you to agree, name the problem, and do something about it. Our piece on SAFe anti-patterns catalogues what they are usually pointing at.

Middle management, which nobody wants to discuss

Worth its own section because it is the most consequential and the least honestly addressed.

SAFe pushes decisions toward teams and the train. A substantial part of what many middle managers do is coordinate between teams, allocate people, and carry information upward. The framework does some of that structurally, through the events, the programme board and the Release Train Engineer role.

The uncomfortable implication is that a genuine adoption reduces the coordinating component of those jobs. Most transformation material handles this by asserting that managers become coaches and leaders, which is sometimes true and is not automatic.

Two things follow. The resistance is rational and pretending otherwise insults people who can read the situation as well as you can. And the conversation has to be explicit and early, because unaddressed it produces a layer of people with the influence to slow an adoption and no incentive to accelerate it.

The organisations that handle this well tend to do two things: name the change to the role directly rather than euphemistically, and give managers a genuine part in the new structure rather than a rebranded version of the old one.

What actually works

Six things, roughly in order of how often they resolve something.

Establish whether the objection is true. Before responding, find out. If the System Demo genuinely is a sequence of team demos, the person is not resisting, they are reporting.

Fix one thing they named. Nothing converts a critic faster than acting on their specific complaint. It also costs less than a persuasion campaign and produces evidence.

Stop explaining the framework. The objection is rarely about comprehension. Explaining again reads as not listening, which converts a specific objection into a general position.

Name the cost honestly. Planning cadence does constrain autonomy. The events do consume time. Denying the cost destroys credibility on everything else you say, and the cost is visible to everyone anyway.

Give the loudest sceptic something real to own. Facilitating a section of the planning event, owning the dependency board, running one Inspect and Adapt workshop. People rarely resist something they are responsible for making work.

Accept that some resistance is correct and unfixable by you. Where funding sits above your organisation entirely and will not change, the sceptic is right. Saying so honestly is better than defending an implementation you know is compromised.

What fails

Escalating. Getting a senior person to instruct someone to comply produces compliance and ends the useful information flow. You will not hear the next problem.

Framework evangelism. Enthusiasm about the model reads as naivety to anyone who has watched an adoption fail, and it disqualifies you from the conversation that matters.

Mandatory training as a response to dissent. Sending a sceptic on a course when their objection was about implementation rather than understanding confirms that nobody listened.

Waiting for it to pass. Resistance that goes quiet has usually converted into disengagement, which is worse because it is invisible. An adoption with no visible dissent at six months is not necessarily going well.

Treating it as a change management workstream. Resistance is information about the implementation. Routing it to a communications plan removes the information and keeps the problem.

The transparency connection

There is a direct link between how resistance is handled and whether the framework's core mechanisms function at all.

Every inspect-and-adapt mechanism in SAFe assumes honest inputs. PI Planning depends on teams stating capacity truthfully. Inspect and Adapt depends on people naming what went wrong. Predictability measurement depends on objectives that were genuinely negotiated.

An organisation that treats objection as obstruction has taught everyone watching that saying uncomfortable things is costly. The immediate effect is that resistance stops. The lasting effect is that every input into every empirical mechanism becomes managed rather than accurate, and the framework is then processing fiction while appearing to run correctly.

This is why handling resistance well is not a soft skill sitting alongside the framework. It is a precondition for the framework working, and it is the substance of what Leading SAFe certification training covers when it addresses leadership behaviour.

Resistance from teams against resistance from leaders

The two behave completely differently and conflating them wastes effort.

Team-level resistance is loud, specific and usually resolvable. Teams say the planning event is too long, the estimation ritual is pointless, the board is not maintained. These objections are concrete, they name a practice, and they can be tested. They also tend to resolve quickly when acted on, because teams feel the improvement directly.

Leadership resistance is quiet, general and structural. It does not appear as objection. It appears as a funding decision deferred, a role not filled, a meeting that keeps getting rescheduled. Nobody says they oppose the adoption; the resources simply do not arrive.

The second is far more damaging and much harder to address, because there is nothing explicit to respond to. The only reliable approach is to make the decision visible: name the specific thing that has not happened, attach it to a consequence people already care about, and put it in front of someone who can act.

An adoption with vocal team resistance and committed leadership will usually succeed. One with compliant teams and quietly absent leadership will usually not, and it will look healthier for longer, which is the trap. This asymmetry is the reason the SAFe implementation roadmap sequences leadership commitment before anything else.

The question that ends most arguments

When an objection is going in circles, one question tends to resolve it.

Ask what would have to be true for this to work.

It does three things. It moves the conversation from whether the framework is good, which is unresolvable, to what conditions are missing, which is answerable. It gives the other person a legitimate route to being right without either party conceding. And it very often surfaces the real objection, which is frequently about funding, authority or a role change rather than about the practice being discussed.

The answers are usually specific and actionable. Business Owners would have to actually attend. Improvement items would have to be funded. The approval process would have to change. Every one of those is a real finding and most are things you can either fix or escalate with evidence.

It also works on yourself. If you cannot answer what would have to be true for this adoption to succeed, you are advocating rather than leading, and that gap is exactly what Leading SAFe certification training is meant to close.

A short script for the hardest conversation

The one where someone senior tells you this is the same as the last failed programme.

Do not disagree. Ask what happened last time and listen properly, because the answer is usually accurate and usually about funding or governance rather than method.

Then say what is different, specifically, or admit that nothing is yet. If the funding model is changing, name the change. If it is not, say that this is the thing that has to change and that you agree the adoption will not deliver without it.

That answer costs you the appearance of confidence and buys something more useful, which is a person who believes you are describing reality. It also puts the actual obstacle on the table, which is where it needs to be if anyone senior is going to act on it.

Rehearse it before it happens, because improvising this one badly is how adoptions lose the people who could have carried them.

When you are the one resisting

Worth addressing, because certified leaders sometimes find themselves objecting and treat that as a failure of belief.

It is not. A SAFe Agilist who thinks a particular implementation is going badly is doing the job correctly. The framework is not a doctrine and the certification is not an oath, and the person best placed to notice that an adoption has gone ceremonial is usually someone who understands what the events are supposed to produce.

Three situations where your own resistance is the correct response.

The organisation is applying it below the scale it fits. A single team does not need PI Planning. Coordination machinery for a coordination problem that does not exist is pure cost, and saying so is more useful than implementing it well.

The governance change is not going to happen. Where funding sits above your organisation and will not move, the adoption will produce ceremonies and no outcome. Naming that early is a service.

The framework is being used to avoid a harder conversation. Adopting SAFe is occasionally a way of appearing to address a problem that is actually about leadership, capability or strategy. The framework will not fix any of those and will absorb the attention that might have.

In all three, the useful move is the same one recommended for handling other people's resistance: be specific, attach it to a consequence, and propose something smaller rather than opposing wholesale. That is what Lean-Agile leadership actually asks for, and it is considerably more valuable than advocacy.

The long game

Resistance handled well compounds, and so does resistance handled badly.

An organisation where objection produces investigation develops a habit. People raise things earlier, the implementation improves faster, and the framework's empirical mechanisms receive accurate inputs. That is not a soft outcome; it is the difference between an adoption that improves each Program Increment and one that ossifies.

An organisation where objection produces explanation or escalation develops the opposite habit within about two increments. People stop raising things, the implementation stops improving, and reporting becomes managed. The adoption then appears healthier than it is, which delays the correction until it is expensive.

The choice between those two paths gets made in a handful of specific moments, usually early, and usually when someone reasonably senior says something inconvenient in front of an audience. What happens in those moments is watched closely and remembered accurately.

That is the whole subject in one observation, and it is why handling resistance is leadership work rather than communications work. Checking your own framework grounding with the free Leading SAFe practice test is worth doing before those conversations, since the credibility to hold them rests on knowing precisely what each mechanism is supposed to produce.

Three phrases worth avoiding

Small things, and each one reliably costs credibility with an audience that has seen a transformation before.

Resistance to change. Framing an objection this way relocates the problem into the objector's psychology and away from the implementation. It is also transparently dismissive, and people recognise it immediately.

Trust the process. Asked of people who are watching the process not work, this reads as a request to stop looking. If the process is working, point at the evidence instead. If it is not, the request is unreasonable.

That is not real SAFe. Technically often correct and rhetorically fatal. The person is describing what their organisation actually does, and telling them it does not count is a way of avoiding the fact that their organisation does it. Better to agree that the implementation has drifted and say what would bring it back.

The common thread is that all three deflect rather than engage, and each converts a specific objection into a general loss of confidence in the person saying it. Our piece on Lean-Agile leadership covers the alternative posture, which is considerably harder and works.

The underlying point

Resistance is the cheapest diagnostic available in an adoption. It arrives free, it is specific, and it comes from people close enough to the work to see what is actually happening.

Treating it as a problem to be managed discards that information and teaches the organisation to stop offering it. Treating it as evidence means the implementation improves and the people who objected become the people who fix it.

The distinction matters more than any framework knowledge, and it is why Scaled Agile frames Lean-Agile Leadership as empowering people rather than directing them. Leading SAFe certification training covers that material across two days with the exam attempt included, and the free Leading SAFe practice test is a quick check on the framework grounding these conversations rest on.