Making Scrum Master Success Visible with OKRs That Actually Work | Steve Martin

Summary

Podcast Summary

Overview

Podcast: Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Episode Title: Making Scrum Master Success Visible with OKRs That Actually Work
Guest: Steve Martin
Host: Vasco Duarte
Date: January 1, 2026

This episode centers on how Scrum Masters can make their impact measurable and visible by leveraging effective Objectives and Key Results (OKRs). The discussion covers the pitfalls of "retrospective theater," fostering true ownership of improvements within teams, practical metrics selection, and democratizing OKRs to reflect actual customer pain points and team input.

---

Key Discussion Points and Insights

1. Retrospective Formats: Beyond the Session Itself

• Steve Martin shares that he does not have a single favorite retrospective format, emphasizing the importance of keeping things fresh to maintain team engagement. More crucial, he says, is what happens after the retrospective.
• Post-retro action and ownership: Steve advises making improvements concrete by transforming them into user stories that are tracked, actioned during the sprint, and even demoed at the end. This ensures accountability and visible progress.
  • Quote: “It is not the retrospective, that is the success of the retrospective. It is the ownership and accountability where you take improvements after the session, bring them into the sprint…” (02:14)

2. Avoiding Retrospective Theater

• Problem Identified: Teams often conduct retrospectives for the sake of process, leading to little real change ("retrospective theater").
• Two main culprits:
  • Focusing on issues outside the team’s control
  • Expectation that only Scrum Masters solve all impediments
  • Vasco frames the risk as: “We end up discussing a lot of things that are either completely outside the ownership of the team.” (05:01)
• Steve’s Tips:
  • Focus on items the team can own and move forward.
  • Promote collective, not just individual, ownership.
  • Foster systems for escalation beyond the team (e.g., visible boards, leadership engagement).

3. Building the “Ownership Muscle”

• Escalation systems: It’s not a failure if teams can’t solve everything themselves. The real failure is not having a mechanism to make impediments visible and escalate them.
  • Quote: “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…” (06:26)
• Allyship: Find allies in other teams who share similar pain points to gain motivation and collective problem-solving power.
  • Memorable Phrase: “Find some peers in pain and use that allegiance to foster motivation and energy.” (07:55)

4. Defining Scrum Master Success

• The Visibility Problem: According to Steve, the major challenge is making one's impact as a Scrum Master “shoutable” and tangible.
  • Quote: “Being able to really highlight exactly how you’ve made an improvement… through measures. OKRs is an amazing way of being able to define that.” (08:27)
• Danger of Poorly Crafted OKRs: OKRs often fail because they're written in isolation and imposed top-down. Instead, Steve advocates co-creation with all stakeholders—including end users—to address real pain points.

5. Making OKRs Work

• Ground OKRs in Real Problems: Objectives should emerge from genuine customer or user pain, with key results directly reflecting efforts to solve those pains.
• Visibility and Alignment: Make progress visible (“put it on the wall”) so the team and stakeholders can always see their status “like a speedometer.”
• Collective Buy-In: If everyone is involved—from engineers to stakeholders—there’s alignment and shared accountability.

6. Choosing the Right Metrics

• Distinguish KPIs from OKRs: KPIs and OKRs often get conflated. KPIs are ongoing health metrics, while OKRs are about focused progress.
  • Quote (Steve): “KPIs are hugely valuable, but they get misused. In terms of metrics, it’s really a case of progress.” (12:02)
• Concrete Example: Reducing e-commerce checkout steps.
  • Baseline: “How many steps does it take today?” (e.g., 15)
  • Objective: Reduce customer friction.
  • Key Result: Bring checkout steps down to a realistic number (e.g., 5 within a quarter).
  • Metaphor: Track progress on a “speedometer” for clarity and motivation (13:33).

7. Dangers of Wishful Metrics

• Beware of “Wishes” from Leadership: Targets like “increase sales by 10%” are wishes, not actionable objectives.
• Find What the Team Controls: Teams need to identify what they can affect and measure specifically.
  • Vasco: “I want to increase sales is a wish… now you need to figure out how does sales happen and how do we measure the factors that contribute.”
  • Steve: “There’s so many contributing factors that the team cannot control.”
• Customer-Centric Metrics: Work backward from the customer’s pain, involve them to identify actionable metrics.

---

Notable Quotes and Memorable Moments

• On Retrospectives and Action:
  “It is not the retrospective that is the success… it is the ownership and accountability where you take improvements after the session…” (Steve, 02:14)
• On Ownership Muscle:
  “The problem isn’t… the team can’t solve it. The problem is there’s no system in place… to escalate it, for them to make it visible…” (Steve, 06:26)
• On Scrum Master Impact:
  “Being able to really highlight exactly how you’ve made an improvement… through measures. OKRs is an amazing way of being able to define that.” (Steve, 08:27)
• On Wishful Metrics:
  “We want to increase sales by 10%. That’s a wish, by the way. From above. It’s a wish, of course. Totally a wish.” (Steve, 14:42)
• On Metric Selection:
  “The key again is ownership and it’s collective ownership… It’s not just the single owner. Just because your name is on the ticket, the team have the ownership of that improvement.” (Steve, 03:57)

---

Timestamps for Key Segments

• Retrospective philosophy and post-retro action: 01:40–03:43
• Avoiding retrospective theater and fostering team ownership: 05:01–07:55
• Systems for escalation and collective ownership: 06:26–07:55
• Defining and making success visible as Scrum Master: 08:27–11:17
• Building effective, actionable OKRs: 11:45–13:33
• Dangers of wishful leadership metrics and actionable targets: 14:42–15:50

---

Summary and Takeaways

• Success for Scrum Masters comes from enabling real improvement, not just facilitating meetings.
• Ownership of change must be collective and visible, supported by systems for action and escalation.
• Effective OKRs are developed collaboratively, focused on actual pain points, and provide tangible measures of progress.
• Teams should orient metrics on what they can control and avoid “wishful thinking” objectives.
• Making progress visible—like a speedometer—helps teams, leaders, and Scrum Masters see real, customer-centric results.

This episode is a practical, actionable guide for Scrum Masters seeking to move beyond process compliance to genuine, visible impact through well-crafted OKRs and empowered teams.

Transcript

[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 success Thursday, the big question of the week, this week with Steve Martin. Hey, Steve, welcome back.

[B]

Let's go. Thank you. Well, thank you for having me back. It's been a wonderful week.

[A]

It's been a blast. It's been a blast. And there's still two episodes to go. All right, let's dive into this. We'll talk about success in a minute, Steve, but first, share with us what's your favorite agile retrospective format and why?

[B]

You know, Vasco, I don't have a single Fabio. Obviously it's very, very helpful and valuable to be keeping the energy of the retrospective, to be adapting it and changing it often so that your teams are not getting bored with the same format. But for me, I think the key is brought is broader. To ensure a successful retrospective is to focus on not just the retrospective, but the after part of the retrospective. What do you mean by that happens after? And I always tell my mentees, well, I always tell my mentees that it is not the retrospective, that is the success of the retrospective. It is, that is the ownership and accountability where you take improvements after the session, bring them into the sprint so that you get ownership of that. In fact, make it a user story even, right? So that you've got, this is the problem, this is how we're going to solve it and this is how we're going to measure the impact and you then have that all the way through your sprint and at the end of the sprint even have even bring it into the demo so you have accountability so that the person who has the ownership of solving the Problem is on the hook for bringing it into the demo and showcasing what improvement has been made so that the team can see exactly how they're improving. They're seeing the results in terms of measures. But there's real continuous, there's a culture of continuous improvement. So it doesn't just become theater retrospective. We just go through the motions. We do Easter retrospective with eggs for post it notes and all sorts, which are fun, but we need to really think about how do we make sure that we take those improvements and implement them.

[A]

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]

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]

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]

Right.

[A]

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]

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]

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]

All right?

[A]

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]

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]

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]

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

[A]

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]

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]

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]

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]

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]

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]

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

[B]

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]

Thank you for sharing that, Steve.

[B]

No problem.

[A]

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 [e-mail] 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.