Agile transformations are everywhere. Every company wants to be faster, more adaptable, and laser-focused on their customers. But let’s get real for a moment: if Agile is so great, why do so many transformations fail or even reverse?
As someone who’s been deeply passionate about Agile—evangelizing it, championing it as an industry ambassador, and living its principles—I’ve seen why. And here’s the uncomfortable truth:
Agile isn’t failing because of the framework. It’s failing because we’ve built walls between IT and the business.
The Glass Ceiling of Agile
When I first started advocating for Agile, my messages resonated with IT teams. The business? Not so much.
For IT, the shift to user stories, sprints, and backlogs was energizing—a way to reclaim control and focus on delivering value. But for anyone outside IT, Agile felt like an entirely new language:
We called ourselves customer-centric because we wrote user stories instead of functional requirements. But let’s not kid ourselves. Writing a user story doesn’t make you customer-focused. It makes you compliant with a framework. Meanwhile, the business—facing chaos, complexity, and constant demands—was left out in the cold. They weren’t partners in the transformation; they were passengers. And when things didn’t work, they were often blamed for not “getting Agile.”
- Jargon-heavy.
- Overwhelming.
- Full of demands to “bring problems, not solutions.”
We called ourselves customer-centric because we wrote user stories instead of functional requirements. But let’s not kid ourselves. Writing a user story doesn’t make you customer-focused. It makes you compliant with a framework. Meanwhile, the business—facing chaos, complexity, and constant demands—was left out in the cold. They weren’t partners in the transformation; they were passengers. And when things didn’t work, they were often blamed for not “getting Agile.”
The Missing Link: Empathy and Curiosity
I hit a turning point when I stopped looking at the business as “the customer” and started seeing them as human beings navigating their own challenges.
It wasn’t easy. I had to step off my high horse of Agile evangelism and face an uncomfortable truth:
It was humbling. And it forced me to shift my mindset, my perspective, and—most importantly—my toolkit.
- I didn’t understand the complexity of their world.
- I didn’t see the constraints they were operating under.
- I wasn’t a partner—I was an outsider expecting them to adopt my way of working.
It was humbling. And it forced me to shift my mindset, my perspective, and—most importantly—my toolkit.
Enter Design Thinking: The Game-Changer Agile Needs
Design thinking became the bridge I didn’t know I needed. It filled the gap between IT and the business, between frameworks and people. It brought humanity back into the conversation.
Here’s how:
- Empathy First
Agile often assumes the problem is already defined. Design thinking says, “Not so fast.” It forces us to understand the people, the pain points, and the bigger picture before we dive into solutions. - Reframing Problems
The business doesn’t always articulate problems in a way IT can digest. Design thinking helps both sides co-create problem statements, so everyone’s working from the same foundation. - Breaking Down Silos
Agile can feel like it’s “owned” by IT. Design thinking cuts through that ownership, creating a shared language that invites everyone to the table—IT, business, and customers. - Prototyping for Purpose
Agile excels at building fast, but speed is meaningless if you’re building the wrong thing. Design thinking ensures we’re testing assumptions before committing to costly iterations. - Unlocking True Customer-Centricity
Writing a user story isn’t customer-centric if the story doesn’t reflect a deep understanding of real needs. Design thinking brings that understanding to life.
The Provocation: Is Your Agile Truly Agile?
Here’s the challenge: Are you actually transforming, or are you just following the motions of a framework?
Agile transformations fail not because of resistance, but because they lack the tools to navigate the human, messy, and complex realities of organizations. Design thinking is that tool.
- Are you meeting the business with empathy, or are you expecting them to adapt to your way of working?
- Are you using Agile to deliver value, or are you hiding behind its language while failing to engage the real complexity of your organization?
- Are you smashing the glass ceiling between IT and the business, or are you reinforcing it?
Agile transformations fail not because of resistance, but because they lack the tools to navigate the human, messy, and complex realities of organizations. Design thinking is that tool.
What Happens When You Add Design Thinking to Agile?
When I integrated design thinking into Agile transformations, everything changed:
This wasn’t just a shift in process—it was a shift in mindset. It was about bringing curiosity, humility, and empathy to a framework that desperately needed it.
- IT and business teams stopped seeing each other as adversaries.
- Conversations shifted from “Who’s to blame?” to “How might we…?”
- Agile stopped being about compliance and started being about connection.
This wasn’t just a shift in process—it was a shift in mindset. It was about bringing curiosity, humility, and empathy to a framework that desperately needed it.
Let’s Talk About It
If you’re on an Agile transformation journey, this is your invitation to think differently. Stop relying on jargon, frameworks, and checkboxes. Start leaning into empathy, co-creation, and curiosity.
Design thinking isn’t a replacement for Agile—it’s the piece that makes it work.
Join me at the next Agile Perth Meetup as I unpack the stories, insights, and hard lessons that helped me bridge the gap and bring humanity back into Agile.
Because Agile doesn’t fail when the business resists. It fails when we forget that people—not processes—are at the center of every transformation.
#AgileTransformation #DesignThinking #EmpathyInAction
