← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
When Your Technical Expertise Becomes Your Biggest Scrum Master Weakness | Natalia Curusi
00:14:37
Loading summary
Transcript17 lines
- [00:04]
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. Hello everybody. Welcome to one more week of the Scrum Master Toolbox podcast. And this week we continue our journey through the Australia New Zealand region. We have with us Natalia Kurusi. Hey Natalia, welcome to the show.
- [01:27]
B
Hello Vasco, how are you today?
- [01:30]
A
Very good, thank you for asking. By the way, whereabouts in Australia are you today?
- [01:35]
B
I'm in Brisbane. So this is a kind of medium to small city. It was small, but now we are preparing for the Olympics so we become bigger. And this is very hot here, but it's about 35 degrees.
- [01:47]
A
Yeah, because it's summer there. Right. Like you're in the south hemisphere, we're in the north hemisphere here where I am, I'm in Helsinki and it's getting cold and chilly and damp for now, but soon it will be snowing. But you have the opposite. You have beach days during Christmas.
- [02:05]
B
Yes, yes, Actually we are doing barbecue near the beach. So it's, it's all different. Yeah. Unfortunately I will not spend my Christmas here in Australia. I will travel back home. But yes, here people like to do barbecue on the beach during the Christmas. It's very unusual.
- [02:22]
A
Yeah, absolutely. So Natalia has over 20 years in software delivery and is an expert in agile transformations, delivery optimization and systems thinking. As an agile coach at Endava, she leads Asia Pacific initiatives driving business agility and continuous improvement while mentoring teams to build customer centric, high performing and collaborative culture. So Natalia, that was a short intro. Tell us a little bit more about yourself and how did you end up becoming a Scrum Master?
- [02:53]
B
Yeah, so that's, that's an interesting story. Actually I, I never Wanted to become a Scrum Master. I never wanted to become. To. To go into it. I wanted to become an economist. Yeah, but that things happens. So it happened that my parents didn't have possibility to sponsor me, economy specialty. And that's why I ended up by doing it. And then in it I wanted to do programming. So actually I have about 12 more than 12 years programming experience in. NET. My dream was after that to become a software architect. I wanted to become the first human software architect in Republic of Moldova, because I'm coming from Republic of Moldova. But the thing changed. My son appeared. Then the priorities changed. Then actually I understood that I have it enough. So I did a lot of software delivery already. I know everything about software delivery, about programming, and I decided to do something else. And when I addressed myself a question, what I want to do, I understood that the biggest thing that motivates me this is the impact of the help, the support that I can bring to people, to teams and to organizations. So that's why I thought that I can do I become a Scrum Master. But actually I wanted to do that even before I know that Agile exists. So what happened back in 2010 I switched my job. So I went to the organization that just started to implement Agile in Moldova. That was 15 years ago. And they did amazing stuff. So I remember the cto, coo, that person was writing code together with us. We are delivering, we are getting the direct feedback from the clients. We are doing crazy stuff for me at that point because I worked only in waterfall and I looked at that and said, look, this is what I want to do because previously I had experience on delivering stuff on Friday evening, directly in production, running the skill scripts in production. And then on Saturday somebody called you and say, look, the server is down. Now you need to go back and restart it because we need to deliver. That was waterfall, that was fixed scope, fixed time, fixed budget. Yes. So yeah, this is how I decided to become a Scrum Master. When I see. I saw how this looks like.
- [05:20]
A
Yeah, absolutely. And it's interesting to hear when you think about how we evolve through the understanding the profession and also our place in it. Right. Like you said, you did quite a few years programming and then you realized that actually you wanted to be there to support people, to help them succeed. Because you also saw, just like you just illustrated the story of the CTO that was there with you in the trenches, doing the work together. That's a great leadership example. But of course, being a Scrum Master isn't easy. There are very difficult moments sometimes. And that's exactly what we want to explore because it is Failed Monday here on the podcast. And we want to hear of one of those moments, Natalia. So tell us the story of that moment. We'll dive into the lessons learned and the takeaways later. But tell us that story first.
- [06:10]
B
Yeah, so actually I had multiple failures in my career and I'm not ashamed to say about that. So I tell that stories to my friends all the time because I learned from that a lot. And this is how we, we evolve and we develop ourselves. But one story stay with me in particular. So that happened about 10 years ago when I just stepped in into my first kind of blend between Team Lead and Scrum Master. Also, I was both team lead and Scrum Master. And I remember that I just returned from my maternity leave, so I was like about nine months off and I didn't have enough kind of capabilities, so Net Framework was already evolved. So a lot of stuff happened in nine months. And I was asked to be a team leader and Scrum Master for the team. I thought that my biggest strength, but then I understood that this was my biggest weakness. This is my technical background. So I was coming into the standups in the morning, I said, look, I know how we need to fix that issue. I know what kind of technical solution we need to implement. And I was a Scrum Master, you know, so I don't need to suggest technical, technical solutions. So then my team started to implement a couple of solutions that I suggested and they failed because I, I was a former leader. They need to listen to me. And then what? I understood that actually I need to choose. Even I'm a team leader. Well, I, I, I'm going to be a Scrum Master. I chose and I have chosen the most technical person in the team. So that person became technical authority. And I just took the Scrum Master role and I never stepped in on his feeds anymore. So we are just synchronized and we had a great relationship with that person. So even now we are friends. So he followed me to another job, by the way, so he came up after me to another job. So that's amazing. But when you do that switch between a technical role, you switch from technical role to become a Scrum Master. What we need to be aware that your technical expertise could be useful, but you don't need to use it in the direction of a team. Like, I mean, it's very good to understand what you are doing and what the team is doing, but it's not very good to suggest technical solutions that's a very interesting.
- [08:37]
A
It's a very common, especially for those of us who have a technical background, it's a very common situation. It's also very interesting from the perspective of deciding where you want to let teams fail and where you want to protect them from failure. When I hear your story, I'm thinking, okay, but you have so much experience, right? Like, there's a lot you can give the team that would help them succeed. And not all solutions can succeed. That's the same no matter where they come from. Right. Whether they come from us as Scrum masters or they come from a tech lead or the teams themselves, not 100% of solutions succeed. So the failure in itself is not a problem as long as it is contained. And it is, let's say, short term, quick feedback and so on. So when you look back at that story and now that you are more in the leadership position, you're not so much in the development teams. How do you keep yourself focused on establishing that clear line between when to ask questions and when to step back and let the team take over?
- [09:41]
B
It's very complicated even now because I'm. I was an introvert, now I'm an extrovert probably. I'm kind of. It's very hard for me to not suggest solutions. So I'm in that kind of solution mode all the time. So it takes me a lot of kind of time and effort to shut up and listen. So I think probably the active listening and active understanding what is happening in the room without trying to suggest anything is the biggest challenge that I have right now. But I manage, I just say, okay, if I say this now, the team will not have possibility to propose another solution in the room. So I can say something, I suggest something, but as a last option, if nobody else have anything else to say. So just like try to keep myself on this kind of boundaries. Yeah, but it's very complicated. I mean, some of the people, they can do this easier. For me, it's not very easy.
- [10:42]
A
Yeah, absolutely. And I think that it's critical for us to understand that it's the people who care that want to intervene. And it's out of a good sense of wanting to help and wanting the team to succeed. But the story that you just relate is very important when we as outsiders, because Scrum masters and tech leads, even tech leads and otherwise people, leaders, when they intervene, they take ownership away from the team. Right. Like they trust you. So when you say something, you go, oh, they said it, so it must be true. Let's do it that way. But then when it fails, they don't have the thinking to adapt your solution to their contact. Right. And we prevent their learning and their ownership by us taking the ownership and saying, hey, let's do this instead. Right?
- [11:35]
B
Yeah. As long as you don't manage to bring everybody on the same page and make them to understand your solution or to come like a cumulative solution between a part of your solution and part of your colleague solution. So it will be like a collaborative solution. This is not going to work. So I think it doesn't matter how good the solution is. It's very important if everybody is on the same page, if everybody understands, ovet should work.
- [12:01]
A
Yeah, absolutely. And that's a very important point. Let's just make sure we're on the same page. And then whatever decisions you make, if I don't see any obvious problem. Right. Then let's just go ahead. It's a great story. Thank you for sharing that, Natalia.
- [12:16]
B
Thank you.
- [12:20]
A
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 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 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 membership 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. 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.