B (3:56)

So I have a similar kind of story, although I did stop by in the project management station before I went from technical to Scrum Master. I often call myself a recovering project manager and I use recovering because I very often fall back to what I learned as a project manager. And I'm keenly aware of that, also painfully aware of that. But it is something that I'm kind of trying to bring in the best from project management without necessarily bringing in the worst because there are great practices also in the, in the project management community that we can all benefit from. But, but the people aspect is really important. And because today is Monday, Fail Monday here on the podcast, we should never forget that we are people too and we make mistakes. And in fact, that's the first question we have for you, Terry, in your learning experience as a Scrum Master and also as a coach, what is that one failure that you want to share with the community and of course also share the learning, but share that story with the community.

C (5:05)

So just in the interest of honesty and transparency, I've had many failures. Vasco. Okay, it's not like the one I'm going to describe is the only one, but I think it's one that makes for an interesting story and a learning that we can all take from it. So I mentioned my first role as a Scrum Master was kind of accidental and it was a space where we were allowed to experiment and try things and get it a little bit wrong and then improve it, literally. My second engagement as a Scrum Master was quite different, but I didn't actually know to sense the system, to actually understand what is it about this system that drives the behaviors in the team. And I thought I was there to be Scrum Master and it's like, oh, we need to estimate with story points and have a daily standup and do all these Scrum things. Oh, we've Got to have retros and reviews and planning. And once we do all those things, everything else will be okay. Because the broader system was the thing that was actually driving the behaviors in the team. So without sensing the system, I was there trying to drive processes and practices and the team were not actually responding to it. They were not able to respond to it.

B (6:26)

So tell us a little bit more. So we got the picture right. Like your second engagement, focusing on the practices, making sure people show up for the daily that we have the refinement sessions and so on. And at the time you didn't yet know that you weren't sensing the system. That's an important part of the story. Right. So what was that moment when you realized that, hey, wait, maybe it's not the practices that are not working, maybe something else is going on. Describe that for us.

C (6:58)

Yeah, so it was really just struggle for a while that forced me to think, I need to look at this differently, I need to try something else because this just isn't working. And what I didn't know until I started to try different things was that the way that organization was structured, the testers reported to a test manager and the developers reported to development managers and bas reported to analyst managers. And I was there trying to operate as if this was a team. But the way the organization was structured, it was just a loose knit bunch of talented professionals. So trying to bring people together on this idea of sprint goals. And you know, when we take a story into the sprint, we need to finish it. Little things like that really didn't work until it became clear after I struggled for a while, not really getting traction, not really helping people, that actually people had their own KPIs and those KPIs were putting them into conflict with each other. What I needed to do was actually to coach the organization as much as the team. But I wasn't ready for that as a coach.

B (8:24)

So let's explore that because that's an important insight. Often talk about how important it is to have KPIs to know what success means. But you're talking about a specific type of KPIs, and I don't know, you haven't shared, but I'm assuming you're referring to individual KPIs or performance metrics that every individual separately must adhere to, not the team as a whole, which as you said, wasn't a team yet either. Right? That's what you were referring to.

C (8:57)

No, that's exactly right.

B (8:58)

So how do you go about changing that?

C (9:02)

So we had to have conversations with the leaders of the various practices. They weren't called practices then, they were just managers. And we didn't have any KPIs for a team. And we literally had KPIs for developers about less defects and KPIs for testers about finding more defects. Right. I kid you not. So the developers would hold onto things as long as possible. They try to make it absolutely perfect before sharing it with anyone. And that meant then the testers were under pressure because there wasn't time to do the testing properly. And they'd also call anything a defect. I actually had like behavioral things appearing in the team where people were literally in conflict with each other and disliking each other. You imagine in a team, people disliking each other. They don't want to talk to each other. They don't want to actually share anything meaningful when we're coming together for our various events. So we had a conversation with the various managers and the one thing we were able to do was to just modify them slightly. We didn't change the whole system to get to Team KPIs and eliminate these individual KPIs that were causing so much dysfunction. But we did get to adapt them a little bit. So rather than finding more defects, it was about defect leakage, which was kind of a different way to look at it. And we could share some of the KPIs across different people. So then the defect leakage was for the developer and the tester together. And then that allowed them to actually start to collaborate a bit better. It never got all that good. But the learning for me from that was you do need to understand the system that you're in. The Scrum Master is not just the coach for the team, they're the coach for the organization as well.

B (11:00)

That's a very important realization, which is this idea that we need to look at Scrum Masters, of course, leaders in general. Right? Not just Scrum Masters, but Scrum Masters as kind of the triggers and the catalyst. We need to be looking at the end to end performance of the system. And that starts with first defining what the system is. Because of course, although in the story you told, it is quite obvious that individual metrics for individual people will be conflicting in some cases. It's also possible that individual team metrics for individual teams will be conflicting in some cases. And we need to look at. Yeah, exactly. And we always need to first start by defining what the system is and then start measuring that system. Not the people and not individual teams either. That's a great story. Thank you for sharing that with us. Terry.

C (11:56)

My pleasure. As I said, I've had many other failures, but I think that's one with a good learning.

A (12:05)

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.

B (13:57)

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.