When Scrum Masters Forget to Listen - A Team Trust Crisis in Agile Implementation | Shawn Dsouza

Summary

Podcast Summary

Podcast: Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Episode: When Scrum Masters Forget to Listen - A Team Trust Crisis in Agile Implementation
Host: Vasco Duarte
Guest: Shawn Dsouza
Date: September 15, 2025

---

Overview

This episode centers on the pitfalls of implementing Agile practices without truly engaging the team. Shawn Dsouza, an experienced Scrum Master from Mangalore, shares candid stories of early-career missteps—particularly, how forgetting to listen to the team led to lost trust and the importance of course-correcting through empathy, small but high-impact changes, and a focus on shared ownership.

---

Key Discussion Points and Insights

Shawn’s Journey to Becoming a Scrum Master

• Background (02:37-06:43):
  • Shawn explains his roots in Mangalore, his passion for social service and aquariums, and his early realization that leadership was not about authority but empowerment.
  • He describes working in an organization with a top-down structure, which made him appreciate the need for collaborative leadership:
    • "We felt like we didn’t really have a voice of our own and that didn’t really sit well with me." (03:09 - Shawn)
  • Shawn’s natural ability to connect and lead led him to step in as an interim Scrum Master during a team crisis, fostering small rituals and fun activities to build team cohesion.
  • Winning an internal hackathon by empowering the team rather than commanding them was Shawn’s “first real taste of servant leadership.”
  • The move into Scrum Mastery was solidified during an Agile transformation initiative—he obtained his certification and resonated with the philosophy of empowering those close to the work.

Failure Story: Implementing Scrum by the Book—But Missing the Team

• Jumping into Frameworks (06:56-09:02):
  • Freshly certified, Shawn joined a young, talented team in firefighting mode. He saw the answer in doing “full Scrum”—all events and ceremonies rolled out by the playbook.
  • The mistake? He pushed the process too fast without pausing to listen or understand the team's actual needs.
    • "I had pushed the process way too fast. I didn’t pause and listen to the team... we’re just doing the motions of Scrum, but nowhere we were ready to realize its value." (07:24 - Shawn)
  • Outcomes: Team energy dropped, disengagement in meetings (cameras off, silences), ineffective retrospectives, and worst of all, lost trust.
  • Reflection was the turning point—Shawn realized the importance of listening and shared ownership.

Rebuilding Trust: Small Changes, Big Impact

• Switch to Shared Ownership (09:02-10:59):
  • Shawn began holding 1:1s and informal conversations to rebuild rapport, shifting away from “process for its own sake.”
  • Major pain points:
    1. Internal Conflicts
       • Rather than formal workshops, simple coffee breaks and casual chats unraveled the root issues—which weren’t personal but systemic.
    2. Chaotic Requirements
       • Requirements had been pouring in from multiple sources (manager, PO, engineering head), overwhelming the team.
       • Change: All requirements to be funneled through the Product Owner (PO), making them the single source of truth.
    3. Scope Creep
       • To combat scope creep, after planning meetings, clear communications were sent to stakeholders outlining what would be tackled, seeking their feedback.
       • Allocated 20-30% of the backlog for buffer/R&D user stories to accommodate unexpected work.
    4. Improved User Stories
       • With a focused role, the PO could spend more time on quality user stories.
  • Outcomes: Team cohesion improved, energy returned, and trust rebuilt.

---

Notable Quotes and Memorable Moments

• On the Consequences of Ignoring the Team:
  • "We’re just doing the motions of Scrum but nowhere were we ready to realize its value." — Shawn (07:31)
• On How Small Changes Shifted Everything:
  • "Sometimes conflicts don’t need any formal workshop. A simple coffee break does wonders." — Shawn (09:18)
  • "We made sure that we funnel all the requirements through the PO. Now we had a single source of truth..." — Shawn (09:44)
• On the Power of Practical Solutions:
  • "It’s important to realize that sometimes it’s not about big changes, it’s about changing the small details that have a big influence." — Vasco (10:59)

---

Important Timestamps

• [01:24] Introduction to Shawn and his agile journey
• [02:37-06:43] Shawn describes his transition from top-down cultures to servant leadership and the value of empowerment
• [06:56-09:02] Early Scrum Master mistake: imposing process without listening
• [09:02-10:59] How Shawn rebuilt trust—practical, people-focused changes
• [10:59] Host’s reflection on the disproportionate impact of small, thoughtful adjustments

---

Takeaways

• Rigid process implementation without genuine understanding can erode team trust.
• Servant leadership is about listening, adapting, and co-creating—Scrum Masters must prioritize their team’s voices.
• Small systemic tweaks, such as clarifying the product owner role or fostering informal connection, can yield dramatic improvements.
• The journey to better Agility is composed of empathy, humility, and constant learning from mistakes.

---

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. Hello everybody. Welcome to one more week of the Scrum Master Toolbox podcast. And this week, joining us from beautiful Mangalore in India is Sean de Souza. Hey Sean, welcome to the show.

[B]

Hey Vasko, thanks for the invite. I'm really thrilled to be here. And if I could put it in words, say, if this was a retro, I'd say that my energy is off the charts today. Well, awesome.

[A]

I'm happy to hear that. So for all of you, Sean is a Mangalore native, which is different from Bangalore. I made that mistake. So apologies, Sean, for that. Mangalore, it's his own city. He's a Mangalore native and software technology post graduate, pardon me, from aimit, and brings more than eight years of IT experience, excelling as a Scrum Master, fostering innovation and teamwork beyond technology. He leads spark, a social service initiative and pursues his passion as an aquarist, nurturing vibrant aquatic ecosystems with dedication. By the way, I love aquariums. I could spend the whole day just looking at aquariums, nothing else would be needed.

[B]

So visit my home someday then.

[A]

Absolutely. It would be a pleasure. So Sean, that was a short intro. Tell us a little bit more about yourself and how did you end up becoming a Scrum Master.

[B]

So before you do anything, I just want to say that I'm really grateful for the opportunity. And as you mentioned, I come from a small but a very beautiful coastal city of Karnataka, India called Mangalore, which is known for its vibrant festival, warm culture and trust me, hands down, some of the best seafood in the world. And I am someone who believes in giving back to the society and that's why I started Spark. I'm also very passionate about traveling and correcting Hot Wheels. So yeah, that's a quick introduction about me. Now coming back to the question how I ended up becoming a Scrum Master, right. So I was working in an organization which was structured in a more top down approach, right where decisions were being made at the managerial level. And then it was coming to us and often conversation with my colleagues, we felt like we didn't really have a voice of our own and that didn't really sit well with me. And I remember thinking, say if at all I get into the leadership role, I would do this differently. And at the same time I realized that I had a very natural inclination towards leadership. I have always been good with people. Even during my college days I was a student leader and I found it very easy to connect, communicate and bring people together. My colleagues noticed it too and often appreciated my ability to listen and guide while with we are not being very forceful. And as I said, I was also leading a social service community and trust me, that taught me a great deal about leading with empathy. And one day my Scrum Master then had to take a few months off. And then things kind of started feeling a bit chaotic in our team. The conversations were slipping, we were not able to meet the deadline and things like that. So that is where I kind of stepped in as an interim a Scrum Master. I started facilitating some of the meetings and my goal was only to bring some rhythm back to our team. It kept the things very casual. I started each stand up with some quick check ins asking how are you doing? And added some humor here and there kind of just to ease the mood and, and every Fridays we kind of used to have these fun activities just to build the bond between the team. Around the same time I remember that our team had participated in an internal company wide hackathon and we worked really well together and believe it or not, we actually won the event. And that small experience that taught me a lot about how we can influence without authority. And it's often like when somebody takes an initiative and bring people together, we can make magic happen. And that was my first real taste of servant leadership. Okay, now coming back to the question, like how I ended up becoming a Scrum Master. What happened was my organization was going through an agile transformation and I saw an opportunity there. I pursued my CSM certification and I would say that the more I explored about Scrum, the more I understood how well aligned it is with my own thought process. It talks about empowering the team and not really controlling them. Right. And the biggest advantage is it puts decision making back into the hands of people who are very close to the work. That really clicked for me, I would say it's been four years now, and I can honestly say that I absolutely love what I do. I have done tons of mistakes, and I'm really grateful that I could learn from them.

[A]

And that's exactly what we're going to talk about next. So, Sean, tell us that story, the difficult moment, the failure story. Of course, we dive into the details later. Tell us that story first.

[B]

Okay, so for that, I actually have two stories to share. The first one goes back to my early days as SCRUM Master, right? Where I just got my certification done. Then I got an opportunity to work with the team. So trust me, this team was young, this team was dynamic, and they were really talented. But often they were firefighting and they were missing the deadlines. And that's why I was bought in. When I joined, I thought that I have the framework, I got the playbook. And then I thought to myself, okay, let's fix this like any new Scrum Master, right? I rolled in Scrum in full. So I made sure that we had all the Scrum ceremonies, the daily stand up, the planning retrospectives, the whole nine yards. But this is where I went wrong. I had pushed the process way too fast. I didn't pause and listen to the team. I just wanted to do Scrum where I didn't understand how to drive the actual value out of it. We're just doing the motions of scrum, but nowhere we were ready to realize its value. What happened was, after a few sprints, the team resisted. I could feel the energy drop during the meetings. The cameras were off, there were long silences. And retrospectives also weren't very effective. And eventually what happened was I think the team kind of lost his trust in me because, you know, that was the reason why I was brought in, right? Because I had to solve the issues the team was facing. But I didn't do that. And that is when I kind of paused and I started to reflect. Right. I then started listening to the team. I had a lot of one on ones, some informal group chat, and then we started rebuilding the whole process together. So this time it was not about the process. No buzzwords, no pressure. It was more about shared ownership. And this is where, what did you.

[A]

Do differently when you helped the team rebuild the process more focused on shared ownership? What were the big differences compared to the first time that you tried it?

[B]

Okay, so we had Two to three major issues. One was that there were a lot of internal conflicts. Our user stories were not up to the mark and we were getting requirements from all the directions. Right? So let's tackle all of this problem one by one. So, about the conflicts. Sometimes conflicts don't need any formal workshop. A simple coffee break does wonders. So we spent time informally chatting with people, understanding what was really bothering them. And what became clear was that most of the tension that was there within the team, it was not personal, it was more about the system or the way we were structured. For example, as I said, we were getting requirements from all the direction the manager was getting involved. There was the product owner, the engineering head. Everybody was giving requirements to the team. So this is one of the first things that we changed. So we made sure that we funnel all the requirements through the po. Now we had a single source of truth so that the team can directly go to the PO and get the requirements that we're not getting distracted from all the direction. And the second thing was we had a lot of scope grade. What we did was after every planning meeting, we made sure that we communicate to the stakeholder exactly what we are going to do and get their opinion about it. And we kept around 20 to 30% of our backlog for the buffer user stories or the R and D stuff that is coming in. Another improvement was since our P.O. kind of became free because of all this new structure that we had introduced. You could focus more on writing quality user stories. These might sound like very small changes, but I would say that these made a very huge difference over the time.

[A]

Very practical. So it's important to realize that sometimes it's not about big changes, it's about changing the small details that have a big influence. Like, for example, the product owner being the single source of truth is an excellent example because it sounds like a small change when you think about it, but actually in practice it becomes a huge change. Right? It improves communication between team and product owners. It establishes trust in the product owner. It helps the product owner step up and talk more to the stakeholders and learn about requirements more directly from them. So I really like how you went through that list of what you called small changes. They weren't really, but they sound like small changes, but that have a huge impact. So thank you for sharing that story with us, Sean. 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 levels, 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. 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.