When Scrum Practices Aren't Enough - Learning to Sense the System | Terry Haayema

Summary

---

Episode Summary: When Scrum Practices Aren't Enough – Learning to Sense the System | Terry Haayema

Podcast: Scrum Master Toolbox Podcast
Host: Vasco Duarte
Guest: Terry Haayema, International Author, Speaker, Agile Trainer, & Coach
Air Date: September 22, 2025

---

Main Theme

This episode dives into why just following Scrum practices is not enough for team success. Terry Haayema shares a pivotal story about moving beyond surface-level Scrum and learning to "sense the system"—understanding how organizational structure and metrics can drive behavior in ways that hinder true agility. The conversation centers on the importance of recognizing system-wide influences, the pitfalls of misaligned KPIs, and the evolving role of the Scrum Master as an organizational catalyst rather than just a process facilitator.

---

Key Discussion Points & Insights

1. Terry’s Accidental Scrum Journey

• [02:02] Terry recounts how he became a Scrum Master by chance, coming from a lead developer background in New Zealand.
  • Given a book as his only training, he and his team learned through experimentation:

  "We floundered about not really knowing what to do. But we were blessed to be in a space where experimenting and trying things out and getting them a bit wrong and adjusting them was okay." — Terry Haayema [02:37]

• The experience shifted his perspective from loving technical problems to finding people problems "more interesting and much more rewarding." [03:18]

2. Fail Monday: When Practices Alone Don’t Work

• [05:05] Terry shares a failure from his second Scrum Master role:
  • He focused on enforcing practices (standups, retros, planning), assuming these would suffice.
  • The turning point came when he realized the team was not responding, and systemic issues were blocking progress.
• The need to explore what was holding the team back led to the realization that broader organizational structures were undermining the Scrum framework.

3. The Power of Sensing the System

• [06:58] The organizational design separated developers, testers, and analysts under different managers and individual KPIs.
  • Example of dysfunctional KPIs:

  "We literally had KPIs for developers about less defects and KPIs for testers about finding more defects. Right. I kid you not." — Terry Haayema [09:13]

• This incentivized conflicting behaviors: developers hoarded work, testers felt pressured to find any error, and mistrust grew within the team.
• The environment bred conflict, undermining collaboration and eroding the team structure essential to Scrum.

4. Changing the System: Conversations with Leadership

• [09:02] Terry describes how they had to engage management to modify KPIs:
  • Shifted from individual to more collaborative, though still imperfect, metrics (e.g., defect leakage measured for developer and tester together).
  • Small changes fostered slightly better collaboration but highlighted the limits of change without addressing deeper systemic issues.

  "The learning for me from that was you do need to understand the system that you're in. The Scrum Master is not just the coach for the team, they're the coach for the organization as well." — Terry Haayema [10:54]

5. Scrum Masters as System Catalysts

• [11:00] Vasco emphasizes the broader responsibility of Scrum Masters:

  "We need to be looking at the end to end performance of the system. And that starts with first defining what the system is... Not the people and not individual teams either." — Vasco Duarte [11:19]

• Both highlight the need to measure and optimize the system holistically, not at the individual or even single-team level.

---

Memorable Quotes

• "People problems were more interesting and much more rewarding. Even though it's more complex, a lot harder, but it's a lot more rewarding and I love it even more than I used to love solving technical problems." — Terry Haayema [03:20]
• "I was there trying to drive processes and practices and the team were not actually responding ... the broader system was the thing that was actually driving the behaviors in the team." — Haayema [05:35]
• "You imagine in a team, people disliking each other. They don't want to talk to each other. They don't want to actually share anything meaningful when we're coming together for our various events." — Haayema [09:33]
• "Scrum Master is not just the coach for the team, they're the coach for the organization as well." — Haayema [10:54]
• "First start by defining what the system is and then start measuring that system. Not the people and not individual teams either." — Vasco Duarte [11:30]

---

Timestamps for Key Segments

• [02:02] Terry’s origin story – becoming a Scrum Master by accident
• [05:05] Main failure story: why enforcing practices failed
• [06:58] Realization: org structure & conflicting KPIs as root cause
• [09:02] Attempting system change—modifying KPIs, engaging management
• [10:54] Big learning: Scrum Master as organizational coach
• [11:19] How to define and improve the system, not just individuals or teams

---

Tone & Takeaways

The episode is candid and practical, focusing on blind spots that even experienced Scrum Masters can fall into when they limit themselves to rituals and practices rather than addressing systemic organizational blockers. Both Terry and Vasco maintain an approachable, honest, and slightly humorous tone. The central message is clear: Success in Scrum is less about following ceremonies and more about understanding and influencing the organizational system as a whole.

---

For Scrum Masters and Agile practitioners:
This episode is a prompt to look beyond daily routines, to have courageous conversations with organizational leaders, and to continuously develop your ability to sense and influence the entire system for sustainable, team-wide agility.

---

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 war free 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 this 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 Sydney, Australia, is Terry. Hi, Emma. Hey Terry. Welcome to the show.

[C]

Hey, Vasco, Delighted to be here. It's an honor to be on what's my favorite podcast. So, always happy to talk about Scrum Mastery.

[B]

And you're already my favorite guest, at least for today. So Terry is an international author, speaker, conference host, trainer, facilitator, mentor and transformative coach whose personal purpose is to help people see differently so that they can find joy. Terry, that was a short intro. Tell us a little bit more about yourself and how did you end up becoming a Scrum Master?

[C]

That's a great question, Vasco, because I never had actually at any point intended to be a Scrum Master. And in fact, when I did become a Scrum Master, I'd never heard of Scrum or Scrum Master. I was actually a lead developer on a software team, happily chugging away at traditional projects. And one day my manager came to me, he said, oh, we're going to do Scrum. Which I had no idea what that even meant. I'm from New Zealand, by the way, so Scrum for me has something to do with rugby and you're going to be the Scrum Master. I had even less idea what he was talking about at that point. And he gave me a book. He said, read that book. That was your training. So literally for 12 months we floundered about not really knowing what to do. But we were blessed to be in a space where experimenting and trying things out and getting them a bit Wrong and adjusting them was okay. And after about 12 months it was a seriously high performing team. We were doing things in that team more than, well, 20 odd years ago that I still see teams struggle with from a, from a technical excellence point of view. So as I said, I never thought that would, that would be my career. And interestingly, it transformed my whole life because I thought the thing for me was solving technical problems. I loved solving technical problems, but I actually found that people problems were more interesting and much more rewarding. Even though it's more complex, a lot harder, but it's a lot more rewarding and I love it even more than I used to love solving technical problems.

[B]

So I have a similar kind of story, although I did stop by in the project management station before I went from technical to Scrum Master. I often call myself a recovering project manager and I use recovering because I very often fall back to what I learned as a project manager. And I'm keenly aware of that, also painfully aware of that. But it is something that I'm kind of trying to bring in the best from project management without necessarily bringing in the worst because there are great practices also in the, in the project management community that we can all benefit from. But, but the people aspect is really important. And because today is Monday, Fail Monday here on the podcast, we should never forget that we are people too and we make mistakes. And in fact, that's the first question we have for you, Terry, in your learning experience as a Scrum Master and also as a coach, what is that one failure that you want to share with the community and of course also share the learning, but share that story with the community.

[C]

So just in the interest of honesty and transparency, I've had many failures. Vasco. Okay, it's not like the one I'm going to describe is the only one, but I think it's one that makes for an interesting story and a learning that we can all take from it. So I mentioned my first role as a Scrum Master was kind of accidental and it was a space where we were allowed to experiment and try things and get it a little bit wrong and then improve it, literally. My second engagement as a Scrum Master was quite different, but I didn't actually know to sense the system, to actually understand what is it about this system that drives the behaviors in the team. And I thought I was there to be Scrum Master and it's like, oh, we need to estimate with story points and have a daily standup and do all these Scrum things. Oh, we've Got to have retros and reviews and planning. And once we do all those things, everything else will be okay. Because the broader system was the thing that was actually driving the behaviors in the team. So without sensing the system, I was there trying to drive processes and practices and the team were not actually responding to it. They were not able to respond to it.

[B]

So tell us a little bit more. So we got the picture right. Like your second engagement, focusing on the practices, making sure people show up for the daily that we have the refinement sessions and so on. And at the time you didn't yet know that you weren't sensing the system. That's an important part of the story. Right. So what was that moment when you realized that, hey, wait, maybe it's not the practices that are not working, maybe something else is going on. Describe that for us.

[C]

Yeah, so it was really just struggle for a while that forced me to think, I need to look at this differently, I need to try something else because this just isn't working. And what I didn't know until I started to try different things was that the way that organization was structured, the testers reported to a test manager and the developers reported to development managers and bas reported to analyst managers. And I was there trying to operate as if this was a team. But the way the organization was structured, it was just a loose knit bunch of talented professionals. So trying to bring people together on this idea of sprint goals. And you know, when we take a story into the sprint, we need to finish it. Little things like that really didn't work until it became clear after I struggled for a while, not really getting traction, not really helping people, that actually people had their own KPIs and those KPIs were putting them into conflict with each other. What I needed to do was actually to coach the organization as much as the team. But I wasn't ready for that as a coach.

[B]

So let's explore that because that's an important insight. Often talk about how important it is to have KPIs to know what success means. But you're talking about a specific type of KPIs, and I don't know, you haven't shared, but I'm assuming you're referring to individual KPIs or performance metrics that every individual separately must adhere to, not the team as a whole, which as you said, wasn't a team yet either. Right? That's what you were referring to.

[C]

No, that's exactly right.

[B]

So how do you go about changing that?

[C]

So we had to have conversations with the leaders of the various practices. They weren't called practices then, they were just managers. And we didn't have any KPIs for a team. And we literally had KPIs for developers about less defects and KPIs for testers about finding more defects. Right. I kid you not. So the developers would hold onto things as long as possible. They try to make it absolutely perfect before sharing it with anyone. And that meant then the testers were under pressure because there wasn't time to do the testing properly. And they'd also call anything a defect. I actually had like behavioral things appearing in the team where people were literally in conflict with each other and disliking each other. You imagine in a team, people disliking each other. They don't want to talk to each other. They don't want to actually share anything meaningful when we're coming together for our various events. So we had a conversation with the various managers and the one thing we were able to do was to just modify them slightly. We didn't change the whole system to get to Team KPIs and eliminate these individual KPIs that were causing so much dysfunction. But we did get to adapt them a little bit. So rather than finding more defects, it was about defect leakage, which was kind of a different way to look at it. And we could share some of the KPIs across different people. So then the defect leakage was for the developer and the tester together. And then that allowed them to actually start to collaborate a bit better. It never got all that good. But the learning for me from that was you do need to understand the system that you're in. The Scrum Master is not just the coach for the team, they're the coach for the organization as well.

[B]

That's a very important realization, which is this idea that we need to look at Scrum Masters, of course, leaders in general. Right? Not just Scrum Masters, but Scrum Masters as kind of the triggers and the catalyst. We need to be looking at the end to end performance of the system. And that starts with first defining what the system is. Because of course, although in the story you told, it is quite obvious that individual metrics for individual people will be conflicting in some cases. It's also possible that individual team metrics for individual teams will be conflicting in some cases. And we need to look at. Yeah, exactly. And we always need to first start by defining what the system is and then start measuring that system. Not the people and not individual teams either. That's a great story. Thank you for sharing that with us. Terry.

[C]

My pleasure. As I said, I've had many other failures, but I think that's one with a good learning.

[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] membership because listening is great, it's important. But doing it together, that's next level. I'll see you in the community Slack.

[B]

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.