Don't Transform Your Team. Confront Reality Instead.
Best process emerges from friction, not frameworks.
Why I Never Do Agile Transformations
I’ve never done an Agile transformation. Not because I don’t believe in Agile principles. I do. But “transformation” is just the wrong word for what actually works.
Early in my career, I was involved in a massive product rewrite. The work was hidden from reality, from real customers, for about a year. Engineers built feature after feature in isolation, convinced they were making progress.
Then we shipped.
That’s when real work has begun. Critical paths broke. Assumptions crumbled. Everything we thought we knew had to be renegotiated with reality. A year of “progress” became months of painful course correction.
That experience taught me something I’ve applied to everything since. Work needs to be confronted with reality as soon as possible, in small meaningful steps.
This applies to code. It applies to products. And it absolutely applies to how you change a team’s process.
The Problem with Big Bang Transformations
When someone hires an Agile consultant to “transform” their team, here’s what usually happens:
Consultants arrive with a framework
Everyone gets trained on new terminology
Existing workflows are ripped out
New ceremonies are installed
Team spends months fighting the process instead of doing the work
Consultants leave
Team quietly reverts to what actually works
I’ve seen this pattern destroy trust and kill momentum. Teams don’t resist change because they’re stubborn. They resist because they know something the transformation plan doesn’t account for. Context matters.
Every team has invisible load-bearing walls. Rip them out without understanding what they support, and the whole thing collapses.
What Works Instead
I was always a fan of changing things step by step. Evaluate. Adjust. Let the process emerge naturally from real friction rather than from a book.
The thing is, most teams are already doing some version of good practice. They just don’t have names for it.
My approach is to apply one principle or pattern at a time. And to stitch it into the existing workflow, not replace it. The framing I use sounds like this:
“We’re doing this anyway. Now it’s just a little more structured and guided.”
That’s it. No revolutionary manifestos. No burning the boats. Just: this thing you’re already doing? Let’s make it more intentional.
A Concrete Example
Say a team has some informal way of tracking work. Maybe it’s a spreadsheet. Maybe it’s Slack threads. Maybe it’s just “everyone kind of knows what they’re working on.”
Step one isn’t “implement Kanban.” Step one is add a proper board that reflects what people are actually doing. See my other related post here:
Then you coach on one principle: move things from left to right as fast as possible. Not “finish as many tickets as you can.” Not “maximize velocity.” Just: whatever you start, finish it before starting something new.
Then you observe. What’s getting stuck? Why? Does it need an additional status? A handover? A review step? Someone to unblock it?
The process reveals itself through friction. Your job is to notice the friction and give it structure. Not to impose structure and hope it reduces friction.
Why This Works
Big transformations fail because they treat process as something you install. But process isn’t software. You can’t deploy it and walk away.
Best process emerges from real friction.
When you change things incrementally:
Team understands why each change exists
Changes that don’t work can be reversed without drama
You build trust instead of burning it
Reality tests your assumptions continuously
When you do a big bang transformation:
No one understands why anything is the way it is
Reverting feels like admitting failure
Trust erodes with every imposed ceremony
You find out what’s broken only after everything’s broken
The Engineer’s Mindset
Looking back, I never made the mistake of doing a big bang transformation. I was intuitively doing the right thing from the beginning. But I didn’t learn it from management books.
I learned it from building systems.
That failed product rewrite taught me that hiding work from reality is always a mistake. Ship small. Get feedback. Adjust. Repeat. The longer you wait to confront reality, the more painful the confrontation will be.
Process change is the same. Each change should be small enough to evaluate, meaningful enough to matter, and reversible enough to survive being wrong.
The Bottom Line
If someone asks me to do an Agile transformation, I say no.
If someone asks me to help their team work better, I say:
let’s look at where you’re stuck, and fix one thing at a time.
That’s not as exciting as a transformation. It doesn’t come with a certification or a framework diagram. But it actually works.
Because the goal was never to do Agile. The goal was to build better products with less pain.
And that happens one small, meaningful step at a time.