The Wiggly Curve of Agile Change

Since I first penned the J-Curve of Change (over 20 years ago) in 'The Intranet Portal Guide', it has been a genuine surprise to see it pop up in all sorts of different disciplines; either largely unchanged or hugely adapted. The most curious in the latter category has been its adoption across the agile development community; not least because agile is an area very close to my heart (as a practitioner of 30 years+ from DSDM on). It's probably high time I penned a proper response. So here it is. Finally.

Big change bad. Agile change good

There is a view (amongst some) in Agile practice that smaller, more iterative changes are intrinsically better than larger 'correct systems' (or waterfall) implementations. As you will know by now, my own view is that neither is inherently better. They are just different horses for different courses. But in one small respect, I would agree. There is no doubt that - at an individual release level - smaller changes in technology produce smaller changes for the user.

What I have observed, however, is this undoubted truism can (and often does) lead on to a much more problematic failure of logic. Which can be roughly paraphrased thus:

if each sprint only introduces a small increment of change, people adapt naturally. So structured business change management is no longer necessary. Just ship, observe, adjust. The humans will sort themselves out.

Whilst I can see how such a view would form, I am also fairly sure it is wrong.

Not completely wrong — that is the point of this article. Consider it a mild rebuttal from someone who has spent more years than he cares to admit delivering large-scale enterprise transformations using Agile methods, and who has watched the "change management isn't needed here" assumption quietly detonate in the final straight of more programmes than is comfortable to recall.

The J-Curve, Kaizen, and Kaikaku

If you are not familiar with the J-Curve model of organisational change, the short version is this: when an organisation undergoes significant change, performance typically dips before it rises. People are learning new systems, new processes, new ways of working. The old muscle memory no longer applies. Things get worse before they get better. The shape this traces on a graph is a J:

The Kaizen/Kaikaku distinction from lean practice is useful here. Kaizen (改善) is continuous incremental improvement — small, persistent gains that accumulate over time. Kaikaku (改革) is radical step-change — a deliberate disruption of the status quo in exchange for a leap to a new, higher plateau. The J-Curve is fundamentally a Kaikaku phenomenon: you accept a deep temporary dip in exchange for a significantly better destination. It's Revolution rather than Evolution.

The job of the business change manager (in Kaikaku) is to mitigate the impact of the "big change" through awareness-building, training, interventions and reward mechanisms. This is reflected by the green curve on the chart above.

Introducing the Wiggly Curve of Agile

Agile practitioners will rightly point out that their method is more Kaizen in character. Each sprint is small. Each increment is modest. Nobody is being asked to absorb an enormous change all at once. And so, the argument continues, the J-Curve doesn't apply — and neither does the change manager.

Here is what I think is actually happening instead.

What Agile sprint cadence does to the J-Curve is not to eliminate it. It distributes it. Instead of one large dip, you get a series of smaller oscillations, repeated at two-week intervals across the life of the programme. Each dip is modest. Each recovery is quick. But the cumulative effect on the humans absorbing those changes is still significant — it is just much harder to see, because nobody is looking at the aggregate.

I call this the Wiggly Curve of Agile (Change):

Look at the diagram. Three curves. The grey Kaikaku J-Curve is the baseline: deep disruption, with a long recovery to the (higher) desired state — brutal, but at least honest about what it is asking of people.

The purple wiggly line is what Agile practitioners assume will happen with a Kaizen release cycle: shallow oscillations, gradual climb, arriving at the desired state with minimal disruption and no need for anyone to manage the change. It is an appealing picture. It is also, in my experience, mostly a fantasy.

The dashed green line is what actually happens when Agile thinking ignores change management. Indeed, the temporary adverse impact is much smaller than under a Kaikaku-style project — but it plateaus short of the desired state. The gap between where the green line ends and where the purple line promised to arrive is labelled on the diagram with appropriate bluntness: the dead loss of poor adoption.

That gap is the cost of assuming the humans will sort themselves out.

Some Uncomfortable Truths About Agile

The diagram makes three arguments simultaneously, and I want to be explicit about all of them. Remember, I am not an agile detractor! Far from it. But I am a realist. Agile as a practial method, used for the right sorts of challenges. Not a dogma.

First: the size of the inital impact is smaller. As I have said above. This is a good thing and undoubtedly the case. But:

Second: Agile is not quicker. This is perhaps the most persistent myth in the whole Agile canon. Every pitch for Agile methodology includes an implicit promise of speed — "faster to value," "ship early," "iterate often." And yet any honest practitioner who has delivered a large enterprise programme in Agile will quietly admit: end-to-end, it usually takes longer. Not because Agile is inefficient, but because the iterative nature (and evolving scope) means (a) some work is thrown away, (b) some areas are re-worked multiple times, and (c) it can sometimes be hard to agree when you are finished.

Hence my annotation "transition takes a bit longer". Whenever I see versions of the 'wiggly curve' they always assume the same duration for agile and waterfall. I call bs.

Third: People don't love lots of small changes. Yeah, sure, they don't much care for really really big ones either. But at least - once done - they can move on with their lives! If you haven't yet read Thinking, Fast and Slow, by Daniel Kahneman, you really should! It is undoubtedly the most important psychological work of the 21st Century.

Kahneman finds clear evidence that humans prefer one big, finite change (even if painful) to many small, repeated annoyances. Each small disruption is a "fresh episode" that requires the engagement of 'System 2 thinking'; creating a background 'cognitive load', a tendency for 'not fully resolved items' to linger on the mind (the so-called Zeigarnik effect), and a consequent 'decision fatigue' and 'change intolerance'. By contrast, the larger change has a clear beginning, a clear end, and a recovery phase, before the auto-pilot of 'System 1 thinking' can resume.

https://www.youtube.com/watch?v=QmBXhRD0yBQ

The key point is that the cost to a person of any individual change is vastly amplified from the size of the change itself, so (many) more changes - even if only small - add up to a far larger cognitive load than one large one. This manifests as 'change intolerance' and damages user adoption and thus performance.

Without any proper change management, the net result of endless small changes is a measurable gap between the end state actually achieved and the original desired state. A gap I call the dead loss of poor adoption.

Why Agile Transforms Change Management Rather Than Replaces It

So before a thousand agile practitioners review bomb this piece, I am not saying don't use agile for transformational change projects. Rather, I am saying don't assume agile methods mean you can dispense with change management altogether.

Sure, the traditional "high ceremony" change management of the big-bang comms plan, the burning platform speech, the cascade briefing to 5,000 people in a town hall — that Kaikaku thinking can be safely consigned to the trash can. But the answer is not no change management. The answer is different change management.

In the Wiggly Curve of Agile, the job of the Change Manager is to minimise the period (for the users) when 'System 2 thinking' is required and to ensure 'loose ends' are addressed almost immediately; to avoid a Zeigarnik effect cognitive load. Done well, these actions can almost completely close the gap between the purple and green lines in the diagram. Here are some things to think about:

Smaller magnitude, longer duration. You are not running a change programme with a beginning, middle, and end. You are maintaining a persistent low-level change capability for the life of the programme — and arguably beyond it. Think of it as a background process, not a project phase.

Different artefacts. The communications vehicle that works in an Agile context is not the town hall or the programme newsletter. It is something closer to Release Notes written in a user tone of voice — delivered at sprint cadence, focused on what just changed, what it means for you today, and what to do differently tomorrow. Not "here is our vision for transformation." Just "here is what happened this fortnight and here is what you need to know."

Closer to the work. Traditional change management operates at a remove from delivery — it interprets the programme to the business. Agile change management needs to be embedded in the sprint, not sat alongside it. The people doing it need to understand what was actually built, not just what the programme communications team decided to say about it.

Perhaps a different job title. These agile change champions are often referred to as a user adoption manager or (if coming from a vendor or partner) a customer success manager. A rose by any other name would smell as sweet. So it's all good with me.

Do these things, and the green dashed line moves upward toward the purple. The wiggly curve becomes what the Agile practitioners always promised it would be — rather than the polite fiction it too often remains.

Final Thoughts

The Wiggly Curve of (Agile) Change is real. The humans absorbing it — sprint by sprint, fortnight by fortnight, without anyone tracking the cumulative load — deserve someone paying attention to it.

Agile does not make change management redundant. It makes it differently necessary: smaller per sprint, persistent across the programme, written in user voice, and honest about the trade-offs. Slower than advertised. Occasionally retreading ground. But — done properly — capable of arriving at a destination that neither Kaikaku nor unmanaged Agile can reliably reach. And at a much lower initial impact on performance.

As usual, dogmatic zealotry doesn't survive first contact with reality. The Agile practitioner who insists change management is someone else's problem will eventually find it becomes everyone's problem. Usually in the post-go-live period. Usually expensively.

You know it makes sense.

Need some help?

I am now working as an independent, fractional consultant; advising clients on AI, Platforms, Cyber, and Change.

Learn More

If you enjoyed this, you might also enjoy my original article on the J-Curve of Change, or its sister piece - the "death spiral" of continuous change - on what happens when organisations do too many "transformation programmes" too often, and with too little time for their people to "exit the j-curve" from the previous change.

© David Viney 2003-2026. Licensed for re-use with attribution under CC BY 4.0

Preferred Attribution Code Snippet (HTML)

The <a href="https://www.david-viney.me/post/the-wiggly-curve-of-agile-change">Wiggly Curve of Change</a>, by <a href="https://www.david-viney.me/">David Viney</a>, licensed under <a href="http://creativecommons.org/licenses/by/4.0/">CC BY 4.0</a>

For Academic Citations (APA style)

Viney, D. (2026). The J-Curve of Change. Zenodo. https://doi.org/10.5281/zenodo.19471093

---

Like the Post?