← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
How to Break the Cycle of Dominant Personalities in Agile Teams | Mohini Kissoon
00:16:33
Loading summary
Transcript11 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. For those of you still enjoying the break time, happy New year everybody and hope you had a great time out and time off. And this week we have with us, joining us from Australia where it is summer right now, Mohini Kisoon. Hey Mohini, welcome to the show.
- [01:36]
B
Hi Vasco. Hi Vasco. Thanks for having me today.
- [01:40]
A
Absolutely. So Mohini is an agility lead with over 8 years experience as a Scrum Master and she's passionate about building high performing, self managing teams that delight customers. She improves flow and collaboration across systems, meets teams where they are and co creates environments enabling adaptability, meaningful interactions and of course continuous improvement and learning. Which is exactly what we are here to talk about. Mohini. So that was a short intro. Tell us a little bit more about yourself and how did you end up becoming a Scrum Master?
- [02:18]
B
Sure. So I started my career in IT about 20 years ago as a developer implementing web based projects. And over time I moved through different roles such as ba, SAP Analyst and PMO as well. And it was during my time as a PMO analyst that I came across the Agile practices when I was working for an organization which was actually going through a major digital and organizational transformation. So several opportunities opened up and I put my hand up to join the team who was implementing that transformation. And to be honest, at first when I heard about Agile I was a bit skeptic. So at the beginning I thought that, oh, it's just another framework that we are being told to adopt from above. And I remember also sitting in an introductory Session where someone was talking about self organizing teams and iterative delivery. And I was thinking, yeah, that sounds very nice in theory, but how does this actually work when we have real deadlines and real stakeholders who want everything now? So what I didn't understand at that time was that Agile is not a solution being handed down. It is a different way of thinking about how we solve problems together. And that realization came later once I started actually practicing it rather than just hearing about it. My journey as a Scrum Master really kicked off when a project manager reached out to me and encouraged me to join a team he was putting together. He wanted my help to implement an agile ways of working within the team. And him and I, we have worked together before as I was, I was in a PMO capacity and he was aware that I was interested in learning more about Agile and also attended a few training sessions on Agile foundations and Scrum framework. And I was also looking for an opportunity to implement my learning. So the place also, the place was buzzing with energy and everyone was learning at the same time. And I just feel that was the right time for me and I just said Y. So I started experimenting and I started to set up the Scrum events, teaching the team about the foundations and facilitating the events. And as I gain experience and confidence, my scope expanded as well. So from setting up new teams to resetting existing ones, then working with teams on a larger scales where I started looking into other frameworks like Nexus and Safe as well. And then I led the growth of a Scrum Master chapter and mentored Scrum Masters as well. So my role then.
- [05:24]
A
Yeah, that's quite a very interesting story for me. What registers is that early skepticism. I can totally identify with that because I was an early skeptic. Like the first project that I did, I didn't think it could work. Eventually it did much better than I expected and that made me a convert. I don't know if that's what happened with you, but as we go through this journey, there's a lot of lessons we must learn. And today's Monday here on the podcast. So we want to explore one of those lessons, right? Because failure is part of that journey and we shouldn't be ashamed of it. It's just part of the journey. We should share it and we should learn from it. So that's what we want you to do with us today, Mohini. Share with us a story of a moment where things just didn't go as you expect. And then we'll dive into the takeaways and the Lessons learned later. But share that story with us first.
- [06:18]
B
Yeah, so there are many stories and I would say I'm grateful for it as well because that allowed me to learn from my mistakes and to be better at what I do. And when I just started in the role, I was mainly focusing on the process and less on the people, so which is very different to what the Agile Manifesto preaches. So we should be focusing more on the individuals and interactions and all the processes and tools. But I was doing it different. So that happened in my first year as a Scrum Master and I had just earned my certification. I was full of energy and deeply committed to be doing things, to be doing Scrum by the book. And I also joined a mid sized product team as well. So. Well, in that team there was a senior developer. He was a brilliant individual but quite dominant as well. So I'll just call him Tom for this purpose of the story. So in every session Tom would speak first, would speak speak longest and often override others ideas. The junior developers, I noticed it but I didn't intervene as I thought that, you know, he's got a lot of experience, more than the others and he's very passionate about what he does and the others are quiet as well and not saying anything. So I just assumed that they were agreeing with his thoughts. And he was also responsible for mentoring the juniors and. But before several, but over several sprints I started seeing the impact. Our standups were like a reporting session, an update session to Tom, rather than a collaboration between the team to plan their day together and to reprioritize the work. So the session was turning into a solution based discussion as well. And there were disagreements and sometimes Tom was shutting down some ideas very, very easily and quickly. And at some point the junior developers, I could see they were gradually stopping to offer their ideas in fear of just being shut down. And for me I thought, well, if we just followed the framework perfectly, everything else will just fall into place. And I just continued to focus intensely on the mechanics and this is where I failed.
- [08:52]
A
Tell me a little bit more because of course now you're looking at it with the perspective of hindsight, right? Like because that you know more than at that time, but when you were there that was not your perspective. So I'm interested to hear how you felt at the time. Like what were you seeing and how was that landing with you? The interaction between the team members and tomorrow and Tom's reactions and behaviors as well. How was that landing with you at that time?
- [09:23]
B
So at that time for me I felt that, yeah, it's not the right approach of how he's using, but at the same time, like I said, I felt that he had the knowledge and he was responsible for the team's growth and that was the approach that he was using to correct the people instantly. But I felt that it could have done that in a better way, like having one on ones with them and rather than just having it like a group conversations. And so what I did at that time as well is to reach out to some of the junior developers and just to get the point of view of how they were receiving those feedback and how they felt about it. And one of them mentioned that it was pretty much all of them saying that they didn't feel that they had a say in anything that was being developed, so they felt they were just a cog in the machine and that every single interaction was a hassle to get their point points across and that it was not a viable approach for them to really help them to grow in their role. And one of them was even considering to leave the organization. So it was at that point that really made me realize that my silence as a facilitator, as a scrum master at that point has been giving the wrong impression to the team, which was that this kind of dynamics is acceptable. So at that time I failed to create a space where everyone felt safe to speak, to make mistakes and learn from their mistakes and was really, I confused silence with agreement. Now in terms to your question, like how Tom was feeling about all this. So I also had a chat with him. I shared the feedback that I received with him without naming names and, and I was very kind of surprised that he was, I must say it was great that he was open to, to listen and hear those feedback because for him he was not across that the junior developers were not happy with the, with, with his kind of approach of giving feedback and he felt that he was helping them to grow and challenging them this way might help them in their growth. So I was happy to know that, you know, he was open to try some new things. And what we did, him and I, we started to brainstorm some ideas about how to address the situation. And I pushed him as well on some active listening. And I proposed to him, let's try to experiment something that in the next planning session, how about he just gave two or three people the opportunity to talk first before he produce his own ideas and we try that a few times. And it was also a way for him to remove a bit of a pressure off his shoulder because he felt that the team were really relying on him. That was each time he felt that he needs to be producing the ideas. So that was a way for him as well to just step back and listen to the ideas that the team can provide and then intervene when he can refine the ideas or, you know, give a bit of more advice on that. Yeah. And I also changed my facilitation style as well. So I introduced like silence, silent brainstorming, giving everyone the opportunity to share their ideas of the without being influenced and also doing a bit of round robin then for them to share their ideas.
- [13:29]
A
Those are very, very practical approaches. I really like how you frame this. Right. Like first open it up, hear what people have to say. In this case also with Tom. And it's great that Tom was open to that, to that collaboration, to that coaching. Right. Because not everybody will be. And that's okay because we're not responsible for what they decide. We can only open the door. They have to decide to cross the threshold. Right. And then the facilitation strategies kind of maximizing the opportunity for others to express their views without being influenced. I think those are very practical tips and approaches. Thank you for sharing that with us, Mohini.
- [14:11]
B
Thank you, Vasco.
- [14:16]
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. 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. 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.