When a Hub-and-Spoke Executive Hijacks Your Agile Transformation — And What to Do About It | Peter Merel

Summary

Episode Overview

Title: When a Hub-and-Spoke Executive Hijacks Your Agile Transformation — And What to Do About It
Podcast: Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Host: Vasco Duarte
Guest: Peter Merel
Date: May 5, 2026

In this episode, Vasco Duarte interviews Agile coach Peter Merel about organizational dynamics that can derail Agile transformations, focusing specifically on the risks posed when a powerful "hub-and-spoke" executive attempts to center Agile practices around themselves. Through the lens of a real-life case study in a major Australian bank, the conversation explores essential lessons, strategies for avoiding similar pitfalls, and the distinction between “push” versus “pull” change approaches in Agile initiatives.

---

Key Discussion Points & Insights

Rethinking "Scrum Master" and Agile’s Ancient Roots

[01:11]

• Peter Merel challenges the term "Scrum master":

  “You call someone a master, it makes everybody else a servant. I would rather be in a servant leadership role. I would rather get a team or a business to a place where they self-organize for mutual benefit.” ([01:26], Peter Merel)

• Agile principles from 3,000 years ago:
  Peter reflects on how the fundamental challenges of throughput, waste minimization, collaboration, and self-organization existed as far back as the agricultural revolution.

  “All of the stuff that we do now was a problem back then.” ([01:56], Peter Merel)

• The influential book(s):
  Peter is inspired by ancient texts, particularly Lao Tzu, which he interprets as guidance for organizational agility—not just philosophical wisdom.

  “If you look at the pictograms, the sage is Shengren... responsive, competent, lively, engaged, agile. This is a book about agile people and agility, and it always was.” ([04:18], Peter Merel)

Case Study: When an Executive Becomes the Hub

Context: The Westpac Engagement

[06:35]

• Merel's role:
  Peter was brought in, post-success at Commonwealth Bank, to replicate an Agile transformation at another of Australia’s “big four” banks (Westpac).

• Leadership dynamics:

  “This gentleman... very clever, very powerful, very mercurial executive... everything he’d read about Agile led him to conclude that this was an ideal form of micromanagement.” ([07:36], Peter Merel)

• Team atmosphere:
  The executive expected Agile to revolve around himself, stifling independent team interactions and attempts at decentralized, self-organizing practices.

• Problem escalates:
  As Peter facilitated horizontal conversations away from the executive’s direct line, the exec felt threatened and marginalized—escalating resistance.

The Turning Point

[09:07]

• Professional risks:
  In Australia’s limited Agile consulting market, one’s most recent engagement defines future opportunities. Peter’s honesty with the executive about necessary alignment led to his exit:

  “If we didn’t find a better way for him and I to align… to him that read as ‘well, there is no better way for us to align… I don’t have a problem, you have a problem—and I can get rid of your problem.’” ([09:31], Peter Merel)

• Personal impact:
  The fallout forced Peter to reconsider his future in Agile coaching altogether.

Push vs. Pull — Transformation Paradigms

[11:10]

• Critical reflection:
  Peter distinguishes between “push-based” and “pull-based” change:

  • Push-based: Forcing change top-down, which seldom gains traction.
  • Pull-based: Building a “thin steel threaded” capability—small, dedicated cross-functional teams demonstrating success and attracting adoption organically.

  “What I’d been hired to do at Westpac was push-based... which never works. The way that we need to go about this... build a thin steel threaded capability from business all the way through to DevOps... prove that it works. Having proved that it works, we’re going to grow it.” ([11:19], Peter Merel)

• Advice for practitioners:

  “Anyone who’s in a situation like this needs to make a decision. Either you’re going to do what you know works or you’re going to step away. Either way, you’re not going to do damage to your client. If you’re in a situation as I was where you can’t do either of those things, then you are the problem.” ([12:37], Peter Merel)

The Ripple Effect

[13:12]

• Continuing to compromise or participate in flawed change initiatives can “make it difficult for the next person,” impacting both the client and future coaches.

  “I hired a particular coach that I had mentored before to replace me and he made a pretty good go of it, but it didn’t make his life easier by what I’d done.” ([13:19], Peter Merel)

---

Notable Quotes & Memorable Moments

• On the term Scrum Master:

  “You call someone a master, it makes everybody else a servant.” ([01:26], Peter Merel)

• On the timelessness of Agile:

  “Software was agriculture and development was domestication... Everything that we do now was still relevant.” ([02:08], Peter Merel)

• On Agile as micromanagement gone wrong:

  “…everything he’d read about Agile led him to conclude that this was an ideal form of micromanagement.” ([07:36], Peter Merel)

• On being true to proven change strategies:

  “Either you’re going to do what you know works or you’re going to step away.” ([12:37], Peter Merel)

---

Timestamps for Important Segments

• 01:11 – The problem with “Scrum Master” and servant leadership
• 03:49 – Applying ancient wisdom (Lao Tzu) to Agile
• 06:35 – Case study: Starting work at Westpac, executive as central hub
• 07:56 – The problem with Agile as micromanagement
• 09:31 – Alignment, conflict, and professional risk
• 11:10 – Push vs. pull-based transformations; actionable advice
• 13:12 – The legacy of toxic change and ripple effects

---

Summary Takeaways

• Agile transformation fails when it becomes centered around a dominant executive (“hub-and-spoke” leadership).
• Push-based change (top-down imposition) rarely succeeds. Pull-based, organically growing approaches yield better results.
• If a transformation approach disempowers teams or perpetuates micromanagement, coaches must make hard choices: stick to proven methods or walk away.
• Legacy matters—compromises or failed change efforts impact future coaches and the organization long after the initial engagement ends.

Peter’s hard-won wisdom: “Do no harm. Stick to your principles—even if that means moving on.”

Transcript

[A]

Hello everyone.

[B]

Quick heads up before we start today's episode. The Global Agile Summit is happening on May 4th. Yes, May 4th. And even with a big blowout Star wars party, you have to join. It will be online and it's like always free to attend. We have four tracks this year that I'm really excited about and I think you will too. Stick around to the end of the episode to know what they are. If you want to check it out already now you can check it out at bit ly globalagile 26. That's the numerals 2 and 6 at the end. So one more time, that's bit ly globalagile 2, 6, all one word, all lowercase. And 2 and 6 are the numerals 2 and 6. So stick around till the end of the episode and I'll tell you what's in store. But for now, on to today's episode.

[A]

Hello everybody. Welcome to our team Tuesday and this week we have with us Peter Merrill. Hey, Peter, welcome back.

[C]

My pleasure.

[A]

So, Peter, on Tuesdays we talk about teams and how sometimes they create their own problems. But before we dive into that, share with us what's the book that most influenced you in your career as a Scrum master?

[C]

Well, so again, I have to object to the term because I kind of think it's an incredibly badly chosen term at the moment. You call someone a master, it makes everybody else a servant. I would rather be in a servant leadership role. I would rather be someone who doesn't have a special name and I would rather get a team or a business to a place where they and self organize for mutual benefit. That means working on the reward model. It means working on the accounting paradigm. It means a lot of things that we don't think about in the context of Scrum at all. Scrum solves the wrong problem. And so that's where we get to the book that most influenced me. And it's one I'm still editing. So I don't mind tooting my own horn on this because this particular book has been writing itself for 3,000 years. This is a book about Agile that began in days when software was agriculture and development was domestication. Back at the dawn of the agricultural revolution, everything that we do now was still relevant. We were still trying to maximize throughput, we were still trying to minimize waste. We were still trying to get people to collaborate and self organize for mutual benefit. All of the stuff that we do now was a problem back then. And when we talk about teams and we talk about how we can get harmonious organizations to align not just as humans, but now as humans aligning with AI and as machines aligning with the humans. All of these problems existed 3,000 years ago. There's a book called or Lao Tzu, and it's a really bad book. The reason it's a really bad book is it's been jumbled and shuffled and made into a bunch of religious ideas. But as far as I can figure out, it was originally about how we get agile development to happen in organizations large and small.

[A]

That is an interesting interpretation. So now I'm curious. So what is the book that you're writing and where could people go to get an early view into that writing and how you can frame Sun Tun's book in that way?

[C]

So I first started translating this book in 1989, and I produced a version that got pretty popular in academic circles. I released it under a new public license. It wound up getting used as the bible of the Dudists, people who love the movie the Big Lebowski. And that sort of sent me back to the drawing board. If you go to Agile Way PM the book is called the Agile Way now. And the reason it's called the Agile Way is if you read most translations of Lazu, they talk about the sage, who's apparently a very wise and enlightened guy. And the sage does this and the sage does that. If you look at the pictograms, the sage is Shangren Ren is just personal people. Sheng is responsive, competent, lively, engaged, agile. This is a book about agile people agility, and it always was. And when you look at the etymology of the words in it, which I've now been doing for the better part of four decades, you see correspondences between that and not just the Scrum ideas, not just the XP ideas, not just Lean and not just Theory of Constraints and throughput accounting and permaculture. All of that stuff is critically important to different kinds of transformation today. But you see those themes there. Not because those things are based on explicitly on this, but because the same problems had similar solutions back then.

[A]

We will come back to that book, I'm sure, in a bonus episode. I'll definitely send you an invite for us to record a bonus episode on the book itself because that sounds like a lot to dig into, but I'll put the link in the show notes so that people can find it easily. And now we turn our attention to to the teams and how sometimes they become their own worst enemies. So Peter, tell us the story of a team, what they were doing, give us A little bit of the context. And then what was that behavior or approach or practice that developed and over time became self destructive for the team.

[C]

Okay, so I had a brief role for another of Australia's four large banking groups and one of them is a group called westpac. And so after the big win at Commonwealth bank, it was natural for me to hop over there and I found an executive who wanted to support me in doing exactly the same thing. At least that's what I thought. But I'm pretty certain everybody has encountered something like this. And this was the most extreme form of it I've ever seen. This gentleman, and I will not name him, very clever, very powerful, very mercurial executive. And he was in charge of a division of the bank that was absolutely central to their global markets play. And he had some products that are very popular in Australia today. And I don't want to take anything away from him professionally at all. But everything he'd read about Agile led him to conclude that this was an ideal form of micromanagement.

[A]

I know some of those people.

[C]

Yeah. So when I came in, he had rolled up the red carpet, everybody knew I was coming, everybody was ready for the guru was going to turn up. And I kind of hate that because I'm not there to be a guru. I'm there to help other people see eye to eye. And if everybody's watching me, then there's a problem. But that wasn't the problem. The problem was that the group that he was working with, that he'd hired on, they were very creative, they were very driven, they were passionate, competent people. But they all revolved around this particular executive and very much, this is my sports car, I'm going to drive it the way I want to, kind of a chat. So I described a lot of work that he liked the sound of and started putting pieces in place and started aligning conversations. And this was the problem because I was making conversations happen that didn't hub on this particular individual. And the more that happened, the more he felt disempowered. And I was blind to it. I had never seen this kind of behavior before. And I had a different problem. The problem was I had a young family based in Sydney. And Sydney, well, Australia is a long way away from everywhere else. So if you're going to have continuity of employment as an Agile coach for large work in Australia, there's only a certain number of places you can go and your most recent gig is pretty much your name. So when this particular engagement hit point where I said to this Gentleman that if we didn't find a better way for him and I to align that we were going to have trouble to him that read as well, there is no better way for us to align. So I don't have a problem. You have a problem and I can get rid of your problem. So for me, that was a problem I could only solve by walking out of the idea of being an agile coach. And this is after about 15 years of active coaching. The only way that I was going to get professional continuity is to come up with something new. I had a choice of either going somewhere else or moving my family somewhere else, or reinventing myself.

[A]

You were finding that. So you were a consultant at the time. So working with a client in a collaborative manner is a must because consultants can be let go very quickly. And when you look at this experience and then also reflecting on what you did, then what advice do you have for us who might be even right now as we're listening to this podcast in that kind of situation?

[C]

So you have to think about whether you are doing damage or not. When I walked in there, if I had read the situation right, I would have framed it quite differently. I would have been talking in terms of something that I came up with on reflection about why the Commonwealth bank gig had worked so well. And I called it a pull based transformation. What I'd been hired to do at WESTPAC was push based. The idea was that it was going to be a change paradigm and we were going to push change into the organization, which never works. The way that we need to go about this, if we're going to frame it right is we're going to build a thin steel threaded capability from business all the way through to DevOps. And just a few people, maybe a dozen, maybe two dozen people, we're going to plug this together outside of the existing organization and we're going to prove that it works. And having proved that it works, we're going to grow it. Now, I had done that at a number of insurers and the Commonwealth bank and that worked great. I needed to stick to my guns and go, all right, here's how we're going to go about this. I let myself be persuaded that no, we were going to do push. I wound up compromised. So I think anyone who's in a situation like this needs to make a decision. Either you're going to do what you know works or you're going to step away. Either way, you're not going to do damage to your client. If you're in a situation as I was where you can't do either of those things, then you are the problem.

[A]

And we need to be, I guess, true to what we believe works. If we're doing work like this change of influencing the future of a team or an organization, because otherwise we will get lost

[C]

and we will make it difficult for the next person. As I did there. I hired a particular coach that I had mentored before to replace me and he made a pretty good go of it, but it didn't make his life easier by what I'd done.

[A]

Yeah, absolutely. Thank you for sharing that story with us, Peter.

[C]

My pleasure.

[B]

Hi there friends. Thanks for sticking around till the end of the episode. So let me tell you what's coming on May 4th. We're running the Global Agile Summit. It will be online and I want you there this year. We have four tracks and each one is built around real conversations with practitioners. No slides, no keynote theater, just honest interviews with people doing the work, just like you. The first track is AI in organizations where practitioners show what actually works. No hype, just AI that makes your Monday better. Happy Monday, everybody. And then we have the people track honest conversations about putting humans at the center of how we work and keeping them there. And third is Agile in construction. And yes, I really mean brick and mortar construction. Lean and Agile. Actual job sites. Field leaders Removing waste. Teams transforming how buildings get built. Stay tuned for what I think will be a super track on Agile in construction. And the fourth track is Agile in Gaming. How game studios ship without burning out Agile Inside the Creative Pressure Cooker over the years, we've had more than 12,000 participants since 2017, the time of the first summit organized with the podcast. And this year we're making it easier than ever to join. You can register for free and get access to the summit sessions live during the event week. That's May 4th to May 6th. Or you can grab the Practitioner Pass and get immediate access to last year's keynotes from Jurgen Apollo, Gojko Adi and Miretech Kangas right now, even before the Summit starts. So grab your Practitioner Pass and start learning today. Head on over to bitly globalagile 26. That's 2, 6. The numerals 2 and 6 sign up and I'll see you on May 4th. And one more time, here we go. Bit ly globalagile 26. All lowercase, all one word and 26. That's the numeral 2 and the numeral 6. I'll see you on the conference floor.