
Loading summary
A
Hello everyone. Quick heads up before we start today's episode. The Global Agile Summit is happening on May 4th. Yes, May 4th. And even with a big blowout Star wars party you have to join. It will be online and it's like always free to attend. We have four tracks this year that I'm really excited about and I think you will too. Stick around to the end of the episode to know what they are. If you want to check it out already now you can check it out at bit ly globalagile 26. That's the numerals 2 and 6 at the end. So one more time, that's bit ly globalagile 2, 6, all one word, all lowercase. And 2 and 6 are the numerals 2 and 6. So stick around till the end of the episode and I'll tell you what's in store. But for now, on to today's episode. Hello, everybody. Welcome to our team Tuesday where we talk about teams that self destruct today with Bhavin Shukla. Hey, Bhavin. Welcome back.
B
Thank you, Basil. Thanks for hosting me.
A
Absolutely. So we'll talk about teams in a second, but on Tuesdays we also want to hear from you. What was the book that most inspired you in your career as a Scrum master?
B
Gosh, that's a tough one, Vasco, because I wish I could show you the whole library behind me. But if there's one book that you would probably ask me to choose, I would choose this lovely book called Make Work Visible by Dominica de Grandis. Why that book? Well, I think that book goes beyond the values and principles and really talks about putting them into practice and in a, you know, very grounded and system focused manner. One clear message I get from that book is it's not the people who are the problem, it's the system that we need to work on to improve ways of working. Some concepts that that's being introduced by Dominica in that book are around, you know, the five thieves of time, visualizing work, dependencies, bottlenecks and so on and so forth. I think it just connects that book, what we talk about, you know, the lean, the Kanban principles, the behavioral issues that we see and makes it very practical. That's something that I like about the book.
A
Very good, very good. So Making Work Visible by Dominica de Grandes. We'll put the link in the show notes for everybody to find it. And now we turn our attention to the team story, Bhavin. So in the team story we're exploring patterns, behaviors that sometimes may start as subtle and small little nagging things that happen here and there, but could potentially grow and become a big problem for the team. So share that story with us, Pavin.
B
Absolutely. Look again, Scrum Master, for probably another team that I was working with in one of the banking organizations here. When I got started with them,
A
what
B
I observed is the team's really humming. Unlike my previous experiences where, you know, I saw some different behaviors that the team actually demonstrated, this thing was humming. They were having conversations and cracking jokes on each other. And then they were this. If you see it on day one, you see like, oh, they are in the zone, they know what they're doing. And then like how a typical Scrum Master would embed himself or herself in the team. You know, you start noticing, observing them working in action, the conversations that you notice, so on and so forth. One thing that got my attention is the team always wanted to help everyone who came to them. They were genuinely curious, genuinely helpful, good people who love helping other people. Just human nature now. I took it as sort of one of my observations and thinking, you know, maybe it's a good thing. I'm just probably overthinking. When it came to digging the data, understanding what's happening in the system, you know, how's the Sprint velocity, burn downs, value being tracked. I could see a bunch of patents now. The commitments often overlapped into the next week and into the next Sprint. The tech debts, they were on the rise. We saw a lot of P1s and P2s coming across from what we put into production. More than this, these were the subtle things that anyone can see. The decisions that the team required to be made at a certain point of time. The decision latency was immense. There was so much delay there and the risks were we never talked about those things. Despite of all these things, you know, the team was humming and having this positive energy. So it was sort of making me feel as a Scrum muscle like it's a slow self destruction mode. They are in good with good intentions, but wasn't helping them and that's something that they were not able to notice. So simple.
A
Do I understand correctly that the overall vibe was positive, but when looking at the data you were detecting some worrying patterns like slow decision making, higher impact bugs or defects coming from production. Potentially some feedback that you were getting from other people. Was that how you would describe it?
B
Yeah, pretty much. Pretty much. And so tell me a little bit,
A
why do you think there was that disconnect between the vibe which was overall positive and the actual trajectory of the team's performance.
B
I think the underlying patterns that we normally observe and talk about when we are an adult practitioner, we see these underlying patterns of either the problem situations or what the team doesn't really day to day observe. Those patterns weren't being very obvious to the team that this is really happening. It was also a culture of it's okay, delays are okay, it's okay, things overflow. So, so there was no sense of urgency. I felt every time sprint goals, not mad. Yeah, that's okay, we'll do it next Sprint. So that sense of urgency, that value delivery, I think that was lacking a bit. So I would say they were getting a bit complacent to overall ways of
A
working and this complacency. Did you ever place a finger on why it was there? Was it that. Maybe I'm just speculating here, but maybe the feedback they were getting was too benevolent, not specific and maybe clear enough.
B
Actually they were not getting any feedback.
A
Okay, now we're starting to look at it, right?
B
No one, no one shared any feedback to them of, of the impact of not meeting the goals. You know, how, forget the sprint goals, but if your goals are not met, what's the impact on the overall product roadmap? What's the impact of that not being. Delivering customer value in time? You know, and if you feel extrapolated or from organization perspective, you are actually risking losing customers if that's happening. So that no one was having this feedback loop to them saying the impact is like a domino effect. It's not that just a team goals are not met. So that was one of the, one of the problems with that scenario.
A
And why do you think that that developed in that particular organization? Why was a team allowed to continue to progress in their work but not be given feedback about potentially the negative consequences of their actions?
B
I think in general, particularly in that group, as far as I worked with that group and what I noticed is feedback isn't something that was actively they've been seeking on. And it wasn't just limited to feedback about generally how teams working, but also how your products performing, how, how you, what's what your customers feedback on, on your products. So generally that feedback loops were missing is how I sort of concluded that maybe, you know, if there's this feedback loop which could be built around multiple touch points, I could experiment around something. And that was probably my experimentation going ahead where you know, I, I literally introduced as a scrum of literally two. Two things or two tools. I just put a anonymous happiness meter. It was, it was those days when we didn't do a lot of murals and murals and things. So I put it on the wall like when you walk out of the to leave guys I just want you to do two things. Praise yourself 1 to 5 how happy you are 5 being very happy and if you're anything below 3 and below a post it note on why or what and anonymous which is data for me. And without you know injecting all those formal tools and everything from an organization perspective which makes it feel like more pressurized and people feeling like gaming the system. This was more like people felt oh it's fun, let's give some data. So that's one. And there was another one which I introduced as gratitude wall. So yes, there could be some negative feedback coming in. People may not be feeling happy in this case it wasn't the case. But my, my gut feels people need that platform to speak out. And there was a gratitude wall. Combined together the team could just not just take pride in what they do thank each other but it gives insights around you know, what was becoming as a pattern that I observed initially the the desire of the team to help everyone. It was becoming a bottleneck and that was what was called out in the happiness meter team was burning out. They had to look at incidents in the weekends. They didn't know whom to reach out to. If it's a P1 issue. There were a couple of instances they shared that Friday evening. We have a P1 we don't know who to reach out. It was like a burnout situation. It was good the data and gradually they went to a path where, you know, I could work with them to teach some negotiation techniques. You don't have to be rude to say no. You can negotiate the yes, you can negotiate the no. So there's always focus on an alignment on what are we delivering, what the value. What's the most valuable thing to do right now. So that was one thing.
A
That's actually a very good point because the saying yes actually means that a lot of other stuff is said no to but it's just not done explicitly. Well, one of the things I really like about this story is how deliberate you were about collecting data. Right. Because problems can happen any point in time. But if we don't have any data we have no way to go and look back, hey, why is this happening? What might be the triggers? What might be the symptoms? So I really like how you focused on that data collection as a way to understand better what was going on. Because another anti pattern that usually happens is that we jump to conclusions and without data, it's very easy to jump into conclusions. When we have data, at least we have the possibility of mirroring our hypothesis against the data and checking is there supporting evidence. Right. So I really like how you described that. Thank you very much for sharing that story with us, Pavin.
B
Thank you, Oscar.
A
Hi there friends. Thanks for sticking around till the end of the episode. So let me tell you what's coming on May 4th. We're running the Global Agile Summit. It will be online and I want you there this year. We have four tracks and each one is built around real conversations with practitioners. No slides, no keynote theater, just honest interviews with people doing the work, just like you. The first track is AI in organizations where practitioners show what actually works. No hype, just AI that makes your Monday better. Happy Monday, everybody. And then we have the people track honest conversations about putting humans at the center of how we work and keeping them there. And third is Agile in Construction. And yes, I really mean brick and mortar construction. Lean and Agile. Actual job sites. Field leaders removing waste. Teams transforming how buildings get built. Stay tuned for what I think will be a super track on Agile in construction. And the fourth track is Agile in Gaming. How game studios Ship without burning out Agile Inside the Creative Pressure Cooker over the years we've had more than 12,000 participants since 2017, the time of the first summit organized with the podcast, and this year we're making it easier than ever to join. You can register for free and get access to the summit sessions live during the event week. That's May 4th to May 6th. Or you can grab the Practitioner Pass and get immediate access to last year's keynotes from Jurgen Apollo, Gojko Adi and Mirete Kangas right now, even before the Summit starts. So grab your Practitioner Pass and start learning today. Head on over to bitly globalagile 26. That's 2, 6. The numerals 2 and 6 sign up and I'll see you on May 4th. And one more time, here we go. Bit ly globalagile 26. All lowercase, all one word and 26. That's the numeral 2 and the numeral 6. I'll see you on the conference floor.
Episode Title: The Hidden Cost of Always Saying Yes — How a Helpful Scrum Team Nearly Self-Destructed
Guest: Bhavin Shukla
Host: Vasco Duarte
Date: March 31, 2026
This episode of the Scrum Master Toolbox Podcast centers on the hidden dangers of a team culture built around always saying "yes." Bhavin Shukla, an experienced Scrum Master, shares a vivid story of a highly positive, collaborative Scrum team whose unchecked helpfulness nearly led to burnout, technical debt, and declining outcomes. Together with host Vasco Duarte, Bhavin explores patterns of anti-feedback, the subtle risks of well-meaning teams, and practical interventions that recalibrate teams around sustainable, value-driven practices.
“One clear message I get from that book is it's not the people who are the problem, it's the system that we need to work on to improve ways of working.”
— Bhavin Shukla [01:30]
Initial Observations:
“They were genuinely curious, genuinely helpful, good people who love helping other people...When it came to digging the data...I could see a bunch of patterns.”
— Bhavin Shukla [03:34]
Worrying Patterns in the Data:
"...it was sort of making me feel as a Scrum Master like it's a slow self destruction mode. They are in good with good intentions, but wasn't helping them and that's something that they were not able to notice."
— Bhavin Shukla [05:32]
Bhavin reflects on how the team’s positive chemistry contributed to complacency:
"There was no sense of urgency. I felt every time sprint goals not met. Yeah, that's okay, we'll do it next Sprint. So that sense of urgency, that value delivery, I think that was lacking a bit."
— Bhavin Shukla [06:50]
Vasco probes deeper:
“Was it that...the feedback they were getting was too benevolent, not specific and maybe clear enough?”
— Vasco Duarte [07:09]
Absent Feedback Loops:
“No one shared any feedback to them of the impact of not meeting the goals...if your goals are not met, what's the impact on the overall product roadmap? ...the impact is like a domino effect.”
— Bhavin Shukla [07:36]
“Generally that feedback loop was missing...if there's this feedback loop which could be built around multiple touch points, I could experiment around something.”
— Bhavin Shukla [08:31]
Simple Tools, Big Impact:
Purpose:
Revealed Patterns:
Coaching Shift:
“You don’t have to be rude to say no. You can negotiate the yes, you can negotiate the no. So there’s always focus on an alignment on what are we delivering, what the value is. What’s the most valuable thing to do right now.”
— Bhavin Shukla [10:55]
“If we don’t have any data, we have no way to go and look back, hey, why is this happening?... When we have data, at least we have the possibility of mirroring our hypothesis against the data and checking is there supporting evidence.”
— Vasco Duarte [11:31]
“They were in good with good intentions, but it wasn’t helping them and that’s something they were not able to notice.”
— Bhavin Shukla [05:32]
“No one shared any feedback to them of the impact of not meeting the goals...the impact is like a domino effect. It’s not that just a team goals are not met.”
— Bhavin Shukla [07:36]
“You can negotiate the yes, you can negotiate the no.”
— Bhavin Shukla [10:55]
“If we don’t have any data, we have no way to go and look back, ‘hey, why is this happening?’ ...It’s very easy to jump into conclusions. When we have data, at least we have the possibility of mirroring our hypothesis against the data and checking is there supporting evidence.”
— Vasco Duarte [11:31]
This episode is a must-listen for Scrum Masters, Agile Coaches, and teams striving to sustain positive cultures without sacrificing outcomes. It’s a reminder to balance helpfulness with focus, feedback, and the confidence to draw boundaries in service of real value delivery.