
Loading summary
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. Hello everybody. Welcome to our team Tuesday this week with Carmela Den. Hey Carmela, welcome back.
B
Hello Vasco. Thank you for welcoming me back into your show.
A
Absolutely. It's a pleasure to have you. And today we're going to talk about teams. But before we dive into that, do share with us what, what's the book that most inspired you in your career as a Scrum Master?
B
That's a great question. This book that inspired me a lot. It is actually not a typical Scrum Master book, it is actually a classic. So it is from Dale Carnegie. It's called how to Win Friends and Influence People. Have you read that book before?
A
Yeah, absolutely. I think every Scrum Master should read that book. It's brilliant book and written so long ago and still so true.
B
Absolutely. And I'm glad that we, the both of us have the same idea. And I actually stumbled across this book because, not because of any agile coaches, but it's actually from, you know, someone that I knew outside work. They're very successful in what they do and so when I first got to know them, they say, well, this book, you have to read it not only just once, you have to reread it every year. So this is such an old book when I picked it out and the letters were so small, but when I dive into it, I could see how it helps everybody. And like what you said, every Scrum Master should read it because we work with people, customer is people and our team, they are human being as well. And in a way, whether we want it or not, we are leaders, we are coach and sometimes we could even Be mentors or team members. So before we can do those role efficiently, we need to know how to be able to communicate with you, you know, help fellow human beings. That's how I put it. So, so that we, the message that we want to send actually come across like it sounds like what we trying to say rather than say something and that person have like completely different take, like completely misunderstood our meaning. So yeah, little book, it has been written so long ago, like what you say, but it just so full of wisdom.
A
Yeah, absolutely. And I do recommend the book for very much the same reasons, but also because it has such a different perspective. This was a book written in the 20s, Great Depression and it was a book where that reflects the importance of people and relationships in our own personal success. And I really love that book because of the fact that it's not about technology, it's not about processes. This was before software even existed. And it's still so true because at the essence we work with people and that's something that we all need to acknowledge. People are the key component of success in any software endeavor. So really recommend that book myself as well. Great recommendation. But despite our best efforts, sometimes teams, and sometimes even because of our best efforts, teams kind of end up self destructing gladly. Not too many, but some do. And that's the story that we want to explore today. Carmelo so share with us a story of a team. Walk us through what was happening at that time and what were those little behaviors that maybe started to emerge early on but eventually led to the demise of the team.
B
Oh, I would give you a little bit of a teaser. Communication was part of a very big part of it. So as a little bit of a background, and I wouldn't say when I work in this team so that I don't give it away too much. But you know, after Covid, most of the team members, they work remotely, remotely now. So there's very little face to face time in the office. And a lot of times pretty much all of the team that I worked on, everybody are working across different continents. So we have people in Sydney, New Zealand, like different time zone. In Australia we have people coming from like India, like Nila. As you could see different continent. And not only that and also different background, like different cultural background. So we have different way of communicating the communication style. It's absolutely different. And so this team that I was in, so it started with a few key people, they were in the meeting, these few key people would talk and say if that is a team of, with 20 people on the call, imagine two person talking the entire hour or the entire two hours. And a lot of time they don't use any visual aids, so no. No PowerPoint, no drawings. And I don't know about you, for me, two minutes into it, my mind starting to wander and I started to do my own thing.
A
People were just, literally just talking then.
B
Yes. And more people just talking. And so as you could imagine, sometimes when these people just talking and the rest of people not paying 100% attention. So towards the end, this person thought, this person's doing that thing and this person's doing that thing. And then the person who was talking thought that he has presented the idea and everybody knew it very well and.
A
Did not verify it. Just assumed.
B
Just assume. So, yeah, just assume. Pass it off. I pass things over the fence and everybody should understand what I'm saying and that kind of thing. Yeah. So as the, as the result of it, and yeah, everybody's doing something and as the result of it, that project ran really late. So like couple months before the Go Live, the dedicated Go Live that they were still talking about proof of concept and that is, that's very like, that's a smell like that's not very positive. When like two months before Go Live, still talking about proof of concept. That means nothing is ready, nothing was confirmed. And eventually that Thing team become. So the trust has eroded. So product owner, they don't trust this team anymore. They're starting to implement things to get on top of this thing or what they deliver. And towards the end it has become like micromanaged. Imagine an agile project turn into a very waterfall like developer. Tell me how many days that you require to develop this piece of work and we are going to track you towards the hours that you use in this project. Yeah. And that's the end of, that's how.
A
One of the things that is really incredible for me. Okay, so even when just talking, even if you're in the same room, it becomes quite difficult to follow because let's say when we are talking like you and I are talking, we're introducing concepts and the concepts are in our minds. Right. Like, and we're making connections between those concepts. But the people listening, they are not getting all of the concepts. Let's say they get 50% of the concepts, that means they get probably like 10% of the whole meaning. Right. And when you can't point at something, we are missing the ability to visually anchor the concept. Right. And what is really difficult for me and I sometimes do it, I'm guilty Of that, what is really difficult for me is to understand how somebody that is conveying an idea, whatever that idea is, a set of requirements, a business call, a customer need, whatever that idea is, that they have nothing to back it up, like an image or a story or something. Because like nobody will ever remember that. Right. Like we rarely remember a conversation we have that lasts five minutes, let alone half an hour or even 60 minutes.
B
Absolutely. So this person, that turnout, you have to keep on repeating the same thing over and over again and majority of people just couldn't grasp or they tune it out.
A
Especially in a remote team, right?
B
Yeah. And different cultural background as well. And even I find it harder to very challenged to grasp the idea of when people cannot give me like two boxes, how they are linked together.
A
And yeah, and in this team's situation, one of the key kind of problems you list is that they were very late with their project. But that was probably not the only thing that was happening. Right. Like there was probably missing information, lots of bugs because of misunderstandings and things like that. Right.
B
Heaps of bugs, heaps of tech debt building things that are actually not high in business priority as in the return of investment is low. And a lot of time when I actually have time to watch them a little bit closely, I notice how they go, oh, butterfly, let's chase that butterfly. Even though it's not a feature that's important and forgotten about, there actually a list of important things that are waiting for them.
A
Yeah. Especially in remote meetings. That happens a lot. I know of teams that I've worked with in the past that had especially a strong technical leader who was able to follow a lot of things at the same time. They were able to kind of grasp many concepts and follow many threads at the same time, but the team wasn't. And they would just jump from idea to idea, from feature to feature. And at the end everybody came to me and said, we're completely confused. We have no idea what decisions were made, we don't know what the priorities are. But for the leader, the tech leader in this case, everything was absolutely crystal clear. When I talked with him in the background, they would know exactly what they said, in what order and what was the most important. Right. Like, but everybody else was confused, like totally, completely without knowing what to do next. And eventually, together with that tech lead, we kind of created this one list which was the 1 list of all of the critical features in priority order that the team would be working on so that we could grasp, we could point at something. Right. Like because that's it. Even though it sounds so simple, when you can't point at something, you can't actually talk about it.
B
That's right. That's right. So this technique had to go through a lot of hand holding in a way to say, this is how we draw a story. This is how you go process from beginning to the end. You have to tell that kind of a story and then go section by section. So this section, this is what we do. This section, this is what we expecting to happen. This section is what we're expecting to happen rather than go on and on and on and. Yeah, so he already lost me at a. Yeah, exactly.
A
And this is why it's so important to have great Scrum Masters and Agile coaches with the teams, because they can pick up on this very quickly, even though the people in the room, they might be feeling the confusion but not able to pinpoint what is wrong because they don't have that structure in their mind. Right. Like probably they've been used to work in a chaotic environment for many years and can't see how the chaos is affecting them.
B
Yeah, absolutely. You pointed out a key thing there, a really strong leadership from a Scrum Master. And the thing is, the Scrum Master was being tasked into a delivery manager role. So she's actually too busy to lead the team. She's being tasked to do something else that's actually not part of her skill set, not something that she was hired to do. And just because I wasn't deeply doing anything with this team, I was doing something else on the side and I could see it happening, but I didn't have the capacity to go like, let me help you. Yeah.
A
Well, thank you for sharing that story. Really insightful, fantastic.
B
I'm glad.
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 session 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 details@scrummastertoolbox.org 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. 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.
Podcast: Scrum Master Toolbox Podcast
Host: Vasco Duarte
Guest: Carmela Then
Date: January 6, 2026
In this “Team Tuesday” episode, Vasco Duarte welcomes Carmela Then to explore a real-world breakdown in remote Agile teams. The focus lies on how ineffective communication, compounded by remote work and cultural differences, can silently erode team trust, derail projects, and kill agility. Through candid storytelling, Carmela shares a cautionary tale of a team whose remote collaboration failed, offering insights and preventative strategies for Scrum Masters and Agile coaches everywhere.
Main Book Recommendation:
Why This Book?
Host’s Reflection:
Background & Context (05:14–07:18):
Breakdown of Communication:
Long meetings with only a few voices; most participants disengaged quickly.
No visual representation—just talk. The rest tune out, multitask, or misunderstand.
The “presenters” assume the message was received and understood by all.
Quote (Carmela Then, 07:22):
“So as you could imagine, sometimes when these people just talking and the rest of people not paying 100% attention... the person who was talking thought that he has presented the idea and everybody knew it very well...”
Quote (Vasco Duarte, 07:58):
“[They] did not verify it. Just assumed.”
Consequences:
Critical information lost; team members start working at cross-purposes.
Project significantly delayed; two months before go-live, still at ‘proof of concept’ stage.
Quote (Carmela Then, 08:01):
“As the result of it... that project ran really late... a couple months before the Go Live, they were still talking about proof of concept...”
Trust between Product Owner and team eroded—shift to micromanagement.
Symptoms of the Breakdown (11:53–12:29):
Cultural Variance:
Remote vs. In-Person Hybrid Failure:
Absence of whiteboards, diagrams, or written “anchors.”
Concepts not tied to visible artifacts means much lower retention and shared understanding.
Quote (Vasco Duarte, 10:56):
“When you can’t point at something, we are missing the ability to visually anchor the concept... nobody will ever remember that.”
Team Member Experience:
Many are lost or disengaged.
Those leading have a “crystal clear” picture in their mind not shared by the group.
Quote (Vasco Duarte, 12:29):
“For the leader... everything was absolutely crystal clear [but] everybody else was confused, like totally, completely without knowing what to do next.”
Attempted Remedies:
Scrum Master Role Dilution:
The Scrum Master was pulled into a delivery manager role, blunting their effectiveness.
Quote (Carmela Then, 14:43):
“The Scrum Master was being tasked into a delivery manager role. So she's actually too busy to lead the team.”
No one available to sense or address the “silent” collapse until too late.
Book Recommendation (02:05, Carmela Then):
“Before we can do those roles efficiently, we need to know how to be able to communicate... so that the message we want to send actually comes across.”
People Over Process (03:51, Vasco Duarte):
“People are the key component of success in any software endeavor.”
Communication Failures (07:22, Carmela Then):
“These people just talking and the rest... not paying 100% attention.”
Visual Anchoring Loss (10:56, Vasco Duarte):
“When you can’t point at something, we are missing the ability to visually anchor the concept... nobody will ever remember that.”
Team-wide Confusion (12:29, Vasco Duarte):
“[For the tech lead] everything was absolutely crystal clear. When I talked with him in the background... but everybody else was confused, like totally, completely without knowing what to do next.”
Scrum Master Out of Position (14:43, Carmela Then):
“The Scrum Master was being tasked into a delivery manager role. So she's actually too busy to lead the team.”
01:19–03:51
Book inspiration and foundational leadership thinking for Scrum Masters.
05:14–09:41
Breakdown of remote team collaboration—communication red flags and initial symptoms.
10:56–12:29
Visual/communication deficits, leadership mindsets, and impact on team understanding.
14:18–15:34
The critical importance and misdirection of the Scrum Master role.
This episode is a must-listen for Scrum Masters working in remote and/or culturally diverse environments, offering concrete symptoms and solutions for the “silent killer” of Agile: the collapse of active listening and shared understanding in teams.