
Gosia Smoleńska: Coaching Agile Teams Beyond The Resistance Threshold Read the full Show Notes and search through the world’s largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. ...
Loading summary
Vasco Duart
Hi, I'm your host, Vasco Duart. Welcome to the Scrum Master Toolbox podcast where we share tips and tricks from Scrum Masters around the world. Every day, we bring you inspiring answers to important questions that all Scrum Masters.
Unknown Host
Face day after day. Hello, everybody. Welcome to our team Tuesday. This week we have with us Gosia Smolenska. Hey, Gorsia. Welcome back.
Gosia Smolenska
Hello. Welcome back.
Unknown Host
So we're going to talk about teams and how sometimes they become their own worst enemies. But, well, there's another story about that from yesterday's episode if you want to check it out. But before that, share with us. Koshia, what was the book that most inspired you in your career as a Scrum Master?
Gosia Smolenska
It was the Culture Map from Erin Meyer. This is a book about cultural differences, and because we work in so diverse organizations, it's a great book to understand the dynamics and the differences, especially in giving and receiving feedback, in making decisions, and even in being on time. What does it actually mean, being on time in different cultures? So it was, like, mind blowing for me. And I think that's a great book to read.
Unknown Host
Yeah, absolutely. Even simple things like being on time can have a significant impact and meaning in different cultures. I think this is a very important thing to recognize. And of course, that's just an example. There's a lot more in human interactions. So we'll definitely put the culture map link in the show, notes for people to go and check it out. And speaking about culture, of course, Tuesdays are team Tuesdays here on the podcast, and they have their own culture. So, Gorgia, tell us the story of a team. Walk us through a little bit of the context so that you know how many people, what kind of project they were in and so on. And then tell us how those small little behaviors developed over time and eventually created a problem for the team.
Gosia Smolenska
So we were the vendor company for a big pharmaceutical company, and we as a vendor, supposed to deliver some part of a code which was old, and our job was to rewrite it and make it perfect, or at least make it nice. Team was conducted with, I think, 20 people. It was three different teams. They were working together. The product owner was one. So they did have bits, different goals. Each team, however, there was one lead who was mostly collaborating with the vendor. So not with the vendor, but our customer. We were the vendor. And what was happening was that client was not really happy with our progress. It was like small things. During the review sessions, they were mentioning, oh, we were expecting that this will happen, or till this day we were expecting that we will get already this amount of work from you. Because how it works is our team was supposed to keep the code base and then the customers team supposed to switch it in their environment for the old program, for the new program. So it started with like really, really small things, not hitting the deadlines, not really being aligned with the customer and all the alignments till this time was done by the Devlin. This was how the company worked, this was how the vendor companies set up their area of work for this particular customer. And this is how they worked since the beginning. I joined like in the middle, so I started questioning like, why is only dev lead speaking with the client, not the product owner? Where is the product owner? There are no product owners, there is only pm because product owner was actually the client product owner. So PM was responsible for money and for budgeting, for time, license and pm.
Unknown Host
Do you mean product manager or project manager?
Gosia Smolenska
Project manager, yeah, yeah, because product owner was just a customer. So what I noticed is that the dev lead and again cultural differences because dev lead was from different culture, client was different culture and the team was different culture. So you have mix of everything. And to add up on that, it was like from all around the globe. So it was not even Europe, it was different continents. David was afraid that the code quality is not good and that they will be judged by the code quality. So what he was doing, he was asking all the developers to firstly send the code packages to him. He was reviewing that and then he was sending the packages to the customer. When they started, it was only five people in the team back then it worked, they were not doing, they were not missing the deadlines. But when the team grew bigger to 20 people, it's hard for one person to review everything and still be on time with customer. So actually the work for me was to coach and mentor the dev lead on his insecurities about the code quality instead of working with the team. Because team actually did nothing wrong. They did their job, they did their tasks, they did deliver the value, but the value was always stopped on the dev lead sites. So he always blocked it because he needed to review it. And we actually never, never fixed this problem. I left this company quite after six months, I think because there was, it was impossible to actually change his mind. And even client was like, I'm not buying your story, I don't like it. So yeah, this is how that is.
Unknown Host
A really difficult situation when you realize that for the team to really deliver on the customer's expectations, somebody in the team needs to significantly Change their own way of working and even their own personal expectations of how the work gets done. And of course, that may not be possible now. It's not very common that there's only one person that needs to change. Usually there's a lot more, like managers that need to change and developers and testers and so on that need to change. But in this case, it's even scarier because only one person needed to change something and they couldn't.
Gosia Smolenska
Yes. And the sad part was that this was really good engineer. It was really nice person. So it was not like it was something wrong with him. And you could see it. It was really nice person. It was really good engineer. He had a lot of knowledge and his worries were somehow true because the code quality was not the best one, but the code was working and the value was delivered. And this was why the customer was paying us. So, as you said, when you have to work with only one person and the company, because we as a company, we were big vendor companies, so they were not really paying attention for one person in the team. So it's you who somehow needs to help.
Unknown Host
Absolutely. And when you think about this kind of like, I mean, I've been in therapy for many years and I know how hard it is to change, even when you want to. But then when you are driven by fear, like in this case, right. Like you're afraid the code will be bad and that will reflect on you. And fear is the ultimate motivator. People will do crazy things if they are afraid. And our role would be to try to help this person to step out of that fearful reaction. But that is not. Even psychologists can do that all the time.
Gosia Smolenska
And there is a question for us as Scrum Masters. We do coach, we do mentor. But where is there this line to stop? Where is this line that, okay, I have no other tools. I cannot help you because I did everything from coaching. I had. I did. For example, in coaching, you have this exercise which is Experts Circle. I'm not sure if it's proper name in English, but it's like if you would have expert, who would. What. What the expert would you tell on this situation? And this is what we can do as a Scrum Masters. But also we need to remember when we use coaching that the person needs to agree. And what if the person doesn't agree on coaching? Then we have mentoring and we not always have experience in situations like that. So how can we mentor when we don't have experience?
Unknown Host
Absolutely. For me, what this story illustrates is the fact that we also talked about this yesterday. We work with people, period. People do the work that the clients need or the employer needs, but we work with people. And when people don't want to do the work and they might have good reasons to, there's nothing we can do. And I think that what you said, that you eventually left because there was not much we could do anymore. I think that's a very important boundary for us, for our own mental well being to be able to set right. Like there will be situations in which you can't really help the person because they don't want to be helped.
Gosia Smolenska
Yes. There is an old saying. I don't remember who said that to me, but I think it was somewhere at the beginning of my career and I still remember that. It's change organization or change the organization.
Unknown Host
Absolutely.
Gosia Smolenska
And I still keep it with me because there are situations for us Scrum Masters than, as you said, if people doesn't want to change and it's work with people, then we have to have some boundaries and to keep us safe and to keep us still not burned out, because we also can have burnouts. We need to have our boundaries.
Unknown Host
Yeah, absolutely. That's very well said. We need to have our boundaries. Thank you for sharing that story, Gosia.
Gosia Smolenska
Thank you.
Vasco Duart
Tuesday is team day here on the Scrum Master Toolbox podcast, but tomorrow we talk about something that goes beyond the work we do with the teams. We will talk about how to lead change and what our guests have learned from leading and participating in change programs during their career. See you tomorrow. 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.
Scrum Master Toolbox Podcast: Agile Storytelling from the Trenches
Episode: Coaching Agile Teams Beyond The Resistance Threshold | Gosia Smoleńska
Host: Vasco Duarte
Release Date: November 19, 2024
In this compelling episode of the Scrum Master Toolbox Podcast, host Vasco Duarte welcomes Gosia Smoleńska, an experienced Agile Coach and Certified Scrum Master, to discuss the intricate challenges of coaching Agile teams that encounter significant resistance. The conversation delves deep into real-world scenarios, cultural dynamics, and the emotional toll that such situations can take on Scrum Masters.
Gosia Smoleńska brings a wealth of experience as a Scrum Master and Agile Coach, having worked with diverse teams across various industries. Her insights stem from hands-on experiences in managing teams with multicultural backgrounds and navigating complex project dynamics.
Gosia recounts a particularly challenging situation she faced while working with a vendor company contracted by a large pharmaceutical firm. The project involved rewriting and perfecting legacy code, a task that seemed straightforward until cultural and managerial discrepancies began to surface.
Key Points:
At 00:52, Gosia highlights the pivotal role of cultural understanding in Agile environments:
"It was the Culture Map from Erin Meyer. This is a book about cultural differences, and because we work in so diverse organizations, it's a great book to understand the dynamics and the differences, especially in giving and receiving feedback, in making decisions, and even in being on time."
A significant issue arose from the way leadership and communication were structured within the team. The development lead, David, was the primary liaison with the client, a setup that initially worked with a smaller team but became problematic as the team expanded.
Challenges Identified:
At 04:32, Gosia emphasizes the cultural clash:
"What I noticed is that the dev lead and again cultural differences because dev lead was from different culture, client was different culture and the team was different culture."
As the team grew, the centralized review process became unsustainable. David's need to personally review every code package hindered the team's ability to meet deadlines and deliver value efficiently. This created a stagnant environment where the team's efforts were bottlenecked by a single individual's insecurities about code quality.
Gosia's Role and Challenges:
At 07:31, Gosia reflects on the personal attributes of the problematic leader:
"It was really good engineer. It was really nice person. So it was not like it was something wrong with him. And you could see it. It was really nice person. It was really good engineer."
A significant portion of the discussion centers around the emotional and mental boundaries Scrum Masters must maintain. Gosia and the host explore the delicate balance between helping team members and recognizing when a situation is beyond their capacity to influence.
Key Insights:
At 09:53, Gosia shares a poignant piece of advice:
"There is an old saying. I don't remember who said that to me, but I think it was somewhere at the beginning of my career and I still remember that. It's change organization or change the organization."
The episode also touches on practical strategies that Scrum Masters can employ when facing resistant team members. Gosia mentions the use of exercises like the “Experts Circle” to facilitate problem-solving and encourage alternative perspectives within the team.
Discussion Points:
Gosia Smoleńska at [00:52]:
"It was mind blowing for me. And I think that's a great book to read."
Gosia Smoleńska at [07:31]:
"It was really good engineer. It was really nice person. So it was not like it was something wrong with him."
Unknown Host at [08:23]:
"People will do crazy things if they are afraid."
Gosia Smoleńska at [09:53]:
"It's change organization or change the organization."
This episode of the Scrum Master Toolbox Podcast offers invaluable insights into the complex dynamics of Agile team management, especially in multicultural and high-stakes environments. Gosia Smoleńska’s experiences underscore the importance of cultural awareness, effective communication, and setting personal boundaries to maintain mental well-being as a Scrum Master.
Listeners are encouraged to reflect on their own team dynamics and consider how cultural and individual differences can impact project outcomes. The episode serves as a reminder that while Scrum Masters play a pivotal role in fostering Agile practices, recognizing the limits of their influence is crucial for sustained personal and professional health.
Stay Tuned:
Tomorrow's episode will explore leadership in change management, featuring guests who have led and participated in various change programs. Don’t miss out on actionable insights to enhance your leadership skills in Agile environments.
Support the Podcast:
If you found this episode valuable, please rate it on Stitcher or iTunes, share it with fellow Scrum Masters, and help us continue providing essential Agile Business perspectives.