It is tempting, when an agile transformation runs into resistance, to frame the problem as a people problem: people who do not understand the framework, who are attached to old ways of working, who are insufficiently committed to the change. This framing is rarely accurate and almost always counterproductive.

Employee resistance to agile principles — particularly in large-scale frameworks like SAFe — tends to be a rational response to a change that has not been adequately explained, supported, or designed with the people affected by it in mind.

What resistance actually looks like

Three patterns appear consistently in SAFe implementations that are underdelivering on their potential.

Stifled experimentation. Agile frameworks depend on teams being willing to try approaches they are not certain will work. This willingness requires safety — the genuine belief that trying and failing will be treated as learning rather than as failure. In organisations where the incentive structures still reward predictability and punish surprises, experimentation is rational to avoid.

Fragmented collaboration. Cross-functional collaboration requires both the structural conditions to make it possible and the relational conditions to make it comfortable. Teams that have been organised by function for years do not automatically collaborate across those boundaries because the framework says they should. The trust, shared language, and mutual understanding needed for effective collaboration are built through sustained interaction — not mandated by a new operating model.

Missed improvement opportunities. Continuous improvement requires feedback, transparency about what is not working, and permission to change things. In organisations where surfacing problems is experienced as dangerous, improvement initiatives stall. People learn to describe the system as working when it is not, which makes it genuinely harder to improve.

What actually helps

The most durable solutions to employee resistance address the underlying conditions rather than the surface behaviour.

Psychological safety as infrastructure. This is not a values statement — it is an operational requirement. Teams need concrete evidence that raising problems, expressing uncertainty, and advocating for different approaches are safe. That evidence comes from leaders' responses to the first few instances of each, not from company values on the intranet.

Education about the why, not just the what. People who understand why agile principles exist — what problems they were developed to address, why traditional approaches struggled with those problems — are more capable of adapting the principles intelligently to their context. People who only understand the ceremonies tend to execute the ceremonies without the underlying judgment.

Leadership modelling that goes beyond statements. Leaders who visibly practise agile values — who are genuinely transparent about what they do not know, who change course based on evidence, who acknowledge when plans were wrong — create conditions where these behaviours become normal. Leaders who profess agile values while continuing to make decisions unilaterally and manage by output metrics send a different and more powerful signal.

Celebrating specific behaviours, not just outcomes. Recognising the team that surfaced a risk early rather than hiding it, the developer who questioned a requirement and prevented expensive rework, the retrospective that produced a change that actually stuck — these create the cultural memory of what agile looks like in practice, which is more useful than any amount of formal training.

The narrative matters too. Employees who understand clearly why the organisation is changing, what it will mean for their work, and how their contribution fits into the direction being taken are far more likely to engage than those who experience change as something happening to them from above.