
Irene Castagnotto: The Risk-Aware Scrum Master: Preventing Problems Before They Happen Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website:...
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.
B
Hello everybody. Welcome to our success Thursday. This week we have with us Irene Castagnotto. Hey Irene. Welcome back.
C
Hello.
B
So success is the topic of our conversation today. But before we dive into success for Scrum Masters to share with us, Irene, what's your favorite Agile retrospective format and why?
C
Well, it's very funny because I create every time a different format using meme. So my team is very young, both of them actually are very young, so we play a lot with that. And because I feel that sometimes the emotional side can be a little bit tough, I always love to put memes inside the retrospective to make them feel fun, to make them feel a little bit funny moment in the beginning and then like, like they relax and then they are ready to get into the emotion. But this is just a statistical part of you speaking about the question that I like to do. It's one of them. The format that I like the most is the good bad Risk. So, so what was good in this print? What was bad in this print? And what risk are you going to face? And this is because a lot of time we cannot see every risk that is coming, but they actually see a lot of them. And maybe we don't realize as a Scrum Master because maybe we don't touch the code. So maybe the risk is from a technical side. And that's why I love this part, because in the end, sometimes the problems are connected to the risks and sometimes when we read the risks, then we can maybe be doing some analysis or meetings or speaking with people or negotiate with the stakeholder to understand how to deal with them. And the work goes so smooth. When you speak about the risk before the sprint starts. That's very good. So this is why this is my favorite format.
B
Yeah. And it's actually a great way to introduce the concept of risks. Right. Because very often risks are not discussed explicitly. Because, I mean, if you think about scrum, for example, of course, we want to tackle the highest risk first, and that's all there. But when you're working every day, right, like, first you have the refinement, and you typically only talk about scope details. Then you have the planning, and there you might be assigning work to people and asking and answering a few questions. Then we have the daily meeting where we talk about what's going on. And unfortunately, many teams don't actually discover or talk about risks in the daily meeting either. And then you have the review, which is too late to talk about risks anyway. Right. So when you think about it, if we structure the retrospective around risks, we also start to create that language that helps the team members to speak about risk all the time. In fact, a trick that I often use is to bring the language of risk to every single meeting. Right. Like, I will ask questions such as, why might that go wrong? What do we absolutely must have before we can complete that work?
C
Yeah.
B
What are the dependencies? Right. All of that is risk language.
C
Language, yeah. Also, because sometimes one person of the team don't see the risk and the other. Yes. So when you bring up the risk, maybe also the other person say, oh, yes, you're right, and start a discussion that actually lead to maybe a solution as well. But if we didn't bring up that kind of conversation, they wouldn't think about it, and they would find themselves in the middle of the sprint, looking at the problem and saying, oh, oh, now what we have to do. So it's very powerful to make them being also okay with the risk coming by. Because when you. Sometimes you don't want to speak about risk because it's a problem, that it's not here yet. So you don't see the reason why to do that.
B
Don't jinx it. Right.
C
Yeah. Yeah. But then when you understand that speaking about the risk before could really help you not having a problem, they are very happy to speak about risks.
B
Absolutely. And in fact, that's one of the things I often talk to with my teams, is that, look, all we do is handle risks. Risks of not knowing what needs to be done, not knowing when it needs to be done, not finishing it on time, not having the right customer in mind, the technical Risks that we often talk about, the quality risks we often, we're always handling risks, but we don't create that language. So it becomes hard to act on because we very often get stuck in this just do it type of language. Right. We need to do X, whatever X is. But as you said, if we are allowing ourselves to talk about risk, we can tackle them. Right. Because it's foresight. Right. It's about understanding what might happen and then being ready for it.
C
Yeah, that's the point, really.
B
So of course today we saw we also talk about success, not just risks. And we want to explore what success means for you in your role as a Scrum Master. So what is it? What do you look at? What drives your understanding of success for yourself in this role?
C
Well, let's start from the risk then. So one of the things that I look at the most is that the team don't face unexpected issues while developing. So during the sprint, that's something that when I started with the team, they deal with weekly. So it was very hard to deal with. It was very hard to finish a sprint with everything that was fine, not doing over hours because of this kind of issues. So we started doing a long process, the starting from speaking from the risk, speaking about the risk in the refinement, in the daily, in the retrospective, but also with the po, we are doing a lot of user story mapping, which is so helpful, but so helpful. And they didn't do it before. So in the beginning they were like, oh, Irene, you are making us doing four hours meeting, we don't want to do that. And now they are like, okay, next time we start a new feature, we want to do a user story mapping again. And I'm like, of course. So that's of course one of the success metric that I use for myself. If the team don't face risk issues or unexpected issues during the spring, that means that we did a good job until now. So we try to address everything that we could address before. Of course it happened that something unexpected came by, but is the normal reality of the life. So we just deal with that. Something really connected actually is also that we don't start working with missing requirements. Sometimes we have missing requirements from a product perspective and this could lead to having a user story that is not complete, that is from a user perspective, kind of strange to use it because we have missing requirements. So this could be very difficult to deal with because you have to take care of the communication of the po, the ux, the stakeholders and the dev as well. Because sometimes the missing requirements, you cannot you understand that we have one when we are in the testing phase, which is too late. So one of the other things I really try to understand is this one. And basically what I find that it's the most helpful is to let UX and Dev speak at the same time. And that's the moment where we find the missing requirement. Then of course, when it's very important, but sometimes we don't take the right care of it. It's the happiness. So if the team is happy, this means that they live in a good environment. So you're doing a good job, because one of the most important things that we have to do is provide a good environment and tweak that kind of environment. So also, when they have therapists, sometimes they also feel free to open up. And that's very important for us, Clan Master, because sometimes we don't have everything. We cannot see everything. So if they don't speak up and then they say, okay, we have this problem also maybe some miscommunication problem that could happen with another team or between the team itself. If the team come to you and say, okay, I'm having this problem in communicating, or I'm having this problem with the infrastructure, you know that they trust you. And this is something really important on a team, not just on a Scrum Master point of view. Apo adept, if the team trusts himself, can go and can understand how to deal with everything that comes by. If not, it's very hard to deal with. So the trust is very important and of course, positive feedback. And one of the things that I, I really like to use as my success metric that when I came in the new company, but actually it happens a lot of times people say to me, well, Scrum mastery is not useful. So when the teams, after a few months, look at me and say, okay, please don't go away because we need you, that's when you understood that you are doing a good job.
B
Yeah, absolutely. And that's definitely a great sign that you're doing a great job. One of the things that you described that I really want to emphasize on. We've talked about it already, but it's this idea that as Scrum Masters, we need to help the team and their management create the right type of environment. So what they need to succeed. Because very often we think of teams as, you know, just do the work, right? Like, no matter the environment, you just do the work and don't complain about it. But once we understand that actually the, the output that the team is able to produce is a consequence of their environment. Right. If there's a bad environment with lots of conflict, unhandled dependencies, unclear requirements, whatever there is, the team will not be able to deliver much. Right. But working on this environment, knowing what to do, why to do it, having the right people on the team with the right skills, all of that is the Scrum Master's responsibility. Of course, it's not only the Scrum Master, it's also management's responsibility. But we need to accept that responsibility and work with management where necessary in order to get that environment there. I very often refer to Deming here on the podcast and one of the things that he says is a bad system will beat down a good person every time. So if we can't create a good environment, it's unlikely that the team will succeed. It's still possible that they don't succeed with a good environment. That's still a possibility. But it starts with the good environment. Right?
C
Yeah. And one book that I would like to suggest speaking about good environment and creating good environment is how to make good Things Happen by Marianne Rojas Estape. I hope I pronunciate it Good. And it's a book that is neuroscience and emotional health. But so it's not connected from a management point of view. But actually I think it's very useful because it speaks about how to create your life in a way that positing things happen and you have to be the positive things in your life. And it's the same time and it's the same thing in a team. If you want a team that is good, positive and is working good, you have to be like that. You have to create as a company, you have to be like that. And it's all about environment. So it's very nice, like how the positive thinking, but also the positive behavior that you can bring up changes everything. And that's something that I say a lot of time to the people I work with. And I think it's a good point that we should stop and think about it. And it's also something that is very common now in the social media to listen to, like the positive environment, the emotional health, something that we also speak about a lot about these topics, but sometimes we have to understand how to apply to ourselves this kind of behavior and approach.
B
Yeah, absolutely. That's a very good point. And thank you for the reference. We'll put the link in the show notes how to make good Things happen. The book link will be there for you to check it out.
C
Thank you.
B
Thank you. For sharing the story, renewal.
C
Thank you. Have a good day.
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 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 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.
B
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: Agile storytelling from the trenches
Host: Vasco Duarte (B)
Guest: Irene Castagnotto (C), Scrum Master, Agile Coach
Date: August 21, 2025
This episode centers on the vital role of risk awareness for Scrum Masters, with guest Irene Castagnotto sharing her practical strategies for preventing problems before they happen. Through the lens of Irene’s experience, the conversation explores how creating a risk-ready culture, fostering psychological safety, and focusing on team environment directly contribute to both team success and Scrum Master effectiveness.
Dynamic Approach:
Irene customizes her retrospectives based on team maturity and mood, frequently incorporating memes to lighten the emotional load and encourage openness.
Good, Bad, Risk Structure:
Benefits:
Host’s Perspective:
Vasco emphasizes that Scrum ceremonies often ignore risk unless explicitly prompted.
Psychological Shifts:
Preventing Unexpected Issues:
Irene measures her impact by how rarely the team faces unplanned issues during the sprint.
Ensuring Complete Requirements:
She highlights the risk of missing requirements and the power of connecting UX and Dev discussions early to “find the missing requirement” before it hits testing.
Team Happiness as a Metric:
A happy, open environment where team members trust and share problems with their Scrum Master is a fundamental success metric.
Validation Through Trust:
Irene recounts “Scrum Masters aren’t useful” skepticism turning into requests for her to stay—a deep sign her work makes a difference.
On using memes in retros:
“I always love to put memes inside the retrospective to make them feel fun...then they are ready to get into the emotion.” — Irene (C), [01:33]
On risk language:
“A trick that I often use is to bring the language of risk to every single meeting...” — Vasco (B), [04:48]
On avoiding risk discussions:
“Sometimes you don’t want to speak about risk because it’s a problem that’s not here yet...but speaking about risk before could really help you not having a problem.” — Irene (C), [05:42]
On true team trust:
“If the team comes to you and says...‘I’m having this problem’...you know that they trust you. And this is something really important.” — Irene (C), [10:25]
On environment shaping results:
“A bad system will beat down a good person every time.” — Vasco (B), [12:44]
| Segment | Timestamp | |-------------------------------------------|------------| | Irene’s favorite retrospective format | [01:33] | | Benefits of “Good, Bad, Risk” retros | [03:32] | | Why risk language matters | [04:48] | | Building psychological safety | [05:42] | | Success metrics for Scrum Masters | [07:04] | | Preventing missing requirements | [09:25] | | Role of team happiness and trust | [10:25] | | On proving Scrum Master value | [11:34] | | Host’s reflection on environment | [12:44] | | Book recommendation: positive environment | [13:16] |
The conversation is practical, candid, and positive, blending actionable tips (“always bring risk language into meetings”) with personal anecdotes (“now they want user story mapping!”) and grounded inspiration for Scrum professionals.