B (4:51)

It's funny because it's kind of the same thread for both books, right? Like, it's the text that isn't in the text, right? Like, it's the understanding that is behind the text that is trying to come out through the text. But it's not always easy to grasp at first reading. But also the other thing that, especially the Scrum Guide, I'm sure will be like that for most of us, which is that when you read something before you have experience, it means something. When you read something after you have experience, it means Something else. And then when you read something after you've made many, many, many mistakes that are similar, it will mean something else altogether. So there's an in depth that comes with also experience. Some might call it wisdom perhaps, but definitely experience of going through several situations at the same time and talking about experience and going through same situations at the same time. One of the things we very often don'. Talk about as Scrum masters, that teams actually can create their own problems. Yes, sure, there's influence from the outside, other teams, management, whatever that is, but teams can create their own problems. And that's the story we want to hear from you, Alex, so that we may learn to detect those patterns as they emerge in front of our eyes before they become a problem. So tell us that story, give us a little bit about the context of that team and then walk us through those steps or behaviors that maybe started small but over time became a real problem for the team.

C (6:17)

Yeah, I mean, I think we've all probably been in a situation where we've seen things go sideways in teams. And one of the gnarly examples that I reflect upon a lot, you know, one of those things that keeps me up at night, like the, like. The goal is I was working with a client at a aviation company around 2018 and it was a small team and for whatever reason we had a PM on that team.

B (6:48)

PM as project manager or product manager.

C (6:51)

Project manager, yeah. Not a product manager, a project manager. And the way the project manager engaged with the team was quite toxic. So they would like belittle people in the team in public. They would take notes at every team meeting so that later on they could argue with team members about what they committed to and what they said in meetings. There's a line in the Agile Manifesto about this. Right. Contract negotiation. That's essentially what this person was doing.

B (7:29)

They were without permission, by the way, contract negotiation without permission, absolutely.

C (7:35)

And they were using it like a weapon. You know when you're seeing contract negotiation happen in a bad way, when it's used like a weapon. We had one person join the team in the morning and by the end of that day they quit. They lasted less than eight hours on the team because it was. That project manager was so toxic.

B (7:56)

Wait, wait, wait. If it was that toxic for somebody coming from the inside, the next interesting question is how come the people who were on the inside didn't quit?

C (8:05)

Also because they were cowed and subdued and dominated by this project manager who would put you down in a room with their written notes and get you to Submit to their authority and their dominance. It got to the point where one of the team members didn't come in to work one day and sent an email to the team. And the email kind of looked like a suicide note. It had that kind of vibe, right? And I had to like, do something about that. So I had to make sure to talk to this person over the phone, make sure that they were, that they were well, that it wasn't a suicide note. And ultimately what ended up happening was one day I was in that team and I was creating slide decks for agile trainings and I was working with the project manager and they looked over at me and they said that my slide deck velocity was too low, that they could create four slides every 15 minutes from my one slide. So they're like comparing slide deck velocities between. And eventually I came to the conclusion that that project manager was so toxic that I couldn't work with that team anymore. My solution was actually to exit that team and I ex at that client. Now I look back and I asked myself, was there anything I could have done? And I don't think so really, but I have reflected on like, in terms of the Scrum values, what was it about that project manager that kind of made me want to go somewhere else? And I think it was. I think it was respect. So if you read the Scrum Guide, one of the Scrum values is respectful. And I urge you to go read the Scrum Guide and look at the Scrum values and reflect on those and how those values, whether you live them or not, could affect your team. And that's my story.

B (10:16)

And that's an important story. We don't always win, but it's very important to know when you're losing enough that it's better to leave. And that's something we've had here as a theme also in the podcast before. But it's always great to remember that you can't win all of the potential improvement fights that you're involved with. Sometimes the system just takes over and I'm reminded, and I don't know if you know about this or if you ever thought about this, I'm reminded that for a person like that to be accepted within the team, you need two sides of the system to agree that that person brings value in some way. So one is the team, because the team can rebel against that can make their life hell as well. So it's not just one sided. And then the other is that there's an expectation from the manager of that person that they are doing a good job because if that would not be the case, eventually they would be let go as well. So when you think about that, obviously you decided to quit, so you were no longer going to take it anymore. But what do you think about these two other sides, like the team members and the organization or the system around that person as well?

C (11:30)

Definitely. I came to the conclusion that they were being encouraged to act that way by upper management in that organization. And my conclusion was that they were doing that to control the team and ensure that the team did the work that they were committing to. That whole contract negotiation thing. Which means, you know, did management really trust the team in the first place? I don't think so. What caused it? I don't know. Had trust been broken in the past? I have no idea. But there was definitely no trust in the system, as it were. Management, I think, was encouraging that behavior in terms of the team. They were just completely dominated and submissive. Probably the closest example I can think of is learned helplessness, where people just become used to being helpless and eventually they just submit to that helplessness because they believe that there's nothing they can do to change the situation. And for sure there are organizations where I think they try to adopt agile ways of working for perhaps not the most healthy reasons. And yeah, sometimes I've had to self exit clients where I think they're not really embracing the values that I personally hold dear, which are like this, what I'm doing.

B (12:53)

Great story. Thank you for sharing that with us, Alex.

C (12:56)

My pleasure.

A (13:01)

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 in question, 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.

B (14:00)

Free of all of that AI slop you see everywhere.

A (14:03)

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@scratch 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.

B (14:51)

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.