The Five Stages Of Agile Transformation

Tuesday 15 May 2018 at 17:00 BST

Every successful agile transformation goes through five stages.

Denial

What are you talking about? What's this "Agile" bullshit? We don't need it!

The first stage of an agile transformation is resistance. Perhaps the CEO is convinced, or perhaps there's a ground-up movement from one of the software development teams, or maybe there's a solo designer, engineer, tester or other developer pushing for change. Either way, we don't like it. And we're not listening.

It's just another fad, anyway. It'll blow over.

Anger

Why are you changing things? It was fine before you came along!

The second stage of an agile transformation is outright hostility. You've gone and done it now. You've broken everything. It was going smoothly and you threw a spanner into the works. And it's so obvious it's broken! Everyone's going slower now!

Fuck your unit tests, fuck your sprints, fuck your retrospectives, and most of all, fuck you.

Bargaining

Do we have to change everything? Our quarterly releases were fine for us. Let's do the scrum thing but release once a quarter, OK?

The third stage of an agile transformation is an attempt to cling to safety. OK, you introduced a Kanban board with work-in-progress limits, and it's helping manage the work. But it's changing too fast and we don't like it. This is good, but let's stop here, OK? No need to rock the boat too much.

We're still in the boat, after all.

Depression

Everything's changing too fast. I'll never be able to keep up with this. I can't do it.

The fourth stage of an agile transformation is a recognition that the new way breaks the old way, bringing with it a heightened fear of the future. Change is hard for everyone, and it's rare that people are prepared for it.

We're never going to be able to make this work. Pair programming is exhausting, automated testing is too hard, dealing with changes to the plan is confusing and we don't even know where we're going to be in six months.

It's all so futile.

Acceptance

It's… working, I guess?

I get it now. I think.

Things are working again. We're delivering software. People are listening to my opinion. There's a lot more communication, and that's… probably better, right? We actually know who uses the software we're responsible for, and some of them have visited our offices and had a coffee with us. We're shipping every week now, and they're happy about that. We released a couple of nasty bugs, but we fixed them really quickly and our customers loved that.

The fifth stage of an agile transformation is an understanding of the values and principles by that mother of all buzzwords, "Agile". By itself, it's meaningless. But you don't learn what it means from a book, you learn by doing.

The fifth, and last, stage of an agile transformation is the understanding that this stage is just the start.

Verschlimmbessern

Unfortunately, it's fairly rare for a large organisation to make it to the fifth stage. Even with competent professionals (who are hard to find) guiding the change, an organisation is a complex system. Every individual has their own motivations, desires and preferences, and almost none of them are interested in having their world flipped upside down on someone else's whim.

It's no surprise that many transformations are abandoned halfway through, typically when bargaining results in a Kanban-esque board with 73 items in the "Doing" column. The problem is that often, the new state is worse than the old state. The organisation is left with many of the costs of a system that responds well to feedback and iteration, but none of the benefits.

It's interesting that some agile change consultants often take a big-design-up-front approach to change management, implementing a system that won't work until all the parts are in place, projecting what the organisation will look like in two years, and following their plan to the letter.

It's funny, because we can apply agile principles to change: do the simplest thing that will work, listen to feedback, and iterate.

The downside is that it's much, much harder than it sounds.

The upside is that unlike the other way, it actually works.

Thanks to everyone in the "Self-Organising Teams" session at CITCON 2018 for inspiring this post, and especially Edward Wong for taking notes of the entire session.