← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
When Politeness Becomes the Enemy of Team Growth—Escaping the Conflict Avoidance Trap | Mohini Kissoon
00:15:02
Loading summary
Transcript13 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 our Team Tuesday this week with Mohini Kisoon. Hey Mohini, welcome back.
- [01:19]
B
Hi Vasco.
- [01:21]
A
So Tuesday is Team Tuesday of course here on the podcast. But before we dive into the team story, share with us what was the book that most inspired you in your career as a Scrum Master? Mohini.
- [01:35]
B
There'S quite a few books which has really helped to shape the way I think and the way I run teams and one of them which really stood out for me is the Turn the Ship around by David Market. This is a classic and I came across it at a time when I was working with multiple teams and honestly felt really exhausted. I kept being the person everyone looked to for answers and while I thought that that's what servant leadership is, I was starting to realize I was creating dependency rather than helping my team to be capable. So the story that Market tells in the book is how he took command of of the worst performing submarine in the US Navy and he turned it into the best by fundamentally changing how leadership worked. One of the light bulb moments for me when he talked about the leader follower model and the leader leader structure. So instead of the traditional leader follower model, he built a leader to leader structure where everyone was expected to to decide and own their work. And for me what really stood out was we don't just empower teams, we need to build an environment where they can grow and where they don't need the permission to excel. And that shifted something in me where I realized I wasn't serving my team well by being the hub of all decisions. So I was actually preventing them from from growing. So I started changing my language instead of saying here's what I think we should do, so I started saying instead, what have you tried so far? What do you intend to do next? So instead of just solving the impediments for the team, I started coaching them to solve the impediments themselves. And that was that point where I was focusing more on the coaching stance of a scrum master. So I was developing my evolution in that area as well. And I must admit it was quite uncomfortable at first to be when people asking me questions and I ask them questions in turn. But over time I watched teams to stop waiting for me and they started experimenting, making calls, holding each other accountable.
- [04:20]
A
Absolutely. By the way, that's a really important aspect of the work that we need to do. Right. Like to enable teams to take actions on their own because we're not going to be around all the time and neither are their leaders. Right. Because David Marquez story is not just about us grandmasters. It's also about, as you said, the leader to leader structure so that the teams can progress and take action with the right guardrails, of course, but take action within their context in order to reach their goals and solve their impediments in the end. And talking about. Oh sorry, go ahead Mohini.
- [05:01]
B
I was just going to add, like when you mentioned guardrail, it's really important to highlight that in the book he also talked about competence and clarity that we shouldn't be just pushing decision making down without making sure that we are providing the knowledge and the context needed to help team to make decisions. So we need to be providing them with all these necessary materials in order for them to fend for themselves later.
- [05:30]
A
Absolutely. Talking about teams is what I was going to say next. The next story is about a team that self destructed. Now I don't know what story you have to share with us. Obviously sometimes we are responsible for that self destruction. Sometimes we try our best to avoid it, but we can't help either. I don't know what kind of story you have to share with us, but we want to hear that story, Mohini. The story of a team that went into the path that eventually caused problems for the team. And walk us through the small little behaviors that maybe you observed at first that grew and eventually cause the team to self destruct.
- [06:12]
B
Yeah. So in my opinion the worst self destructive pattern that I have seen is when team members are overly polite just to avoid addressing conflicts. So there was a team I was working in that really prided themselves of being Collaborative and also drama free. But that was on the surface. So beneath that politeness was that hesitancy to have difficult conversations. So it started small. In Sprint planning, for example, the product owner would propose a scope that everyone knew was unrealistic, but people would just nod, just accept. And sometimes someone might say, that's quite ambitious, but no one would actually push back. And in retrospective as well, the feedback was very gentle, always wrapped in different layers of positive framing. And when one of the developers also consistently delivered work that didn't meet the team's definition of done and that caused some rework, no one would actually call it out directly as well. They will just quietly fix it or work around things. So after three months in, I started noticing the side conversations where people would pull me aside after meetings to share concerns and they would never voice it though in a room. So the challenge for me was they were coming to me to have those conversations individually. And then when I was setting up like a retro and then encouraging them during the retro to voice out these concerns in a group, it turned out that I was the only one calling out those issues. And it's just felt that there was no problem. So at some point, even the managers at that point was encouraging me, just let the team to work the way that they want and then they won't have the time really for us to work through the dynamics of the team. So I still though, try to do a few things in terms of walking them through the Tuxman model and through the team's development. And I really emphasize that we are skipping the storming phase. So there are teams who are very afraid of going into the storming phase, which I feel is a very important phase to go in to address any conflict. And that's the phase that we get to know each other better as well. Like, you know, what are the things that we like, how do we like to receive feedback, how do we want to work, work. But that was kind of missing and what happened then. So we had to identify towards the end what needed to be removed from, from, from the work that in order for us to meet the, the deadline and agree with stakeholders. So it's producing some metrics as well to show that we are not going to be able to meet the deadline because we already have, we, we have so many things still in the backlog. And it was only as we were nearing to the deadline then people started to listen to what I was saying. So yeah, so that was for me was like the learning is the conflict, isn't the enemy but it's mainly when we avoiding conflict, that's when it is an issue for teams.
- [09:51]
A
For me, the key word here is avoiding. And conflict is just one of the things that teams avoid. They also avoid shame. They avoid being exposed to uncomfortable situations, conflict being one of them. But there are others. And for me, what I've always learned, and especially from my own work, I've been in therapy for many years and been vocal about how positive and how productive that process has been for me here on the podcast. And one of the things I've gotten from that process is the ability to face discomfort but still remain calm. Because one of the reasons why teams avoid the conflict is because it is dysregulating. And it's entirely okay that it is dysregulating. It takes a lot of work and practice to be able to face conflict and remain calm, remain present, remain focused on what is it that we are really trying to achieve here, rather than feeling ashamed or feeling blamed or whatever that is. Right. So when you work with teams today, how do you help them specifically in the context of conflict, how do you help them learn to be okay with having conflict?
- [11:11]
B
So first I try to see where the conflict is coming from and, and really address it from that perspective. In that case, I feel there were so many, so many areas where it was coming from. There was a high pressure of the project they needed to deliver. But I tried to address it in a way that create that psychological safety for them that it's okay to sometimes to disagree with things and find a way to really deliver feedback in a constructive manner as well. And also not giving any. Some kind of the way to give feedback, but not giving them in a way that it felt that the person is being attacked. So we need to be rather addressing the problem and not the individual. And that's where starting the retro, always making sure that we are. I always make sure that we are not blaming each other. So it's not a blaming game. We are here to stop and reflect. How can we get better? Each sprint or however the team is working in, it's making it really safe for us to fail and then to call out anything that we feel is.
- [12:33]
A
Not working well, making it safe to talk about difficult topics. Thank you for sharing that story with us, Bohini.
- [12:42]
B
Thank you, Vasco.
- [12:46]
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 at Scrum Master Toolbox 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.