Why Teams Hate Agile (And How to Change That) | Carmela Then

Summary

Podcast Summary: Why Teams Hate Agile (And How to Change That)

Scrum Master Toolbox Podcast
Host: Vasco Duarte (B)
Guest: Carmela Then (C)
Date: January 8, 2026

---

Episode Overview

This episode explores the root causes of "Agile fatigue"—when teams grow resistant or openly hostile to Agile frameworks. Carmela Then shares her personal experience of joining a team disillusioned by Agile, detailing practical steps she took to restore trust, foster genuine collaboration, and move the team from task-driven burnout to value-driven engagement. The episode is full of actionable insights and real-world strategies for Scrum Masters facing similar resistance.

---

Key Discussion Points

1. Favorite Retrospective Format: The Emotional Seismograph

[01:23 – 04:03]

• Description: Carmela shares her preferred retrospective tool, the "emotional seismograph," which visually tracks the emotional highs and lows of each team member throughout a sprint.

  • "It looks like a graph from the beginning, day one of the sprint to the last day... happy at the top, sad at the bottom. Team members draw on the graph how they feel day by day." —Carmela Then [01:54]
  • Triggers conversations about team well-being without focusing solely on failures.
  • Helps surface emotional pain points or moments of satisfaction, stimulating discussion about underlying causes.

• Benefits:

  • Quick pulse-check on team morale.
  • Offers non-threatening way to address issues leading to stress or unhappiness.
  • Linking mood trends to productivity:
    • "When the team is having a positive experience throughout the workday, they're actually more productive than being stressed and being unhappy. Stress is the silent killer." —Carmela Then [03:23]

2. Investigating Emotional Peaks and Valleys

[04:03 – 05:48]

• Practice: After plotting feelings, Carmela asks team members to write Post-Its at points of significant happiness or sadness.
  • Group Post-Its to identify common themes.
  • Discuss both what led to positive moments (so they can be repeated) and negative ones (so they can be addressed).
  • Supports targeted continuous improvement:
    • "Even if it's that little small happiness… we can get data from here. So that becomes the continuous improvement plan." —Carmela Then [05:28]

---

3. Redefining Scrum Master Success

[06:01 – 07:45]

• Carmela's Evolution: Previously, she focused on quantifiable metrics like cycle time. Her current definition prioritizes team advocacy, morale, and a genuine embrace of Agile principles—not just processes.

  • "Now, I would actually say the advocacy of Agile and Scrum." —Carmela Then [06:16]

• Key Story: Carmela recounts joining a "burned out" Agile team as a trusted business analyst and later, Scrum Master.

  • Previous Scrum Master was micro-managing, rigidly process-driven.
  • Team was drowning in work, plagued by bugs, and saw Agile as a burden.
  • User stories were broken down into granular, disconnected tasks (e.g., one story for dev, a separate story for testing).
  • Lack of ownership and end-to-end visibility—no one knew what was truly delivered or its quality.

---

4. Rebuilding Trust & Team Engagement

[07:45 – 13:10]

• Carmela’s Approach:

  • Came in as a "friendly" figure, open to hearing frustrations.
  • Let the Product Owner vent about hating Agile:
    • "One day the product owner just wanted to talk about how much he hated Agile. I just let him rant. And for some reason after that, things started to take a turn." —Carmela Then [09:35]
  • Focused on breaking stories/features in a way that created traceability, shared understanding, and preserved the big picture.
    • Helped the product owner and team see how stories fit into an end-to-end product vision.
    • Team began to work in meaningful increments instead of disparate tasks.
  • Improved visibility and created end-to-end documentation, fostering collaboration between devs, QA, and the business.
    • "Show the team how we could grab one section and build it as a story, and grab another section—so they could start to build section by section." —Carmela Then [10:34]
  • Gave the Product Owner true prioritization responsibility, building team ownership.

• Host's Perspective:

  • Vasco notes that the team was “faking” Agile—following ceremonies and frameworks but missing the point of collaboration and value delivery.
    • "They were following all these Agile frameworks, but without living Agile." —Vasco Duarte [11:11]
  • Carmela agrees, emphasizing the need for shared understanding of the product, not just managing a list of tasks.

---

Notable Quotes & Memorable Moments

• "Stress is the silent killer... If we could lift the spirit up a little bit, have less of the sad or angry days—the team's actually more productive, healthier, and everything good is going to go with it."
  —Carmela Then [03:23]

• "I actually don't know exactly what I did... but I came in waving the flag of 'I'm new here, I have no idea about your industry, but I'm a great business analyst, I could help you figure things out.'"
  —Carmela Then [08:45]

• "They were just delivering tasks instead of delivering value from an end user perspective."
  —Vasco Duarte [12:55]

• “Now, I would actually say the advocacy of Agile and Scrum.”
  —Carmela Then [06:16]

---

Key Insights and Takeaways

• Team emotional health is key to sustainable productivity.
• Retrospectives that explore emotion (not just facts) are powerful intervention tools.
• The success of a Scrum Master is not found in velocity, but in nurturing true Agile mindsets and advocacy.
• Agile resistance often results from process over people—when the "why" is lost, ceremonies become rote, and burnout is inevitable.
• Patience, empathy, and re-centering on team value delivery (instead of tasks) can turn even the most fatigued teams around.
• Sometimes stepping outside the "expert" role, being a listener, and inviting honest venting creates room for genuine change.

---

Timestamps for Major Segments

• [01:23] – Carmela introduces the emotional seismograph retrospective.
• [04:03] – Methods for discussing emotional peaks and valleys.
• [06:01] – Carmela’s current definition of Scrum Master success.
• [09:35] – Letting the Product Owner vent; start of team buy-in shift.
• [10:34] – Building shared understanding, moving from tasks to value.
• [11:11] – Discussion on “faking” Agile vs. living Agility.

---

Conclusion

This episode is a practical case study for Scrum Masters wrestling with team disengagement or skepticism toward Agile. Carmela Then’s open, human-centric approach shows that meaningful change is possible—if you start by listening, focus on emotions, and steer the team back toward delivering real value together.

---

Recommended for:
Scrum Masters, Agile Coaches, Product Owners, and anyone facing “Agile fatigue” in their teams.

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 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 success Thursday, the big question of the week this week with Carmela then. Hey, Carmela, welcome back.

[C]

Hello Vasco. Glad to be here.

[B]

So Carmela, on Thursdays we talk about success for Scrum Masters, of course. But before we dive into that, share with us what's your favorite agile retrospective format and why?

[C]

This is when I can't pronounce the word properly. My favorite retrospective is emotional seismograph. How you say it?

[B]

Yeah, yeah, yeah, Seismograph, yes.

[A]

And what does that look like?

[C]

To me it looks like a graph from the beginning, day one of the sprint and then to the last day of the sprint and you get your happy at the top and you get your set down the bottom. So get the team member to grab a marker and just draw on the graph how they feel day by day. And so after everybody has put some lines on it, of course it's very beautiful and it also triggers conversation. It is a really good conversation tool without, you know, going into too much of things have failed, nothing worked and those kind of things. So when I put up there, they're happy and we can talk about, oh, everybody's happy. Like why if we see an outlier or not being happy. Okay, who's this person? Do you mind sharing? So, yeah, can actually draw a lot of things out, like emotionally how the team is going through and personally I feel like when the team is having like a positive experience throughout the entire workday, it actually, they're very, actually more productive than being stressed and being unhappy. And because stress is the silent killer, it makes people sick and it takes people out in not only like physically but mentally and people just quit. So I, I just think by being able to, you know, put a finger on the pulse in terms of how everybody's feeling when, during their work, if we could lift the spirit up a little bit, if we have less of the very sad, very annoyed and angry days overall, yeah, the team's actually more productive. They will be there, healthier and everything good is going to go with it.

[B]

So what do you use? So of course the line going up and down is a great conversation starter, but what do you use to investigate the moments of happiness and the moments of stress? Because both of them contain information, right? Like somewhere in the middle there's very little information, but if it's very much at the bottom or very much at the top, there's a lot of information there. How do you investigate those moments with the team?

[C]

So I would get them to write a post it on it. Great. So let's look at this moment of great happiness or great sadness. Get everybody to put a post it and when you have gather information that way, common theme emerges so we can actually group them and get the team to discuss them. And of course, if everything, whenever the thing goes well, that's something we should continuously do it out of the not so very great moment, like the themes. Then the question becomes, so what do we need to change over here so that we could lift your mood from the bottom part of the chart into the positive? The top part of the chart, it doesn't have to be, you know, high, high, even if it is across, you know, that middle line into the positive zone can be that little, little small happiness or it can be great happiness. So get a data from here, there. So that becomes that, you know, the continuous improvement plan.

[B]

Absolutely, that's a great point. All right, now we do run this retrospectives because we want to help teams succeed. And of course that is because that means our success as SCRUM Masters.

[A]

Right?

[B]

Like when teams succeed, we are succeeding. But when you look at yourself and how you're performing and how you're working with teams, how do you define success for yourself as a SCRUM master? Carmela.

[C]

If you asked me a few years ago, I would have given you like cycle time and those kind of metrics. But after having to work in this environment, I would actually say the advocacy of Agile and scrum. And so this team I was working in, so initially I just became, I was the business analyst of the team and eventually because they trusted me that much, they asked me to help Them as a Scrum master as well. So I was holding two roles and that team was very tired of Agile already. They had a Scrum master who was absolutely micromanaging type of project manager style. And they constantly plan and things still goes wrong and everyone was overworked. The delivery was bug and bug and bug. And so they just hated hl. They just absolutely hated. And they, they used to breakdown story. Not just story, they broke it down in it is almost a task like project management type of Agile. You had a story for death, you had a story for testing and they don't connect with each other. And at the end of the day you ask them, so what do you deliver? So this is in production, is it working as design or is it a bug? Like nobody knew. So everybody just had this Agile fatigue. They hated it. So because I felt like maybe because I was a business analyst, I come across as less of a threat, I came across as friendly. So I came in as like, you know, just tell me about your problem, I'm here to help. And so I actually don't know exactly what I did. So I have implemented a few things, a few things with the team. So I had this planning session, I love my planning session of breaking down a feature. And I've told the product owner saying, you are great, you have business knowledge, but at the same time the team needed your business knowledge more than your technical knowledge. And because I didn't have any industry experience, so I just came in waving the flag of I'm new here, I have no idea about your industry, but I have no idea about data. But I'm a great business analyst, I could help you figure things out and put things together and create traceability for you. So because of that I feel like, and I've given the, the product owner time to vent. So one day he just wanted to talk about how much he hated Agile. Yep, yep. So in a retrospective. So I just let him run. I just let him run. Just go ahead and just say it. And for some reason after that things are starting to take a turn. So after I show him how you can break down your stories, how we could document things, how we could share it with the team, with the developers, with the qa. So to create a greater visibility, so to give them an understanding of end to end, how these things actually work together and how we could put something on just a document end to end, like a report document, end to end report, what do we need to do? And show the team how we could grab one section and build it as A story and grab another section and build it so they could build starting to build section by section in. And the product owner has the ability to tell the team which one is more important in his view.

[B]

Basically, they weren't even aware that they were just learning how to do Agile properly.

[C]

Yes, it feels like that they were following all these Agile framework, but without leaving Agile. Like the true meaning of Agile.

[B]

Was it like before you joined, was it that they had just a very, very large list of requirements and they just trolled through it? I mean, you already said that the stories weren't even connected and there was a test story and a development story and nobody could say something was in production. Like, was it that when you joined, you kind of helped them realize some of the core aspects of what work management feels like in an agile organization or Agile team? In this case.

[C]

Not only just work management, it is to have the common understanding of how this feature actually links, how it is being put together, because it is. So what they were building is actually a massive data product. So they were going field by field without looking at how this entire data product, how they should be connecting to each other. That's when they go field by field. And the top part doesn't talk to the bottom part. So in the end they're building something that's completely disjointed. So a data table, these columns, the data in this column. And doesn't, it's not really. Doesn't have a lot of relationship to the data in the end column.

[B]

The other column. Yeah.

[C]

Yes, because they were just looking at one thing at a time.

[B]

Yeah, basically they were. They were looking at themselves as a team, as task deliverers. Right. Like they were just delivering tasks instead of delivering value. From a end user perspective, I assume.

[C]

Yeah, absolutely.

[B]

That's a great story. Thank you for sharing that, Carmela.

[C]

You're very welcome.

[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 Estimate 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.