Why Teams Always Adapt—And How Bad Rules Push Them Into Zombie Scrum | Danil Chernyshev

Summary

Podcast Summary:

Podcast: Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Host: Vasco Duarte
Guest: Danil Chernyshev
Episode: Why Teams Always Adapt—And How Bad Rules Push Them Into Zombie Scrum
Air Date: July 28, 2026

---

Episode Overview

This Team Tuesday episode delves into why teams are compelled to adapt — regardless of circumstance — and how poorly designed rules or rigid processes can backfire, leading to the phenomenon known as “Zombie Scrum.” Danil Chernyshev joins Vasco Duarte to share real-world stories about how teams respond to both helpful and counterproductive organizational structures, and how roles like Scrum Masters and Agile Coaches can either foster healthy adaptation or inadvertently stifle genuine improvement.

---

Key Discussion Points & Insights

1. Influential Books for Scrum Masters

• [01:24–04:02]
  Danil highlights two books that have deeply influenced his approach:
  • Actionable Agile Metrics for Predictability by Daniel Vacanti

    “That was an eye opening for me about how metrics would look like, how you actually can use metrics or team to help them improve, to help them understand what to do next and to actually use metrics for them, not just for executives.” — Danil Chernyshev [02:02]

  • User Story Mapping by Jeff Patton and Peter Economy

    “It's a go-to for me for building backlog, for understanding how to approach a big problem... Actually it’s user story mapping and user stories with the context. How to build context for the team so they understand what actually happening...” — Danil Chernyshev [03:19]

2. How Bad Organizational Rules Create Dysfunction

• [04:36–08:23]
  Danil shares vivid stories about how teams adapt to dysfunctional organizational structures:
  • Classic Matrix Organization Example:
    • Scrum Masters measured by team velocity.
    • Retrospectives monitored and logged by a manager (tracking for compliance, not improvement).
    • Manager attending Daily Scrum to enforce rigid “three questions” ritual — stifling team experimentation.
    • Result: Teams treat retrospectives as a “time ticking activity,” focus shifts to “surviving the hour.”

    “We just need to sit there. We just need to survive this hour or whatever it would be. We don’t need to discuss anything during the daily. We just need to go through. No conversation, no checks, no adaptation, no questions.” — Chernyshev [05:28]

    • Completion of stories is manipulated to fit reporting needs (splitting stories rather than delivering increments).
  • Agile Coach Overreach Example:
    • Mandated team norms review based on a roadmap—not what the team needed in the sprint.
    • Teams forced to discuss irrelevant topics during retrospectives, disrupting useful adaptation.

    “By the end of the sprint we [were] mandated to spend time on a completely different topic which [was] irrelevant to this particular sprint. So those boundaries once again they broke. Adaptiveness, they broke.” — Chernyshev [07:52]

  • Core Insight:
    • In both, teams aren’t to blame—they are adapting to survive within imposed limitations.
    • These adaptations breed “Zombie Scrum”: teams go through motions but aren’t genuinely improving.

3. The Inevitability—and Nature—of Adaptation

• [08:23–10:37]
  Vasco and Danil reflect on the essence of team adaptation:
  • Teams always adapt—the question is “to what?”
  • Example:
    • Scrum introduced adaptation to timeboxes; Kanban introduced adaptation without timeboxes.
    • Adapting to imposed rules vs. adapting to collective goals/product value.
    • Negative adaptation shifts team focus from meaningful improvements to simply “surviving the rules.”

    “Team was focused not on the adaptation of the process to make best of them and best of the product, but they spent effort on figuring out how to survive in this job with given roles and given boundaries and given rules. So it’s switching focus from productive work and enjoyable work to actually zombie Scrum and surviving.” — Chernyshev [10:03]

4. Servant Leadership: The Role of Leadership in Team Adaptation

• [11:43–12:12]
  • It’s not about dictating rules but facilitating adaptation towards delivering value.
  • Servant leadership means removing barriers, not creating them through bureaucracy.

    “The role is to help the team adapt to an overall goal or value delivery. We often talk about value. Right? That’s what we should be adapting to, right?” — Vasco Duarte [11:43] “Completely agree with you, Vaska. Yes, yes, absolutely.” — Danil Chernyshev [12:06]

---

Notable Quotes & Memorable Moments

• On metrics and transparency:
  “After that book you will probably know that a lot of cumulative flow diagrams that you saw in your past, they doesn't work well and needs to be rebuilt so they don't show what they supposed to, etc.” — Danil Chernyshev [02:38]
• On zombie Scrum:
  “We don't need to discuss anything during the daily. We just need to go through. No conversation, no checks, no adaptation, no questions.” — Danil Chernyshev [05:37]
• On surviving, not thriving:
  “...they are still not telling them how to work. They are literally telling them, hey, adapt to my expectations. That's the only thing that we can do, right?... We can't define or dictate what motivates people. We can only define or dictate rules that their motivation will allow them to adapt to.” — Vasco Duarte [11:17]

---

Important Segment Timestamps

• Book Recommendations & Agile Inspiration: [01:24–04:02]
• Stories of Dysfunctional Team Adaptation: [04:36–08:23]
• Team Adaptation vs. Zombie Scrum: [08:56–10:37]
• Leadership’s True Role in Adaptation: [11:43–12:12]

---

Tone and Takeaways

• The conversation is honest, practical, and rooted in direct experience "from the trenches."
• Both speakers emphasize respect for teams’ innate adaptiveness, while warning against bureaucratic rules that undermine genuine agility.
• The main takeaway: Leaders and change agents should focus not on enforcing rules but empowering teams to adapt in ways that lead to value, learning, and product excellence.

---

This summary captures the essence and tactile wisdom from Danil Chernyshev’s guest appearance, and provides a useful reference for agile practitioners seeking to avoid the pitfalls of Zombie Scrum and nurture autonomous, value-driven teams.

Transcript

[A]

Hey there agile adventurer, just a quick question. What if for the price of 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 our Team Tuesday. This week we have with us Daniel Chernyshev. Hey Daniel, welcome back.

[C]

Hello. Thank you for having me. And happy Tuesday everybody.

[B]

Happy Tuesday. That's a great way to put it. So we'll talk about teams because it is Team Tuesday here on the podcast. We'll talk about teams in a second. But before we go there, do share with us. Daniel, what's the book that most inspired you in your career as a Scrum Master?

[C]

Probably I will name two. That was a difficult moment to choose something and I want to mention two books. Actionable Agile Metrics for Predictability by Daniel Vacanti. That was an eye opening for me about how metrics would look like, how you actually can use metrics or team to help them improve, to help them understand what to do next and to actually use metrics for them, not just for executives and actually to help executives as well with transparency with everything. So that's mind changing. And after that book you will probably know that a lot of cumulative flow diagrams that you saw in your past, they doesn't work well and needs to be rebuilt so they don't show what they supposed to, etc. And the second book is user Story Mapping by Jeff Patton and Peter Economy. That's another tool that when I acquired it to my toolbox and using it's a go to for me for building backlog for understanding how to approach a big problem. Even actually for myself for personal tasks. That's the tool that I use to build work breakdown structure, let's call it that way. Actually it's user story mapping and user stories with the context. How to build context for the team so they understand what actually happening and what's going on and what is the path, how we approach the product and what is our goals and challenges building these common understanding and tackle the big problem that actually can be tackled without that. Or it can, but it's the most convenient way that I found. Absolutely.

[B]

We'll put the link to those books in the show notes and both of the authors have been on the podcast before so make sure you check the episodes with them. They're also linked in the show notes Daniel Vacanti and Jeff Patton have been on the show before but Daniel now we turn our attention to the teams and how sometimes they can become their own worst enemies and create an environment for whatever reason that eventually leads to big problems in the team. So tell us that story Daniel.

[C]

Well, I believe that distractions actually comes from different reasons and from the root cause might be different but the most common is organizational structure and practices within the organization teams just trying to adapt the reality. For example, I worked in a classic matrix organization where Scrum masters reported to a dedicated manager and that manager tried to measure Scrum Master success and effectiveness by checking team velocity or another example, this manager actually checked and registered tracked retrospectives in a separate retrospective lock that he maintained and he may show up during the daily scrum and check that everybody in the team answers three questions that actually waved a room for any experiments. You can understand that the result was that retrospective became a time ticking activity. We just need to sit there. We just need to survive this hour or whatever it would be. We don't need to discuss anything during the daily. We just need to go through no conversation, no no checks, no adaptation, no questions. A lot of dysfunctions came there and for velocity for sure we end up with having half finished stories that in the end of the sprint Sprint will not even spill over to the next sprint but split. The previous story was closed as done. A new one opened in the new sprint with the additional part in the name part two. Like we never had done increment in this case and I cannot blame the team in this case because they tried to adapt. They tried to survive those rules and those boundaries. That's very important to empower teams to do what they need to do, have them self managed and give them an opportunity to deliver what they promised as a done increment. The same problem. I also faced with maybe some examples with agile coaches. I had an example when agile coach mandated that based on the roadmap that they had teams have to do their team norms review. During that sprint, my team faced face the problem. They decided not to spend any time on discussion how it happened during the sprint. Just do whatever it needs now and discuss during the retro. But by the end of the sprint we mandated to spend time on completely different topic which irrelevant to this particular sprint. So those boundaries once again they broke. Adaptiveness, they broke.

[B]

Okay, so let me ask a follow up question there Daniel, because the first story you shared is the rules came from the manager and the team adapted to that. The second story you shared is the rules came from the agile coach and the teams adapted to that. Now you said the teams couldn't adapt, but obviously you meant they couldn't work in a self managed way, right? Like, because even following rules is an adaptation.

[C]

Yes, you're right. They adapted to those rules for sure.

[B]

What I wanted to explore is exactly that process of adaptation, right? Because when we work with teams the only certainty is that they are adapting to whatever is thrown at them. Right? Like we can't actually prevent the team from adapting. We can only decide what they need to adapt to. Right? Like for example, Scrum is a great example. We decided collectively as an industry, we decided that Timebox is something teams should adapt to. Right? Like, and there's all kinds of consequences to that. And then Kanban came up and said, hey, we don't think this is a good adaptation. Let's work without time boxes. Right? Which is again another adaptation because we always need to adapt. So when you look back at these two stories, what do you think was particularly negative for the teams in the way that they decided even implicitly to adapt to the rules that were being dictated to them.

[C]

Let me formulate it. Team was focused on the not on the adaptation of the process to make best of them and best of the product, but they spent effort on figuring out how to survive in this job with given roles and given boundaries and given rules. So it's switching focus from productive work and enjoyable work to actually zombie Scrum and surviving.

[B]

I think that's a great way to put it. Right. Because we can decide that we want the team to adapt to creating a great atmosphere and reaching their goals, then we need to dictate goals because then they adapt to the goals. Or we can decide that we want them to adapt as trying to survive within a set of rules, also known as bureaucracy, by dictating that bureaucracy and they will adapt to that. Right? And I think that the stories you shared are a great example of how even when we try to tell them. Meaning management leadership tries to tell a team how to work. They are still not telling them how to work. They are literally telling them, hey, adapt to my expectations. That's the only thing that we can do, right? Because we, we can't define or dictate what motivates people. We can only define or dictate rules that their motivation will allow them to adapt to.

[C]

I believe that's a great way to put it. Yes, for sure.

[B]

And that's why we need the servant leadership, because we need to recognize that the role is to help the team adapt. The role is not to dictate rules, although some rules will be necessary. The role is to help the team adapt to an overall goal or value delivery. We often talk about value. Right? That's what we should be adapting to, right?

[C]

Completely agree with you, Vaska. Yes, yes, absolutely.

[B]

That's adaptation. Great. Let's say model to have in mind at all times. So thank you for sharing that story, Daniel.

[C]

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. We have so much for you, so check out all the [e-mail] 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.