B (5:08)

I really like the maps analogy because that's what we are trying to do for our teams, right? Like we're trying to map out the options and helping them decide. But sometimes just like Google Maps and I do remember the initial GPS systems we used to have back in the early 2000s or late 90s. It doesn't always work setting the map for the team and we fail. And that's okay because we all learn from it and failure is not the problem, not learning would be the problem, but we want to learn from it here. So Jeanette Share with us that story of failure that of course left you with a very important lesson learned.

C (5:49)

Yeah, I think in my journey, in my career, always, if you are, like I said, if I am a Scrum person, I am also bound to retrospect a lot. So in the retrospectives that I've done, I think I have some very good learnings. So in my initial days of being a Scrum Master, where you have the passion, you have the theory with you, but not the practical experience, experience, you end up, you know, counter. Countering the effect of being the Scrum Master somehow. So initially what I used to do is when I used to join a team as a Scrum Master, I used to go like, ah, no, this is not how you should do it. This is. So I started proposing solutions right away. And then I, I mean, at that moment it felt, isn't it quite obvious that you are not doing it the correct way? And. But sooner I. So very soon I realized that, you know, it's an assumption, you know, what you are looking as a third person, maybe it's an assumption that you feel like, oh, this is obvious, this is right. But you need to understand the pulse of the team, pulse of the process. And only then you can still not suggest direct solutions. You can enable and facilitate, you know, solutions. So I, very quickly, I started creating smaller tiger teams involving the affected people and ensuring that I facilitate the session in a way that they are the owners of their solution. This, this led to a very high acceptance and, you know, really continuous improvements. So one of the first things was do not propose direct solutions. Stop assuming that was a big.

B (7:32)

Facilitate them to propose themselves the solution.

C (7:35)

Right. Exact. Exactly. Exactly. Also, when you're new in your journey, you are exposed to a lot of tools, fancy tools, and then you want to say, ah, this is nice. Let me go back to my team and have a session. I felt that was also a lesson learned, that I shouldn't do that because like I said, agile, sometimes, especially depending on the majority of the teams, it becomes an enabler or sometimes an overhead. So as a Scrum Master, you cannot directly go to your team and say, hey, let's sit for two hours and utilize this tool. If it's not needed, you shouldn't propose that tool to the team. I remember one of the teams, I proposed working agreements, for example, and there was a pushback from the team, like, why do we need working agreements now? We have been working so well since the last two years and stuff. So I realized, you know, okay, maybe I saw something fancy there Was I should analyze myself better before I bring the tool to the team.

B (8:40)

Actually, that's a great point because I mean, intuitively, most people would say, yeah, it's great to have working agreements, but. But what was it like? Because of course, now you have the benefit of hindsight. So when you were thinking about, hey, I should propose that we create working agreements, what was it that you were trying to achieve that later on when you did propose it, you figured out maybe this wasn't the right way to achieve it.

C (9:06)

Yeah, like I said, it was my lack of experience. So I was exposed to this working agreement. I attended one another event of another Scrum team where they were doing the working agreement. I was like, ah, this is nice, let me bring that to the team. But I did not realize that the team did not need this tool at this moment.

B (9:25)

So your perspective was this is a tool that would be useful for my team, but you weren't necessarily trying to give them or help them solve a specific problem.

C (9:36)

Exactly.

B (9:37)

Yeah, that's actually a great insight. Right, like tools, all tools are useful in some context. I mean, this is why the podcast is called the Toolbox, right? Because we have to have many tools in our toolbox, but not all tools are appropriate at that time for those people. Right. Sometimes that time with different people would be a good idea to propose working agreements. Sometimes a different time with the same people would be a good idea to propose working agreements. But at that time with those people, maybe that wasn't the right proposal. So these days when you reflect in your role as a Scrum master, how do you go through that process of thinking? I'm thinking of a solution. Is this the right time and the right people to propose the solution to?

C (10:28)

Well, that's a very good question. What I do with my experience now, I always have a good connect with the team members and the product owner to have those one to ones. And I do a sense check. When I have the sessions with them, I do question them and I make, make notes for myself and then I analyze, okay, what's the overall situation, what's happening? What is the, what are the needs of the team? And based on that, I still do not go big bang. You know, in a session, I directly go and present that tool. I have my closer allies in my teams. When I present them, like, okay, base, I'm seeing the situation and I am proposing this. Do you also see that? And then they say, yeah, yeah, yeah, I agree this is a problem that we are facing and this tool might help. So when I have this dialogue with a couple of them. Then I'm like, okay, you know, my, I'm not assuming my, my analysis is in the right direction. Then I go ahead and propose it to the full team.

B (11:31)

Absolutely. And that's a great way to, I think, balance because we all have, and like you said, we have passion, we want to help, but sometimes by wanting, by doing something to help, we're actually shooting ourselves in the foot and sometimes making other people's lives harder. That was a great story. Thank you for sharing that with us, Junaid.

C (11:54)

Thank you, Osko.

A (11:59)

All right, 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 that AI slob 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 Scrum Master 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 membership because listening is great, it's important. But doing it together, that's next level. I'll see you in the community Slack.

B (13:51)

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.