When the Scrum Guide Isn't the Rulebook — A Scrum Master's First Conflict with Management | Mirco Gerling

Summary

Podcast Summary

Podcast: Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Host: Vasco Duarte
Guest: Mirco Gerling, Scrum Master (Public Sector, Germany)
Episode Title: When the Scrum Guide Isn't the Rulebook — A Scrum Master's First Conflict with Management
Date: July 13, 2026

---

Main Theme

This episode delves into the real-world challenges Scrum Masters face when organizational culture and established management hierarchies collide with the ideals of Agile self-management. Mirco Gerling, an experienced Scrum Master in Germany’s public sector, shares the story of his first serious conflict with management: discovering that operating strictly "by the Scrum Guide" wasn't enough in a workplace unfamiliar with its principles. The conversation centers on the struggle to define the boundaries of self-management, learning through conflict, and practical strategies for building understanding and collaboration between teams and management.

---

Key Discussion Points & Insights

Mirco’s Journey to Scrum Mastery

• Transition: Mirco began as a software developer, grew interested in improving software processes, and moved toward a Scrum Master role. The transition was not easy, as most positions required extensive experience.
• Hybrid Role Challenge: He spent about 1.5 years in a combined developer/Scrum Master role and quickly realized the drawbacks, particularly internal conflicts and role confusion, particularly noticeable during sprint ends and retrospectives.
  • Quote [03:45] (Mirco): “It was a bad idea to work as Scrum Master developer... it was difficult to prepare a retrospective and to deliver the software... I changed to a full Scrum master position after 1 1/2 years.”
• Lesson: Attempting to juggle both roles led to clarity on the importance of separation for team effectiveness.

First Major Conflict: The Scrum Guide vs. Organizational Reality

• Self-Management Misalignment: The team wanted to embrace self-management per the Scrum Guide, but management and the wider organization were not aligned or familiar with these concepts.
  • Quote [05:25] (Mirco): “I thought the Scrum Guide makes the rules, but I had to learn the organization didn’t know the Scrum Guide very exactly.”
• Confusion over Authority: There was ambiguity over decision-making power, especially about timeboxing meetings and documenting retrospectives.
  • Timeboxing Example: Mirco enforced meeting timeboxes per Scrum, but some managers pushed back, saying it wasn’t his call to end meetings.
  • Retrospective Documentation: Asking about team happiness was frowned upon by management; any visible records from retrospectives drew attention and unwanted scrutiny.
    • Quote [07:25] (Mirco): “Since then I am destroying everything from the retrospectives that could call the attention of any person.”
• The Realization: Organizational context and cultural understanding are just as critical as process knowledge.

Tools and Techniques for Navigating Organizational Tension

• Delegation Poker & Management 3.0: Mirco discovered Delegation Poker and the Delegation Board (from Management 3.0), which helped clarify decision-making boundaries and visualize the level of self-management.
  • Quote [08:32] (Mirco): “There’s a tool to make it visible, to make the level of self-management visible.”
• Fostering Open Communication: Mirco stressed the importance of consistent dialogue between teams and management to proactively surface issues and prevent unhealthy speculation.
  • Practice: Conducted regular (sprint-end or weekly) meetings with management to discuss friction points.
    • Quote [09:49] (Mirco): “In my role, I started to have a meeting after the end of the sprint with the management... It’s very important to talk with each other or talk more and more if there are problems. It’s not a good idea to close the door and speculate...”
• Building Incrementally: Vasco reinforced the value of experimenting with solutions ("there’s not only one right way"), reframing each challenge as an opportunity for joint learning.
  • Quote [10:52] (Vasco): “We shouldn’t approach these conversations with the idea that there’s only one right way... right now, we’re trying to discover the next experiment and then we’ll try it.”
• Transparency as Experiment: Vasco suggested using visibility (like deliberately leaving a poster from the retrospective) as a subtle experiment to observe management’s reactions.
  • Quote [11:57] (Vasco): “That’s a great experiment to run — to design a poster to leave behind with an expectation of a result and see if that works... almost like a secret message... designed to be learned about.”

---

Notable Quotes & Memorable Moments

• On the Hybrid Role:
  Mirco [03:45]:
  “It was a bad idea to work as Scrum Master developer... at the end of the sprint... it was difficult to prepare a retrospective and to deliver the software or to finish some tasks... I changed to a full Scrum master position after 1 1/2 year, more or less.”

• Discovering Organizational Blind Spots:
  Mirco [05:25]:
  “I thought the Scrum Guide makes the rules, but I had to learn the organization didn’t know the Scrum Guide very exactly.”

• Managing Retrospective Fallout:
  Mirco [07:25]:
  “Since then I am destroying everything from the retrospectives that could call the attention of any person.”

• Introducing Delegation Poker:
  Mirco [08:32]:
  “There’s a tool to make it visible, to make the level of self-management visible.”

• On Conversations over Speculation:
  Mirco [09:49]:
  “In my role, I started to have a meeting after the end of the sprint with the management... It’s very important to talk with each other or talk more and more if there are problems. It’s not a good idea to close the door and speculate...”

• Experiments as the Path Forward:
  Vasco [10:52]:
  “We shouldn’t approach these conversations with the idea that there’s only one right way... right now, we’re trying to discover the next experiment and then we’ll try it.”

---

Timestamps for Important Segments

• 01:59 — Mirco’s career path and transition into Scrum Mastery
• 03:45 — Lessons learned from the developer/Scrum Master hybrid role
• 05:25 — First conflict with management; disconnect between Scrum Guide and management understanding
• 07:25 — Retrospectives and managing sensitive team information
• 08:32 — Using Delegation Poker and Delegation Boards to clarify self-management
• 09:49 — Importance of ongoing management-team conversations
• 10:52 — Vasco on experimentation, adaptive learning, and creating psychological safety
• 11:57 — Playfully experimenting with organizational transparency

---

Conclusion

Mirco’s story is a candid, practical look at the realities facing Scrum Masters: that deep Agile and Scrum knowledge alone isn't enough. The key takeaway is that bridging the gap between Agile theory and organizational norms happens through continual communication, experimentation, and the practical use of tools like delegation boards. Scrum Masters must regularly clarify boundaries, engage proactively with management, and be willing to adapt—not just enforce process dogmatically.

This episode offers valuable lessons for any Scrum Master encountering resistance or ambiguity in their organizational context, emphasizing that Agile transformation is as much about building relationships and mutual understanding as it is about process.

---

Transcript

[A]

Hey there, agile adventurer, just a quick question.

[B]

What if, for the price of a

[A]

fancy coffee or half a pizza, you could unlock over 700 hours of the best agile content on the planet? That's audio, video, E courses, books, presentations, all that you can think of. But you can also join live calls with world class practitioners and hang out in a flame warfree and AI slop clean slack with the sharpest minds in the game. Oh, and yes, you get direct access to me, Vasko, your Scrum Master Toolbox podcast. No, this is not a drill. It's the Scrum Master Toolbox membership. And it's your unfair advantage in the agile world. So if you want to know more, go check out scrummastertoolbox.org membership, that's scrummastertoolbox.org Membership. And check out all the goodies we have for you. Do it now. But if you're not doing it now, let's listen to the podcast.

[B]

Hello everybody. Welcome to one more week of the Scrum Master Toolbox Podcast. And this week, joining us from Germany is Mirko Gerling. Hey Mirko, welcome to the show.

[C]

Yeah, thank you. It's a great honor for me to be a guest in your podcast.

[B]

Well, it's a pleasure to have you. So let me tell you a little bit about Mirko. He's an experienced Scrum Master in the public sector in Germany with a strong IT background. He spent 25 years developing software and driving agile transformations and he's passionate about innovation, teamwork and brings expertise and dedication to every project. So Mirko, that was a short intro. Tell us a little bit more about yourself and how did you end up becoming a Scrum Master?

[C]

Yeah, thank you for the first question. And I've been working as a software developer for a lot of years and I saw a lot of problems with the process and so I decided for me, or I found out that I would like to work in, in the higher level, on the process level, in the software development and especially in the Scrum context. And I was looking for companies that would like to employ me as a software. As a Scrum Master. Sorry, as a Scrum Master. I wanted to make the change, but it was very difficult because the most job offers were made for people with 10 years plus experience. And I had good luck and I found organization in the public sector. They said, okay, you can start as a software developer and we will,

[B]

we

[C]

will see that you can get the Scrum Master later in, in our organization. And about two or three years later I had good, good luck. That There was a free position in the, in the same project on, on my project and I could fill this position. Becoming a Scrum Master. Yes. And it was a mixed or hybrid role. I was a software developer or working as software developer and Scrum Master in the same project. After some 11 year, some months, I. I found out that it was a bad idea to work as Scrum Master developer. All the people said oh, it's not so good to do this. And I found out okay, they are right. Because there were some internal conflicts at the end of the sprint. It was difficult to prepare a retrospective and to deliver the software or to create the increment or to finish some tasks or user stories. And so I changed to a full Scrum master position after 1 1/2 year, more or less.

[B]

It's great that you got that opportunity, but I can imagine that just like that single learning journey and learning story that you shared with us right now. I'm sure there were other learning stories for you as a Scrum Master. So today's Fail Monday here on the podcast, of course. So we explore one of those stories. So Mirko, tell us a story of one of those moments where you as a Scrum Master, you still had a lot to learn and did like we all do these days anyway.

[A]

But tell us that story first.

[B]

We'll dive into the insights and lessons learned later. Tell us the story first.

[C]

And especially in this time where I was working as a developer too. It was the first time I was working as a Scrum Master and I found out there was some conflicts with the hierarchy, the management for example, where I found out that we should negotiate where are the frontiers or the limits of self management. And I had some conflicts or the team members had some conflicts where they said okay, now we are self managed team, a Scrum team and we take the decisions and the management or the organization was not aware about the idea of the self management. And there were some conflicts and that was my first experience and I, I thought that the, the Scrum Guide is the the book says or make the rules and but, but it. I had to learn that the organization didn't know the Scrum Guide very exactly. And there were some examples like time boxing in some meetings I said okay, the time box is over now. And some people said oh no, it's not your decision, it's my decision when the meeting is over. Yes, and some I have had some experiences with the retrospective. For example, when I ask if you are happy, it was not allowed to ask if the people are happy. And the manager saw the flip chart after the retrospective. And since then I am destroying everything from the retrospectives that could call the attention of any person. Yes. And especially like I said, the limits were not clear or the frontiers, for example about decision making and generally you could say the decisions, but was not clear who makes or who takes the decision. And there I found the idea of the delegation poker and delegation board. I think it's from the management 3.00 book or movement. And yeah, that was nice for me to see. Okay, other people have the same problems and there's a tool to make it visible, to make the. Great or the, the level of self management visible.

[B]

So beyond that delegation poker, we'll put the link to that in the show notes. Beyond that, delegation poker as kind of an instrument for reflection as a team and kind of finding out where the limits are. As you said, what other approaches, techniques, tools did you collect from that time that helped the teams and their of course leadership get to an agreement of where the limits for self management really are in practice?

[C]

Let me think about it. And in general I try to initiate the people talk with each other. For example, in the Sprint review, sometimes the people said, oh, we don't have time to go to the Sprint review. And each sprint we got better. And people had interest in going to the Sprint review. And especially in my role, I started to have a meeting after the end of the sprint with the management to talk each sprint or each week with the management if there are some issues, some problems, some things that went wrong. That is my experience. It's very important to talk with each other or talk more and more if there are problems. It's not a good idea to close the door and speculate about things

[B]

when there is doubt. We need to have a conversation, we need to get to a decision. And for me, one thing I would add to that is that we shouldn't approach these conversations with the idea that there's only one right way to do it. Right now we're trying to discover the next experiment and then we'll try it and if it works, great. If it doesn't, we move on. Right. Like I think that one perspective that is very useful for scrum masters out there is to understand that anyone can be wrong. And that's okay if you can move on right? But if you're wrong and you're stuck, then of course you're continuously doing something that doesn't work. But if we are able to frame things like, you know, where does the decision power lie? When can we stop a meeting. How much of the retrospective documentation should we leave behind? When we can talk about it, we can come up with an experiment. And I was just thinking, based on what you just discussed, about the fact that when you left things behind, people paid attention. I was just thinking that that's a great experiment to run to specifically design a poster to leave behind with an expectation of a result and see if that works. Right? Like almost like a secret message that nobody was supposed to know about, but actually was designed to be learned about by the people who came in afterwards.

[C]

Good idea.

[B]

Everything we do has an influence around us. That was a great story. Thank you for sharing that with us. Mirko.

[C]

No, you're welcome. Thank you.

[A]

All right, I hope you liked this episode, but before you hit next episode, here's the deal. This podcast is powered by people like you, the members who wanted more than just inspiration. They wanted real tools and real connection to people who are practicing Agile. Every day we're talking access to over 700 hours of agile gold, CTO level strategy talks, summit keynotes, live workshops, E courses, Deep Dive interviews, books, and if you're into no Estimates, we got the pioneers of no Estimates in those Deep Dive interviews as well. Agile Business Intelligence, creating product visions, coaching your product owner courses, you name it. You'll get invites to monthly live Q&As with agile pioneers and practitioners, plus a private Slack community which is free of all of that AI slop you see everywhere. And of course, without the flame wars. It's a community of practitioners that want to learn and thrive together. It's the best place to connect with community and learn together. So if this podcast has helped you before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org membership and join the community that's shaping the future of Agile. And we have so much for you. So check out all the [e-mail] membership because listening is great, it's important. But doing it together, that's next level. I'll see you in the community.

[B]

Slack we really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes? Share this podcast and let other Scrum masters know about this valuable resource for their work. Remember that sharing is caring.