C (4:48)

Yeah.

B (4:48)

What are the dependencies? Right. All of that is risk language.

C (4:52)

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 (5:41)

Don't jinx it. Right.

C (5:42)

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 (5:54)

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 (6:42)

Yeah, that's the point, really.

B (6:45)

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 (7:04)

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 (11:44)

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 (13:16)

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 (14:57)

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 (15:07)

Thank you.

B (15:07)

Thank you. For sharing the story, renewal.

C (15:09)

Thank you. Have a good day.

A (15:14)

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 (17:08)

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.