
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 we have with us Prableen Kaur. Hey, Prablin, welcome back.
B
Hey. Thank you for having me.
A
Absolutely. So, Team Tuesday it is today. But before we dive into the team story, share with us. Prablin, what was the book that most inspired you in your career as a scrum master?
B
I actually have two books to mention, so. The first is Scrum by Jeff. And it's a very obvious book coming from a scrum master. But the reason I say that it influences me really well is because it talks about the perspective of having a framework. It's not about following rules, being mundane about it, it's just a structure which is helping you to do better. So when I actually read the book and I understood the nuances of rugby and how the team should be and what the goals look like, and then everything started making sense. So I also grew beyond that Scrum guide and following rules and doing ceremonies and being the facilitator, understanding that it's about how the team is going to operate around you and it's a collective. It's not that I'm going to just facilitate the ceremonies, bring the retrospective, be there in the standup. No, it's about making sure that the team around you also understands that we are solving the same thing, we are operating for the same goal. And that is the book I really enjoyed reading. The Another one is Turn the Ship around by David. If I have to sum that book up, it just says that leaders lead leaders. So when you are at a position where you're coaching somebody that, okay, things should Go this way or that way. You have to make sure that you bring them to a position where they feel leaders in themselves and that's how they collaborate with you. Because otherwise it'll be just a group of people following the rules or the instructions coming and we will never grow together as a team. So these are the two books I really recommend everybody to read.
A
Absolutely. So the books by David Marquez, we have an episode or actually two episodes with David Marquez. So make sure to check out the link in the show notes to listen to those interviews about two different books that he wrote. And what was the first book? Can you repeat the name of the book?
B
It's called Scrum. The name of the book is Scrum and the writer is Jeff. He is the co writer of Scrum. Oh, okay.
A
Yeah, yeah. Scrum by Jeff Sutherland. Absolutely. We'll put the link to that in the show notes. Make sure that everybody can easily find it. Now, books are awesome because they teach us a lot and we learn a lot when we read these kind of books. But we also need to face the reality. Right. It's not always has the books depicted. Sometimes teams can create their own problems and can self destruct, implode even. So tell us one of those stories. We want to hear the context of the team and a little bit of how the patterns of behavior developed over time for that team that eventually led to the problems that you observed.
B
Absolutely. So I was shadowing a team and the first red flag for me was that the standup sounded like a register activity about. I did that. That's my piece of work. And that was actually happening because we had three teams in the same RTE and we wanted to understand that we have the same practices across. So I happened to join these ceremonies and the first ceremony I joined was the standup itself. So I was just listen, observing what's happening around me. Gradually I realized that nobody was working for the sprint goal because when the conversation was happening, nobody pointed out that, okay, this much is done. This is reflecting as per what we had to deliver. Nothing like it. It was just about stories, what the status is and that is it. And it was not even at a place where people were talking about the challenges they are facing or the help they need. It was just about, this is what I'm doing and this is the status of that piece of work. So I just started to understand that why is it happening? And I shared my observation with the Scrum master of that team and then he shared with me that there was a conflict on the pr. So the team didn't make much noise about it and that's why he didn't register it as a point to be discussed. It was just that the PR was subjected to be pushed, but that didn't happen. And of course it caused a lot of issues. But then because everybody was into the position of solving it, nobody brought it up as a conversation. Even he didn't bring it up as a conversation in retrospective.
A
So what was the problem exactly? Can you explain what was that source of conflict in the team?
B
The source of conflict was the PR which was to be pushed for one of the increments which were to be delivered, but that didn't happen on time.
A
So it was a release, a feature that needed to be added to an increment release, but it didn't make it on time. Is that so?
B
That's the correct understanding. It was near about our Sprint review and we had a critical delivery to do, but because the PR wasn't pushed at any point, it couldn't be merged later and nothing was delivered. So basically we missed the entire deadline. And that was the understanding which was shared to me by the Scrum master. And I, I quite understood that. That is the reason nobody is talking about the Sprint goals or nobody's talking about how we are going to finish whatever we have in hand. It was about what I have in hand. There was no we. It was just I in the conversation. And it made me realize that it costed them the transparency. The team members were working in silos and that was the point where I understood that teams self destruct despite best efforts when they lack trust. Not having trust is the point where the whole disruption starts. So that was one of the experiences I've had.
A
So in this case I understand that what you mean by lack of trust is that there wasn't trust enough to discuss the failures. So the failures were kind of ignored or swept under the rug and nobody tackled them. And that led the team members to kind of focus on their own work. So they didn't have a collective ownership of what they needed to deliver. They just focused on this is my task, I'm going to do it. And if I do my work, then it's not my problem anymore. Is that how you would phrase it?
B
That's true. And another aspect to this whole thing is that at point where somebody has done something wrongly or somebody has done something at a point where it has costed the entire team a deadline, generally what happens is that because everybody gets into fixing it. And of course you have people who understand the system better or, you know, who can contribute more. They kind of take things in and they choose not to speak because the only answer they have is to get the work done. But the point is that it just piles up. And the thing with the disruption in the team is that it's never one action. It's not that one conflict happened and the team is going to go all the directions. It's just that when the opinions are not voiced out, when the discomfort is not shared, it just collects and collects and collects. And when it comes out, it is generally the worst point where the conversation should not have happened and it is very visible with the stakeholders. Also, it's not just about finding the deadlines on time or delivering when we were expected to deliver. The quality is also subjected when we are not working from the space of trust, when we are not working from the space where we realize that it's okay if we are making the mistake. But the. Another aspect to this is that if a mistake is made, of course we have to fix it, and then that should not happen twice. So that's the whole crux of lack of trust.
A
Yeah, absolutely. Because once the, as you called it, the lack of trust is there, then there's no space for improving anything. Because improving starts from the perspective of acknowledging that something isn't working as well as we need it to work. And if there's no openness to discuss it, of course there's then no ability, no content, no input to improving it. Right. When you think about these teams, what are some of the tips, the ideas that you have about kind of slowly bringing the trust back into the team? What are your experiences there?
B
I have actually made it very slow for myself for such cases that I don't sit down with having like immediate conversations and improvements because changing behavior and especially being at a point where people feel very frustrated of each other, that takes considerable time. And it's all about developing the relationships within the team. So one quick thing anybody can do at this point is that they can start having peer reviews, not out of a mandate, but out of the space where we want to help the other person. So when you sit down, start looking at what the team members are doing, it generally brings up conversations and that space where I know I could be wrong or properly I'll get the suggestion, helps the person to imbibe that trust, that feel of a team. So other than that, I. I believe that as a Scrum master, when we find a team like such, where people are just not interacting with each other, the more vocal you will Be in front of the entire team and it could be the smallest of the things or the biggest of the conflict. You can choose the ceremony, of course, the retrospective is the right one. And if that is something which is to be immediately addressed, you can probably talk about in the stand up as well. But you as a Scrum Master have to make sure that you're there vocal for them and you're putting up the conversations, the challenges, the problems in the space where everybody's available so that they also know that they can speak up. Now, if the team is like really shelled, the worst case scenario, taking the anonymous feedback always helps. And even if that's not working out, because you don't know who the person is who has written a certain feedback for you, because if they suggest you something in the feedback, you don't know where to have the conversation with because you don't know who has written it to the start. So you can have scheduled one on ones with the team. And I think having quarterly one on one with the team is the practice every Scrum Master should develop. Because you don't always want to touch upon the work you're doing, right. You get all the insights in the ceremonies. But then if you build a certain relationship and it's all organic because if you're, you're kind of doing it out of mandate of your job, the other person will realize it and is not going to respond the same. So if the situations are like super worst, if that's the point, we are then having one on ones they really help. Having anonymous feedbacks, they really help. And then of course there are multiple surveys which you can take up with the team, talking about how they feel within the team. So there could be short surveys like how am I feeling in the team? Am I feeling supported? Do I need the kind of learnings or basically whatever I have in the team, is it helping me? Any kind of feedback is good feedback when nobody is speaking. So we can decide our space. And it could be from any tool you can use, forms you can use Miro. It's just that you have to make them speak, if not in front of everybody, then maybe with you, and if not with you, then anonymously. But it's, it's about having that conversation wherein people realize that I'll be heard, I'll be understood, but I'll not be judged for it. So once that is established, the trust comes back.
A
Absolutely. And as you said, it is a process that takes its time and we should be patient about it. Thank you very much for sharing that with us. Pravlin.
B
Thanks a lot.
A
Alright, 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 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.
B
Slack.
A
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.
Title: When Lack of Trust Turns Teams Into Isolated Individuals
Host: Vasco Duarte
Guest: Prabhleen Kaur
Podcast: Scrum Master Toolbox Podcast
Air Date: February 10, 2026
This Team Tuesday episode features Agile Coach and Scrum Master Prabhleen Kaur discussing a critical challenge in Scrum teams: how a lack of trust can erode collaboration, turning effective teams into isolated individuals. Prabhleen shares a real-world example, unpacks underlying causes, and offers actionable strategies for Scrum Masters to rebuild trust and re-establish team cohesion.
[01:23–03:14]
Prabhleen highlights two cornerstone books that shaped her Agile journey:
“If you bring them to a position where they feel leaders in themselves, that's how they collaborate with you. Otherwise it'll be just a group of people following the rules... and we will never grow together as a team.” — Prabhleen [02:47]
[04:28–06:03]
Prabhleen recounts shadowing a Scrum Team where the standups felt like status updates rather than genuine collaboration.
Key Issue: No one mentioned the Sprint Goal or asked for help; team members only described their individual task status.
She observed that the collective "we" was missing, replaced by isolated "I" updates.
“It was not even at a place where people were talking about the challenges they are facing or the help they need. It was just about, this is what I’m doing and this is the status of that piece of work.” — Prabhleen [04:54]
[06:03–07:30]
Trigger Event: A failed PR (Pull Request) blocked a critical delivery. The team missed the deadline but avoided discussing the incident.
Result: No open conversation in retrospectives; members addressed only their piece of the puzzle.
The team fell into siloed work modes, leading to a breakdown in transparency and mutual support.
“The team members were working in silos and that was the point where I understood that teams self-destruct despite best efforts when they lack trust.” — Prabhleen [06:54]
[07:30–09:27]
Conflict avoidance: Failures were ignored rather than explored; there was no collective accountability or reflection.
Deteriorating quality and delivery: Without open dialogue, both delivery timelines and product quality suffered.
Accumulation of unresolved issues: Problems “collect and collect and collect... when it comes out, it is generally the worst point” ([08:34]).
“It’s never one action. When opinions are not voiced out, when the discomfort is not shared, it just collects... and when it comes out, it is generally the worst point...” — Prabhleen [08:24]
[10:04–13:22]
Go Slow and Focus on Relationships: Change and trust-building require patience; avoid forcing immediate fixes.
Peer Reviews for Collaboration: Initiate peer reviews not as mandates, but as opportunities to help, making knowledge-sharing and feedback natural.
Vocal Scrum Mastering: Be openly communicative in ceremonies about both big and small issues—modeling openness encourages team participation.
Anonymous Feedback & Surveys: Use these tools for teams too closed-off to speak up in group settings. Capture honest sentiment and start conversations.
1-on-1 Meetings: Build trust through regular, organic check-ins that go beyond work topics. Quarterly 1-on-1s recommended for continuous relationship building.
Create a Safe Space: The ultimate goal is for team members to feel “I’ll be heard, I’ll be understood, but I’ll not be judged for it.” ([12:40])
“Any kind of feedback is good feedback when nobody is speaking. We can decide our space... It’s about having that conversation wherein people realize that I’ll be heard, but I’ll not be judged for it. Once that is established, the trust comes back.” — Prabhleen [12:40]
[13:22–13:33]
Trust-building is a gradual process; quick fixes are rarely effective.
“It is a process that takes its time and we should be patient about it.” — Vasco [13:22]
In this episode, Prabhleen Kaur and Vasco Duarte delve deeply into how the absence of trust can fracture Scrum teams. Prabhleen’s case study vividly demonstrates how clandestine conflict and a lack of collective ownership convert teamwork into individual task management—undermining delivery, quality, and improvement. She provides a robust toolkit for Scrum Masters—including fostering open communication, peer reviews, anonymous feedback, and genuine 1-on-1 engagement—to gently restore trust and team resilience over time. The message is clear: building trust is foundational, requires patience and intention, and without it, genuine agility is impossible.
This is a must-listen (and reread) for anyone committed to nurturing healthy, high-performing Agile teams.