The High Cost of Unsafe Agile Retrospectives | Terry Haayema

Summary

---

Podcast Summary

Overview

Episode Title: The High Cost of Unsafe Agile Retrospectives
Podcast: Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Host: Vasco Duarte
Guest: Terry Haayema
Date: September 23, 2025

This episode explores the critical role of psychological safety in Agile teams, focusing on a real-world case where a single misstep during a team retrospective led to the rapid breakdown of a once-cohesive team. Terry Haayema shares candid lessons on how leadership actions can make or destroy team trust, why retrospectives must remain protected spaces, and concrete steps managers can take to support—not sabotage—collaboration and learning.

---

Key Discussion Points and Insights

1. Most Influential Books for Scrum Masters

[01:22 – 02:58]

• Terry highlights Agile Software Development with Scrum (Ken Schwaber & Mike Beadle) as foundational for starting out as a Scrum Master.
  • “It was massively influential because it started my journey as a Scrum Master… By the time you’ve read it, you’ve got a good idea what it’s about.” – Terry Haayema, [01:46]
• His top recommendation: The Five Dysfunctions of a Team (Patrick Lencioni).
  • “If there’s a lack of trust, you’re not going to get anything else… [It’s] a really, really, really good read if you’re working with teams.” – Terry, [02:07]

---

2. Anatomy of Team Breakdown: The Cautionary Tale

[03:58 – 06:37]

• Terry recounts his experience with a team operating as a "feature factory," working in silos and lacking holistic integration.
• The turning point was the positive influence of a business analyst (BA), described as the team’s “mum,” who fostered cohesion and supported Agile change.
• Catastrophe struck when this BA, after voicing a candid improvement point in a retrospective, was challenged and performance-managed by her direct manager. She soon left the team.
  • “She was actually the glue that held the team together… Unfortunately, she mentioned something at a retrospective that then got back to her manager... and ended up putting her on performance management. She left.” – Terry, [05:10]

---

3. Aftermath: Erosion of Trust and Team “Self-Destruction”

[06:37 – 09:20]

• The team reverted to old patterns: individualism, disengagement, lack of collaboration, increase in rework and defects.
  • “Right back to working as individuals… right back to not really caring and engaging as we’re refining work and planning work… There was very much that lack of teamness.” – Terry, [06:44]
• The sense of psychological safety was lost; retrospectives became viewed as dangerous, not supportive.
  • “If it’s not safe to say [something] and you’re going to be put under performance management, that kind of leads people to think, well, all of this stuff is putting me in a place of danger.” – Terry, [09:20]
• Vasco summarizes the risk:
  • “When there is no safety, then there can be no openness. And if there’s no openness, you can’t collaborate.” – Vasco Duarte, [10:13]

---

4. The Crucial Role (and Risk) of Leadership Influence

[10:49 – 11:45]

• Leaders can, through a single action, “destroy work that takes weeks or months to do.” Trust, belonging, shared future—critical to team success—can be shattered quickly.
  • “Leadership can, with a single action, destroy work that takes weeks or months to do.” – Vasco, [10:49]
• Terry highlights leadership’s power to create as well as destroy:
  • “They can support [safety] as well… If you’re leading a space and you can hold that space open… you can actually create a space where innovation flourishes.” – Terry, [11:17]

---

5. What Should Managers Do? Leadership vs. Reactiveness

[11:45 – 14:28]

• Terry: Instead of reacting to what’s heard from retrospectives, managers should approach with curiosity.
  • “I would always encourage leaders to ask questions rather than make statements… Listening to understand rather than just responding… is a much stronger way to be a leader.” – Terry, [11:59]
• Vasco clarifies the distinction:
  • “Responsiveness—or reactiveness, I think is the more correct word—is about reacting… without thinking about long-term consequences… and leaders should not be reactive because of their responsibility and their immense influence on their teams.” – Vasco, [13:05]
• Terry agrees and focuses on the leader’s responsibility to “hold the space open,” based on trusting people’s good intentions, supporting rather than micromanaging:
  • “Everyone here is doing the very best they can with what they have… If you start from that assumption… your responses will be more supportive of the people in the system.” – Terry, [15:24]

---

6. Closing Thoughts

[16:11 – 16:21]

• Leadership’s greatest role is to be supportive and foster psychological safety.
  • “Supportive is a key word, I think, for leadership. Be more supportive of the people in the system.” – Vasco, [16:11]

---

Notable Quotes (with Timestamps)

• On influence of team books:

  • “If there’s a lack of trust, you’re not going to get anything else…”
    — Terry Haayema, [02:07]

• On the cost of unsafe retrospectives:

  • “She was actually the glue that held the team together… Unfortunately… she left. And then the team that suddenly lost its mum… started to self destruct in a really rapid way.”
    — Terry Haayema, [05:10]

• On leadership’s power:

  • “Leadership can, with a single action, destroy work that takes weeks or months to do.”
    — Vasco Duarte, [10:49]

• On psychological safety and collaboration:

  • “When there is no safety, then there can be no openness. And if there’s no openness, you can’t collaborate.”
    — Vasco Duarte, [10:13]

• On leadership mindset:

  • “Everyone here is doing the very best they can with what they have… your responses will be more supportive of the people in the system.”
    — Terry Haayema, [15:24]

---

Timestamps for Important Segments

• [01:22] – Books that shaped Terry's approach to Scrum
• [03:58] – Start of the team breakdown story
• [05:10] – Why and how the BA’s departure triggered collapse
• [06:44] – Regression to individualism and lack of trust
• [09:20] – Loss of psychological safety and retrospective danger
• [10:49] – Leadership’s destructive power in a single moment
• [11:59] – The right way for managers to respond to problems
• [13:05] – Leadership vs reactivity debate
• [15:24] – Leaders should assume teams do their best and support them
• [16:11] – Final reflection on supportive leadership

---

Conclusion / Takeaways

• Retrospectives must be safe spaces. Breaching confidentiality or punishing candor not only stifles improvement, it can unravel months of hard-earned trust and teamwork overnight.
• Leadership’s influence is profound. A manager’s actions can make or break psychological safety.
• Reactiveness kills; curiosity builds. Managers should seek to understand, not react.
• The loss of a single key team member can catalyze crisis, especially if mishandled. Team "rebalance" isn't automatic; it needs careful, supportive guidance.
• Support is leadership’s greatest tool. Belief in the team's good intent forms the foundation for collaboration and continuous improvement.

---

This episode is essential listening for Scrum Masters, Agile Coaches, and anyone interested in team dynamics or leadership in Agile environments. The stories and insights offered by Terry and Vasco are both cautionary and empowering, offering practical guidance and reminders of what truly supports — or destroys — healthy 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 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 our Team Tuesday this week with us, Terry. Hi Emma. Hey Terry. Welcome back.

[C]

Hey Vasco. Thank you. Happy Tuesday everyone.

[B]

Happy Tuesday indeed. And talking about Tuesday, we really want to investigate that story of the team that self destructed. It is Team Tuesday after all. But we before that want to know what's the book that most influenced you in your career as a Scrum Master?

[C]

Terry, I did consider this question deeply and there's so many books I would want to mention, so I'll just stick to a couple. The first one I mentioned, when I started my career as a Scrum Master, the manager gave me a book, I'd have to say that was massively influential because it started my journey as a Scrum Master. It was Agile Software Development with Scrum by Ken Schwaber and Mike Beadle and it kind of tells the story of a Scrum team and then tells the same story for another Scrum team and tells the same story about six times. But by the time you've read it, you've got a good idea what it's about and I would recommend that for any Scrum Master. I think it's a good read, but the one that probably influenced me the most, and it's not about Scrum, but it's the Five Dysfunctions of a Team by Patrick Lencioni. And just the way that he puts it, the way that he allows you to see if there's a lack of trust, you're not going to get anything else if there isn't a lack of trust, but you don't have conflict. And those five Dysfunctions. Again, I strongly recommend that book to anyone. It's a really, really, really good read if you're working with teams.

[B]

Absolutely. And a great book. It is often referred to here in the show. I'll put the link in the show notes. And talking about teams, by the way, the framework that Lencioni refers to in the book is actually a very good first step to start understanding the system of a team, whatever that team is. Right. Like a team of leaders, a team of software product developers, a team of teachers, whatever that team is. And this is really timely because of course, today's Tuesday and we talk teams here on the Tuesday episode and we want to hear first the story of a team and how they, you know, slowly started to develop these patterns, these approaches that led to problems, potentially even self destruction. We'll talk about how to fix those in the conversation, but first walk us through how that began. What were like the initial signs that something was going wrong with that team?

[C]

Yeah, so the team I'm thinking about, I was engaged with them quite a few years ago and again, I think the system is a part of this, but I'm going to focus just really on the what was happening in the team and especially the behaviors. So they were a team that were working very much as individuals. They were working like a feature factory. So effectively just pumping out one requirement after another, happily delivering stuff, and kind of felt like they were doing okay, but there were a lot of problems around the edges. So after things were finished, we'd find out they didn't integrate. After something was done, we'd find out it was the wrong requirement altogether. There was a lot of rework and they then got this weird agile guy to come in and start to see things a bit differently. And there was one particular lady on the team who was the business analyst and she kind of bought into it and she gave quite a strong coaching invitation. So I was very happy to coach her a little more than the others because the invitation was there and she was kind of like the mum for the team. She bought the cakes, she remembered people's birthdays, she'd give them a hug when they were down. And she was actually the glue that held the team together. And as we went on the journey of starting to try to work in more agile ways and think more about outcomes and less about requirements, and the list is long of all the things we have to do differently. She was the one who supported people through the change and made it a lot easier for me as the coach in that space or the scrum master to actually achieve the changes. Unfortunately, she mentioned something at a retrospective that then got back to her manager who then challenged her on what she had said as if it was something negative, even though it was really just a valid observation about something that wasn't right and could be improved. And then ended up putting her on performance management. She left. And then the team that suddenly lost its mum, they lost their social glue, if you like, actually started to self destruct in a really rapid way back.

[B]

To give us a little bit like what, what started happening at the time after this, this business analyst left. So.

[C]

So right back to working as individuals again. Right back to just give me the details and I'll. I'll build it, you know, right back to not really caring and engaging as we're, you know, refining work and planning work, sitting there quietly and not saying anything and then afterwards pointing out that was actually not possible to do or you know, it was, it was very much that lack of teamness. Now I know teamness isn't a word, but I think it should be right.

[B]

The characteristics that define being in a team.

[C]

Yeah, that's right. No, no feeling of belonging to a team. It's just that our work comes out of the same board in jira, if that makes sense. And all the old problems started to reemerge as well. So rework, defects, things not integrating, all because the one person who really cared about them just disappeared. And then there wasn't that care for each other. And if we think about the book, the five Dysfunctions of a Team, we'd actually gone through and built trust. We had that healthy conflict. As Patrick mentions in the book. It doesn't have to be like deep conflict, but it's that idea that I can challenge. An idea they were even up to the point of actually making commitments. We didn't get all the way, but. But we were good halfway through that model and we went right back to an absence of trust again and people just not. Not trusting each other, but not not caring to build trust anymore either. All because of the loss of one is there.

[B]

And like when you think back to that story, is there besides the BA leaving obviously, because that has an impact. Like whenever a team member leaves the team, the team becomes a new team. This is important to understand because, you know, the dynamics need to kind of rebalance again. But beyond that obvious fact that BA left, was there something else that changed after the BA left that might have triggered people to retreat to their individual space, not be so collaborative, starting to mistrust their colleagues again?

[C]

I think it was actually the example of how she had left because it had been something that was mentioned at a retrospective. Even though a retrospective should be a safe place to say whatever you think, it's not about blame. Absolutely not. But, you know, we should be able to say, I think we need to improve how we do this thing. I think this, this aspect of something isn't working. If it's not safe to say that and you're going to be put under performance management, that kind of leads people to think, well, all of this stuff is putting me in a. In a place of danger. I'd rather just put my head down and do what, what the, the managers want us to do, and then I'll be safe. All of this weird action.

[B]

So this lack of safety kind of reemerged immediately after the BA left. And of course, as we know, when there is no safety, then there can be no openness. And if there's no openness, you can't collaborate. Right. Because if you start collaborating, you're immediately being vulnerable because you're helping someone that might not help you back.

[C]

Well, that's right. But also it might get out that you helped someone when really you should have been doing your thing, and then you might then be in danger. Helping someone might be dangerous.

[B]

This is actually a great example of how often leadership can, with a single action, destroy work that takes weeks or months to do. Right. Like to create the aspect of belonging to a team, of trusting each other, of having a sense of shared future, which is a critical aspect of being part of a team. And management can come in and through one action, can destroy that immediately with just one simple action.

[C]

Absolutely. Absolutely, they can. Or they can support it as well. So if you're leading a space and you understand that you're leading a space and you can hold that space open for the people that are doing the work, you can actually create a space where innovation flourishes and creativity is brought to the fore. People will bring their best self to work and they will try harder and have more passion and care about each other.

[B]

So what should have management done at that point when something was brought to their attention that was discussed in a retrospective? If you had been the manager yourself at that time, what would you have done?

[C]

So it's easy to say you should have ignored it because it was said in a retro, but I'm imagining that the manager involved wasn't quite across it the way we might be or the people listening to this podcast. I would always encourage leaders to ask questions rather than make Statements. So I heard this was the case. What can you tell me about it? What was going on for you at the time? How were you feeling? It's hard to say what the right question would be, but certainly listening to understand rather than just responding to something that you've heard is a much stronger way to be a leader. I don't think you can effectively lead if you're just going to respond to what's happening. You have to allow the team to own the space, let them do the responding, but you can help them to explore it.

[B]

Well, actually you open up a very interesting debate. I'm just going to tease it because that's a whole nother episode. Maybe we do a bonus episode at some time about this, which is you talked about being open and being curious as a leader instead of responding. And I think that it's very important for us to make a clear distinction between what leadership is and what responsiveness is. Responsiveness or reactiveness, I think is the more correct word, is about reacting to what comes to you without thinking about the long term consequences, without thinking about how this fits the whole system that we are part of, without expressing curiosity. That's reactiveness. Right. And leaders should not be reactive because of their responsibility and their immense influence on their teams. They should behave with leadership perspective, which is understand that not all information is available. I don't know everything if it's a team topic. The team should solve the problem, maybe with my guidance, but definitely they should be part of figuring out what the problem is and how to solve it, not me. Those are completely different perspectives, this leadership versus reactiveness. And I think it's important for us to keep those two concepts in mind. What do you think, Terry?

[C]

I totally agree and thank you for correcting me. It's a reaction more than a response. A response can be perfectly appropriate if you've taken the time to consider things. And I also agree that it is about holding the space open as a leader so that people can define the solutions for themselves. They know the system better than you do. Even if you were the best developer, tester, analyst, whatever in the entire world when you were doing that work, it's completely different now. You don't actually know what they do. And I've had that trap myself because I used to be a developer, still think I know how to do it, and I write little HTML games and things just to keep my hands in the tools, but that's beside the point. So I do coach leaders on finding a space, create a space, even if it's just a momentary pause to remind yourself everyone here is doing the very best they can with what they have, the information at hand, the systems, the tools, the processes, the practices, et cetera, et cetera. If you start from that assumption, and you might need to manage by exception, there may well be people who are not doing that. But if you start from that assumption, then your responses will be more supportive of the people in the system. I don't.

[B]

Supportive is a key word, I think, for leadership. Be more supportive of the people in the system. Terry, thank you very much for sharing that story with us.

[C]

My pleasure. 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] membership because listening is great, it's important. But doing it together, that's next level. I'll see you in the community Slack. We really hope you liked our show.

[B]

And if you did, why not rate.

[A]

This podcast on Stitcher or itunes, Share.

[B]

This podcast and let other Scrum masters.

[A]

Know about this valuable resource for their work.

[B]

Remember that sharing is caring.