What Agile Gets Wrong About Organisational Change (And What to Do Instead)

I have watched dozens of companies try to "agile their way" through organisational change. Sprint planning for culture shifts. Daily standups for transformation programmes. Retrospectives on why people are not adopting new behaviours.

It almost never works.

The problem is not that agile is bad. It is brilliant for what it was designed to do: iterative software development with clear deliverables and measurable progress. But human behaviour change operates by completely different rules.

Where Agile Falls Short on Change

Agile assumes you can iterate your way to the right answer. Build something small, test it, learn, adjust, repeat. This works when you are building features because code does what you tell it to do.

People do not.

When I worked with a major bank trying to "agile" their way through a digital transformation, they spent months running two-week sprints to "test different change approaches." The result? Dozens of confused middle managers who had been through four different onboarding processes, three communication strategies, and two completely different training programmes.

Each iteration felt like starting over. Because behaviourally, it was.

Here is what agile gets wrong about human psychology. People need consistency and predictability to form new habits. When you keep changing the process every fortnight, you are not iterating towards better adoption. You are creating friction and uncertainty.

The Behavioural Reality of Change

Real behaviour change follows BJ Fogg's B=MAT model. Behaviour happens when Motivation, Ability, and Trigger align simultaneously. But here is the bit most agile change programmes miss: these three elements need time to stabilise.

Motivation fluctuates. Your team might be excited about the new CRM system on Monday but overwhelmed by their existing workload by Wednesday. Ability takes practice. The trigger needs to become automatic.

You cannot sprint your way through habit formation. It takes repetition and consistency over weeks, not iterations over days.

At Disney, we learned this lesson the hard way. Initially, we tried rapid-fire testing of different guest experience improvements. Each week brought a new approach. Staff became exhausted by the constant changes. Guest satisfaction scores actually dropped.

The breakthrough came when we slowed down. We picked three core behaviours, designed simple triggers, and stuck with them for eight weeks. No pivots. No retrospectives that changed the fundamental approach. Just consistent reinforcement until the new behaviours became automatic.

What Actually Works Instead

Start with behaviour mapping, not sprint planning. Before you build anything, map the specific behaviours you need people to adopt. Not the outcomes. The actual actions. "Log into the new system daily" is a behaviour. "Embrace digital transformation" is not.

Then identify the friction points that prevent each behaviour. Is it motivation? Usually not. Most people want to do good work. Is it ability? Often. People might not know how to use the new tool effectively. Is it triggers? Almost always. They forget, or there is no clear prompt to act.

Design for consistency, not iteration. Once you have identified the key behaviours and removed friction, commit to one approach for at least six weeks. Resist the urge to pivot based on early feedback. Human habits need time to form.

This does not mean ignoring problems. It means distinguishing between fundamental design flaws and normal adoption curve challenges. If people say "this is confusing," that might need immediate fixing. If they say "this feels different," that is exactly what you want.

Measure leading behaviours, not lagging outcomes. Agile metrics focus on working software and business value. Change metrics should focus on behaviour frequency. How many people logged in? How many used the new feature? How many attended the training?

These leading indicators tell you if adoption is happening before the business results show up in quarterly reports. They also let you spot problems while there is still time to address them without starting over.

The Action Steps

If you are currently running an agile change programme, here are three things you can do this week:

Map one critical behaviour your change depends on. Write it as a specific action someone could observe. Test if a random person could understand exactly what to do.

Commit to your current approach for the next six weeks. No major changes to processes, communications, or training. Small tweaks are fine. Complete pivots are not.

Track daily behaviour frequency. Count how many people are doing the new behaviour each day. Forget satisfaction surveys and sentiment analysis. Just count actions.

Agile revolutionised software development because it matched how code actually works. The same principle applies to organisational change. You need methods that match how humans actually change.

Sprint thinking builds software. Habit thinking changes behaviour.