A (3:43)

Are there any tips like any, any things that you have applied or you help your mentees with that, that helps to focus on that post retro action taking and ownership taking. Making a difference, I guess we could call it?

B (3:57)

Yeah, absolutely. I mean, the key again is ownership and it's collective ownership. I always talk about this is that it's not just the single owner. Just because your name is on the ticket, the team have the ownership of that improvement. Right. So, you know, I could give you a few examples of some of the things that, that have worked with teams in the past. You know, basically impediments that are ongoing, doing some root cause analysis and then, and then presenting the those changes and improvements at the end of the end of the sprint in the demo. But as I say, the key to cultural one and so the sorts of things that must happen is that the team themselves actually want to bring those improvements. It's not the Scrum Master's responsibility to ensure that it happens as much as it is the team themselves bringing it in as well.

A (5:01)

So one of the things that I think about when specifically considering the retrospective theater like you just talked about, which is kind of running the retrospective just to run it and then not really taking any actions. I'm thinking that one of the possible reasons for that is that we end up discussing a lot of things that are either completely outside the ownership of the team.

B (5:29)

Right.

A (5:29)

Like we can talk about it, but we can't do anything about it. That would be one possible reason. And then the second reason is that there's an expectation that Scrum Masters are the ones that need to solve all of the impediments. And I would be the first to say that yes, Scrum Masters should definitely solve impediments, but not be the only ones and definitely not to the point where they would remove the ownership of how the team works from the team. So when you think about that, how are you helping teams to realize that, yeah, some stuff is outside our control. We can list it, but let's not worry too much about it, we can raise it and so on, but there's not much we can do it. Let's pick something we can work on right now. How do you help teams acknowledge that and maybe even exercise their ownership muscle? Maybe we could call it that way.

B (6:26)

Well, ownership muscle is a great way of doing it. I'm going to take that away with me. So going back to your point, we're talking about escalations, right? If the team have an improvement or a problem that they need solving that sits outside of the team that is beyond their capability, then it's either leadership level or it's another team that is, that is impeding, then, then the problem isn't the fact that the team can't solve it. The problem is that there is no system in place for them to be able to escalate it, for them to be able to make it visible on, on another board or another leadership team. Part of the operation. Not, not a, you know, something that people come up with in the retrospective and then just sits on a Miro board. We need to make sure that it is, it is taken upon us. And this is, this is all about having one, one collective ownership spirit, contra, where it's, it's not just the team, it's the leadership, it's the different product teams within a value stream. Perhaps everybody is pulling in one direction. I have a problem over here on this side. Hey, I've got the same problem over here on, on another side, right on my team. So let's, let's get together and let's try and collectively work through it.

A (7:55)

Okay, that's, that's a great tip to, to find some peers in pain and use that, that, that, that allegiance to foster some motivation and energy.

B (8:12)

All right?

A (8:12)

But we do all of this because we want teams to succeed. But before we can do that, we need to define what is our role in that. So Steve, how do you define success for yourself as a Scrum Master?

B (8:27)

Well, I think this is one of the big problems that has been for many years is actually being able to not just define success, but be able to really shout it. To be able to shout it from the rooftops. Like I, I have done some great things and this is how I measure it, right? This is. And something. That's a big gap. It's, you know, it's like we, we tell anecdotally, we give a good story potentially like in interviews or amongst our peers, but having sort of tangible evidence, being really know, being able to really highlight exactly how you've made an improvement. How you've transformed a team or an organization through measures. OkRS is an amazing way of being able to define that. OKRs historically are very poorly written and implemented usually in a dark room, right. With a, like head of, head of product in, you know, in a dark room, putting them together and then, and then cascading them downwards, you know, so you see some really poorly put together okrs. Actually. Okrs need to be done collectively with, with the team, with stakeholders, with you end users even. And we focus on the pain. Like what's the problem that you have right now? What's the, what are the big pain points that you as a customer or an end user or a stakeholder, what, what is the problem that you're having? And we make our objective the, that the goal to be able to solve that problem. That's our objective. And how we measure that. Well, that's, that's, that's something that we, we can define. And, and if we are all bought into that as Scrum master, engineers, products, product owner, stakeholders, leaders, everybody's aligned to that, then we're all pulling in the same direction. And you know, you make it visible on the wall and you see how you're progressing from your, you know, from being able to sort of showcase exactly how the team are getting on at any one time, make it live. Then as a Scrum master, as an agile coach, you have some clear metrics of the impact that you have had because the work that you do and it all come together, right? The delivery, the value, everything should be focused on customer as an endpoint. And then you've got something really tangible to be able to stand up and tangibly say, look, this is the difference that I've made as a, as a, you know, as an actual.

A (11:17)

How do you go about selecting the metrics? Like one of the things that very often happens that, okay, I could use many, right, like, so what, what do you do like when you're helping someone to think through this? Like, what are the metrics that matter? What are the metrics that I should focus on also to guide my own reflection? Because metrics are input, they are information, they are feedback. How do you help people select what metrics and what aspects to focus on?

B (11:45)

Yeah, so there's obviously the difference between KPIs and OKRs and they get merged.

A (11:54)

The fact that we have those two viable at the same time is in itself already an anti pattern. But again, that's another episode, of course.

B (12:02)

Absolutely. Yeah, we could certainly get into that. KPIs are hugely valuable, but they get misused. But in terms of metrics, it's really a case of progress. So we want to see where we are today. So it's safe, for example, that the problem that we have is that there are too many steps to check out for our customers. Like we're on a website, for example, an E commerce website. There's too many steps to check out. So our objective is to reduce the pain for our users to be able to check out at pace. And the metric to that would be reduce the number of clicks. Right. So that would be a key measure, a key result. And so you want to understand, well, what is it like today? What's the measure? How many steps does it take today? Let's say there's 15 steps to check out. So that's our baseline measure. And then you would set out, well, what do we want to bring it down to? Well, we want to get it down to. Let's be realistic within the next three months, a quarter, let's go by quarters. What can we realistic, realistically achieve in that time? We're going to reduce it down to five clicks. Okay. So at any one time we'll be able to see a bit like a speedometer on a car. You'll be able to see exactly where the, where the, where the team are on the dial and whether they're actually improving and moving towards.

A (13:33)

We recently published an episode with Tom Gilb and Simon Holzapfeld where Tom specifically uses the speedometer metaphor. And one of the things that he talks about from his own work and his own experience is that when he talks to leaders about being specific about what they are trying to achieve and then how to measure it, he very often is faced with very fuzzy ideas, not really translatable into a measurement process. I think that that's a challenge that we need to acknowledge as grandmasters and agile coaches, that we need to be able to solve that for ourselves. We need to be able to be so specific about the work that we're doing that we can define a metric and a measurement process to assess where we are in as you use the metaphor on that speedometer. Right. And I think this is so important because otherwise we fall for simple to get yet meaningless metrics like velocity.

B (14:42)

Yeah, yeah. And also targets, completely misunderstood as well. They usually come from above. It's like we want to increase sales by 10%. That's, that's a wish, by the way. From above. It's a wish, of course, Totally a wish.

A (15:01)

Right. I want to increase sales is a wish, because there's no way you can translate that. Now. You need to figure out, okay, but how, how does sales happen? And how do we measure the factors that contribute to the sales? And, and once we realize that, then we can start thinking, can we even affect any of those factors that lead up to the sales numbers? Because if we don't have that level of conversation, it's going to be very hard to decide even what to do.

B (15:30)

Yeah, well, there's so many contributing factors, and NPS is a great one. You always hear we want to increase our NPS score. There's so many contributing factors that the team cannot control. They have no.

A (15:45)

Yeah, we need to find what we can control first, then we can work on it.

B (15:50)

Exactly. And that's where we bring in the customers, the end users, and we work with them to understand their pain. And then we start from there. Awesome.

A (16:00)

Thank you for sharing that, Steve.

B (16:03)

No problem.

A (16:06)

All right, I hope you like 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 Key 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 Pioneer 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. 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.