
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 success Thursday this week with Bhavin Shukla. Hey, Bhavin, welcome back.
B
Thank you, Rasko. Thanks for having me again.
A
Absolutely. We had a great conversation yesterday that kind of deserved a lot more attention. So I hope we can continue that in a later moment. But today we focus on success for Scrum Masters and one of the tools we most use to try to achieve that success. Of course, I'm talking about Agile retrospective. So share with us, Pavin, what's your favorite Agile retrospective format and why?
B
Absolutely. Actually, what I'm about to share isn't really a retro retro format. There's two techniques. I would probably call it. The first ones I use, I think what we often use it when doing roadmaps or creating vision for the product is the newspaper headline. I use it as a retro format. The reason behind doing that is because it's a simple reason. The team owns the story. Putting them in that newspaper headline, they author the story behind what do we want to be printed in the newspaper tomorrow or in a month or the next print. They narrate the story, which means they own pretty much the accountability to make it successful. So it's them doing from start to the end, doing the whole building the narrative to building that data in which they talk about, well, if that was the headline for us to be when we're successful, these are the ABC things that we would have done right? And these are the XYZ things that would have, you know, blown us out of the water. So. And once that happens, it builds the ownership within the team to say, guys, if you are going to be in the headline, let's do things right, what's going to not work, let's take some actions. The whole thinking and the narrative around the mindset of putting people in that frame of you own your success and then you build your own actions to
A
identify which is what we're trying to do with today's episode, by the way. Great stuff. And what is the second technique?
B
Second one was it was really an impromptu one. I've done it probably a couple of times now. I used to work with a Kanban team and then you know how it is vascular when you say oh, you don't do scrum, you do Kanban, which people? It translates to oh, just don't do anything sort of thing. So it was a Kanban team working primarily operations team working primarily to fix, keep this system, keep the lights on, keep the system humming. The pattern that I noticed was the influx of work and the incidents was a lot larger than how much actually we could pick in terms of the solutions or the actual product in production. I did not introduce literally any ceremonies, I didn't speak of any jargons, any agile, any Kanban fancy words because I knew they are under the pump. It's not going to land well if I do something silly like that. All I did was as a retro thing, I just created a whiteboard and I said frustration of the day is one column, success of the day, literally two columns. And I said guys, you don't have to come to a meeting to do this. You don't have to do it religiously at the start of the day, end of the day, all I want, all I, all I invite you to do is the moment you hit, you hit a frustration point or something that make you feel proud. Just put a note here. They started giving me insights. It was a rolling board now it was, if you think about it, it was a retrospective board which was continuously gathering insights and data from the team. And again, there was no cadence. I committed to build, but I used to stop every two, three weeks to say, hey guys, this is what the data is telling us. Anything we need to change. That's where the conversation started landing. There's a particular pattern, for example, that came out saying this particular feature has most number of P1s and P2s coming in the last two months. Okay, great, what do you want to do about it? Is that an automation opportunity? Is that an opportunity for something else? What is it?
A
That's a great way to also reflect on how we can contribute without necessarily pushing any process because it starts from the problem of the team which is one of the ways in which we try to be successful as Scrum Masters, of course. So Bhavin, when you think about that question, what does Scrum Master success mean for you?
B
It's a very hard one, isn't it? Because I, I often speak to now that working in, I still enjoy Scrum mastering. Let's go. I would to be honest, but I speak to my Agile community and we talk about hey, wouldn't be amazing as a successful coaches and Scrum Masters where you know, the teams don't need us anymore and they just self functioning and humming like a machine and then we joke about it but that mean we are jobless. Let's not talk about this, that's not a topic we want to discuss. So answering your question, you know, again, working with the team, fantastic culture, you know, people who believe in quality outcomes, working with each other, sharing knowledge etc, and again me thinking about, you know, what would be my success in this scenario or how would you, what can I do to add value as a Scrum Master, right. And until that point I hadn't really given the thought in terms of what success looks like because keep doing your work for the greater good and you just continue. So I'm sharing this example because this was a pivotal moment in my career when it made me think of this. Setting my team up for success also means I'm set up for success for myself and I do have an analytic for that. So anyway, the situation was great team, like I said, working fantastically with the product owner Scrum Master. But then again this similar pattern arises that we probably see Sprint goals not met and product owners. Scrum Master is always being chased by stakeholders. You know, what's really happening. If the team's so good, why are the goals not met? What's happening really? As a Scrum Master, I get my hands dirty. I get into the, you know, data digging and all that sort of what's happening? Let's look at the system and figure out things around this lack of clarity on work and context, switching, so on and so forth and get the data and present it to the team. Well, they take it with a silence. And that was more of a confronting moment where I could literally sense the team while they were styling, but they were literally like looking at me and telling me we were happy, we are happy as a team. Why would you do this to us? That's sort of, I'm like, guys, look, if I am just here to go coffees with you and laugh with you and go lunch with you, that's not my only job. Right. That's just me. Being humans, we like to connect socially, but then if I'm not showing you the reality and we're not confronting to it, well, I'm not doing my job and I cannot see myself into the mirror tomorrow. So not just a lesson learned, but success for me comes from that particular story saying, you know, success is not always good vibes, good environment for a Scrum Master. For me, it's about confronting the reality, the ugly truth, which takes the team to a more tougher conversations, more constructive challenges, which leads to, hey, how do we change now? If that is a reality, how do we improve and what actions do we take? So it's if I can set team up for a success with those sort of unsettling but truthful data, probably. I think it would be a success for me as Scrum Master.
A
Yeah, absolutely. And it's a balance, right? Like, we always need to bring truth to the conversation, but we need to do it mindfully, meaning in a way that doesn't make people feel like they are being blamed. Because in the end, whatever the team's performance is, is mostly dictated by the system around the team. That includes the team themselves and their relationships, but it also includes the processes, the interaction with stakeholders and all kinds of other things. So bringing data to the conversation sometimes will feel confronting, but we need to pay attention. I love this phrase, which is attributed to Churchill. No matter how beautiful the strategy might be, once in a while we must look at the results, right? And that data is kind of the window to the results in the end. So I really like that approach to what you said.
B
It's happened with this team. When I presented data a couple of times, they actually raised their voice, saying, that's actually not something to do with us, it's something to do with the external vendors. It's something to do with the system, like you said. So data was just giving voice. Data isn't a reflection of the personality or the dynamics of.
A
It's not about blaming. Of course not. It's about discovering what is going on. Thank you for sharing that, Pavin.
B
Thank you.
A
Hi there, friends. Thanks for sticking around till the end of the episode. 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 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.
Podcast: Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Host: Vasco Duarte
Guest: Bhavin Shukla
Episode Title: Why Scrum Master Success Means Confronting the Ugly Truth With Data
Published: April 2, 2026
This episode explores what true success means for Scrum Masters, shifting the focus from maintaining positive vibes to confronting difficult realities with data. Guest Bhavin Shukla shares hands-on retrospective techniques and discusses the sometimes uncomfortable, but essential, role of data in fostering genuine team improvement. The discussion underscores the need for Scrum Masters to address the truth compassionately, using data as a catalyst for meaningful change and ownership.
Newspaper Headline Retrospective ([01:41]–[03:28])
"The team owns the story. Putting them in that newspaper headline, they author the story... it builds the ownership within the team to say, guys, if you are going to be in the headline, let's do things right..." [02:09]
Rolling Retrospective Board ("Frustration of the Day/Success of the Day") ([03:36]–[05:57])
"It was a retrospective board which was continuously gathering insights and data from the team... I used to stop every two, three weeks to say, hey guys, this is what the data is telling us. Anything we need to change?" [04:29]
Challenge: Well-functioning team still not meeting Sprint goals; stakeholders are dissatisfied.
Root Cause: Data analysis unearthed issues like lack of clarity, context-switching, and system bottlenecks.
Team Discomfort: When presented with tough data, Bhavin sensed team discomfort—“We were happy, why bring this up?”
Professional Responsibility: Bhavin asserts the Scrum Master’s role isn't just social facilitation—it's to reveal and face tough truths for the sake of improvement.
Quote:
"If I am just here to go coffees with you and laugh with you and go lunch with you, that's not my only job... if I'm not showing you the reality and we're not confronting to it, well, I'm not doing my job and I cannot see myself into the mirror tomorrow." — Bhavin Shukla [08:03]
Defining Success:
"Success is not always good vibes, good environment for a Scrum Master. For me, it's about confronting the reality, the ugly truth, which takes the team to more tougher conversations, more constructive challenges..." [09:06]
On Data-Driven Change: Data often points to system and process issues, not personal failings.
Balancing Act: Scrum Masters must surface truths compassionately and avoid blame.
Host Commentary:
"Whatever the team's performance is, is mostly dictated by the system around the team... bringing data to the conversation sometimes will feel confronting, but we need to pay attention." — Vasco Duarte [10:37]
Memorable Quote:
“No matter how beautiful the strategy might be, once in a while we must look at the results.” [Attributed to Churchill] [10:56]
Bhavin’s Reflection:
"When I presented data a couple of times, they actually raised their voice, saying, that's actually not something to do with us, it's something to do with the external vendors... Data was just giving voice. Data isn't a reflection of the personality or the dynamics." [11:00]
This episode is a must-listen for Scrum Masters and Agile practitioners aiming to move beyond “feel-good” facilitation and into powerful, data-driven team development and self-accountability.