B (3:14)

Absolutely. And definitely. I'll put the link in the show notes, so please do send the link so I can direct people towards those approaches. I do have one question, though. So I'm sure that many of our listeners, and definitely myself, I have been in my share of teams where some people just don't want to take playful formats seriously.

C (3:36)

Absolutely.

B (3:37)

Like Lego Serious Play. What have you found works for you when you do find that there's someone in the audience or even several someones that just kind of, I wouldn't say refuse, but choose not to engage with the playful formats?

C (3:55)

Yes. I usually, by the time I've introduced something like this, I've already thrown so much neuroscience and psychology at the team that they sort of understand that I have ulterior motives for this. But if I am coming into something, if I haven't had a lot of time with the team and they're not quite sure what to expect from me and I pull Lego out, I can see on their faces, Lego. I didn't come. I'm here to work. I don't want to play, I don't want to do these things. And so as soon as I get. Get that kind of a reaction, I stop and I explain the science. I start talking about creativity. I start explaining of how we all have all these different ego states or personalities, and our most powerful learning states are our playful states. I start talking about how in order to learn something really effectively, we have to get a dopamine hit. And if we want to get a dopamine hit, we need to be doing something that's novel or that's something that Makes us laugh or something that even makes us smile. Those are the three key things. Novelty, laugh or smile. That will trigger a dopamine release. In order to save a new memory, we have to have a dopamine release. So I talk about all of the science and I go through all this and I say the reason we're doing a playful approach is because I want you to learn more effectively, because I want you to be thinking at your most creative, because I want you to be doing this. There's an ulterior motive. I'm not just doing fun for the sake of fun. I'm doing fun because we need to learn something more effectively here.

B (5:14)

Yeah.

C (5:14)

And by the time I've said all that, everybody's saying, okay, at least I'll play along. Yeah, maybe I'm still not going to enjoy it, but I'm going to play along.

B (5:22)

My own experience is that some of the most skeptics are those that enjoy it the most because they actually decide to give it a try rather than just follow the format. But of course, we can't always get to that level. And I think that introducing the science behind some of these retrospective formats is definitely going to tackle at least those who consider themselves logical and rational regarding others. We might need to try something else.

C (5:50)

Well, the key is always to know your audience. And when we are working in our space, we typically are our audience are IT people. And IT people pride themselves on being logical and rational. So I throw a lot of neuroscience at let's talk science.

B (6:05)

Yeah, absolutely. So, of course we run these retrospectives because we want to help teams succeed and we want ourselves as Scrum Masters to succeed. So, Mike, in your own experience, what defines success for Scrum Masters?

C (6:22)

Well, really, it's that if the team is successful, the Scrum Master is successful. That's really ultimately what's going on, because the Scrum Master is a catalyst changing things around them, enabling the team to get better. We're not measuring the Scrum Master on individual accomplishment. We're measuring them on the effect they had on the team. So if the team is more effective, the Scrum Master was more effective. And the things that I am primarily looking for is, is the team effective at delivering what it is they need to be delivering and are they getting better over time? So those are the two things I'm really looking for. One is, short term, are we effective? Are we actually getting stuff done? Or are we just being busy and not being effective at all? Which I do see a lot of times that we're very, very Busy, but we didn't actually get anything delivered to our customer. So are we being effective and are we continuing to improve over time? Those are the two things that we're really looking for. And that's true for both a coach and for a Scrum Master. But if I specifically, in the context of Scrum Master, that's what I'm looking for. They are the catalyst that enables those other two things to happen.

B (7:24)

So when you focus on these aspects, how do you keep yourself accountable to this definition of success for yourself as a coach as well as a Scrum Master? Mike?

C (7:36)

Well, I'm always looking to see what changes can I see? And I need to have some kind of metrics to be able to see what's going on. So I do dig a lot into metrics as well. I'll pull data out of their ticketing system. I'll look. I might look at DORA metrics. I might talk to the customers. I might get a sense of, you know, are we actually successful at delivering what we're doing? And have we been up till now? Because there's some way that we can show that we're noticeably better. Because if we don't actually look for indicators, then it's all too easy to say, oh, well, nothing changed. But if we look at the indicators and we say, well, look at the data, the data actually tells us a story. And when I say data, it doesn't have to be hard data, like raw numbers. It could be an experience talking to a customer. Yes, I'm much happier today than I was last month. You know, last month you delivered these things and that was okay, but right now you just delivered something much bigger, and I'm much happier about that. So it's all data, but some of it is very easily quantifiable. It's numbers, and other things are fuzzier, but it's still data. And that's what we're looking for. We're looking for data that backs up our argument that we are, in fact, getting better, that we are, in fact delivering what we need to our customers. And if we don't have some kind of data, then it's impossible to say whether we're better or worse.

B (8:51)

Yeah, not only that, but if we don't have data, whether it's qualitative or quantitative, if we don't have data, it's very hard to reflect on what has changed. Right?

C (9:02)

Yes.

B (9:03)

So when you think about this, like, let's say you go into a team, it's the first time you're with that team. You're really just, you know, trying to figure out what's their baseline.

C (9:12)

Right.

B (9:12)

Where do they start from? What kind of data do you usually start with?

C (9:18)

Well, I, again, I will pull things out of their ticketing system. I wrote a tool that extracts data out of jira. So as most of my clients use jira, if they are, I'll start there, I'll pull data out, I'll say, this is what we see, but the data doesn't tell us the story. The data tells us what happened, but not why. So we can look at the data out of their ticketing system and we can say, well, we see this pattern that we delivered a lot and then we didn't deliver much. And then we delivered a lot and we didn't deliver much. What does this mean to you? And the team will say, well, that's because we just got somebody new in the team, or that's because this was Christmas break, or that's because something else. And they can tell me the stories. All I have is raw data. The data tells me some numbers, tells me what happened, but it doesn't tell me why. And so as I start to review this with the team, they'll tell me the stories that back it all up. But we need to make sure that we don't get too trapped into stories because if we're just looking at the stories week to week, all kinds of times, I'll say to a team this week it looks like we didn't deliver as much and they'll come up with a really plausible explanation of, well, this is a one off situation and it'll never happen again. Except next week we have another one off situation that'll never happen again that looked just like the previous one. And the week after that we'll have another one off situation. So I'm looking for patterns. So we do want, I do want to hear the stories, but at the same time, the stories, we can't trust the stories too much because all too often they obscure patterns. And I'm looking for that pattern.

B (10:45)

So this is really cool because what I heard you say is, okay, I'll look at the data and try to see if I can find some patterns and then I will work with the team to understand the context of where that data comes from. Maybe there are some systemic causes for breaks in delivery, right? Like, oh, I remember a team that had five validation steps, right? The team was done, done, done, but there were still four validation steps after the team was done, done, done in order to get something into production. Which of Course delayed delivery into production. But without digging into the story, we would never get that information out because, you know, when we come in, we're just working with the team. We don't see all of the other things that happen in other departments that we might not even have access to.

C (11:33)

That reminds me of another situation about data. I came into one team and I noticed on one day the way their board was laid out was that every other column was something in their control and all the other columns were something out of their control. So there'd be a column where they would do something and then a column where another team, they were a services team that were doing things for other. And so every other column was out of their control. And I came in one day and I noticed that every piece of work on their board was in a column that was out of their control. And I just, I commented on it. I notice in your data that nothing here is in your control. And then I walked away and I came back a couple of days later and I noticed that it was the reverse. Every piece of work that was on the board was in a column that was in their control. And again, I commented on it. I said, hey, I'm noticing the last time I was in, everything was out of your control and today everything's in your control. What's different? Well, I don't know. All I know is what the data tells me, but the data doesn't tell me why. So I started asking them questions and they said to me, well, as soon as you pointed that out, we hadn't really paid attention to it. But as soon as you pointed that out, we started being more proactive. We started going and chasing after people. We started making calls. Earlier we started doing follow up. Earlier we started doing all these things and now we went from a situation where nothing was in our control to a situation where everything's in our control. And it was all because I started asking them, why is the data like this? Tell me the story behind what's going on. And then they figured it all out.

B (13:01)

Yeah. And that's a very powerful question. Just asking, why is the data like this? Because that triggers all kinds of questions in people's minds. Of course they will immediately become curious as well. Oh yeah, why is it like that? And then take action. That was a beautiful story. Thank you for sharing that, Mike.

C (13:19)

Are you welcome?

A (13:25)

Part of a successful Scrum master job is to help the product owner. Tomorrow we explore that critical role in Scrum. The product owner role. Tune in to learn about product owner anti patterns. What you can do to help the product owner and a real life example of what a great product owner is and what made it so. Tomorrow on our Friday Product Owner episode. 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.