Vasco Duarte (4:11)

Yeah. And one of the things. Of course you draw comics so you're probably attuned to the importance of visual thinking. But one of the things that I really like about this metaphor based retrospectives, you know, whether it's sailboat or climbing up the mountain or whatever you want to call it, it unlocks some sort of creativity that isn't there otherwise. And that's one of the things that, I mean, many of us work in it, are engineers or have an engineering background. And we're very concrete thinkers. Probably many of us are very pragmatic by nature, but the training we go through makes us very concrete thinkers. It makes it hard to think abstractly and the metaphors kind of unlock that aspect. And I often see teams are happier, they're more creative, they're more interactive. When they're using a. Do you see the same.

Robert Finnan (5:04)

Yes. It's good to get them going. But I mean, I will also, I have to admit, I'm not a great. You know, I believe retros. We're trying to do something concrete and rec. I want an improvement at the end of the retro. In the end of the day, it always boils down to the same thing that we're looking at, what's going on and what's not. So I will invest a little bit into that. But. And, but I don't want it to become a novelty that every two weeks I'm trying to think of something madly exciting. And so I go to the sailboat every week and I think it's important to vary it a little bit, but I do. I, I'm not, I've. I'm not going to go in and ask them to build a LEGO model of last week's Sprint. That's. But that's just my type of. Maybe this is. I want to get them talking, but I feel like I can generally get them talking. You might have noticed, I can get them talking anyway.

Vasco Duarte (5:54)

I think that the get them talking is part of it. But I'm also thinking that we very often are. And I'm a student of philosophy, or I should say I'm a curious of philosophy, not really a student, I should be honest with that. But I am interested and I explore this. And we even have a couple of episodes on the podcast about philosophy applied to our role as scrum masters and agile coaches. And one of the key things for me from that curiosity about philosophy that has come out is the importance of the mental models and the languages we use. And for me, the sailboat is about switching the language. It's about switching the language from the things we can name to the things we can relate. And the relate part is very important, right, Because I can relate something to a rock or a shark or the sun or the island that I would not come up with if I'm thinking about the exact actions that happened in the last sprint. What do you think about that, Robert?

Robert Finnan (6:50)

No, no, I agree there. I think that it's useful sometimes to put it to this context switch or this, this visualized reframing of things in a different. In a different kind of different words that then you're kind of surprised by what comes out afterwards. And they start to use the words that. They start to use the words that you're using for the metaphor. So whatever that might be, whether it's sailing, there's a hole in the boat, or, you know, our anchor is massive, our, you know, we need a bigger sail, whatever it Might be that those rocks are massive, whatever it's going to be. And they. And it becomes, you know, they, using the imagery that you put up there, starts to become the words that they're using to convey their thinking and they'll.

Vasco Duarte (7:27)

Even refer to that in the future.

Robert Finnan (7:29)

Right.

Vasco Duarte (7:29)

Oh, remember that rock?

Robert Finnan (7:32)

It hit us. There's a hole in the boat. We're going down.

Vasco Duarte (7:36)

Yeah. And that becomes kind of powerful because it conveys so much information in so little or in so few words. Right. Because it has all the whole background of the visual metaphor that we were using before. But that was a tangent.

Robert Finnan (7:50)

Freeze people. Yeah, yeah. Frees people up a bit in their thinking. Yeah, absolutely.

Vasco Duarte (7:55)

Obviously, we do all of this because we want teams to succeed, and that also means we succeed as Scrum Masters. So, Robert, let's explore that a little bit. When you think about your success as a Scrum Master, what does it mean for you?

Robert Finnan (8:09)

So I think I mentioned this in the previous episode that I sort of see myself when I'm a Scrum. So I see myself coming as a Scrum Master. I see myself a little bit like the product owner of team improvements.

Vasco Duarte (8:21)

This is.

Robert Finnan (8:21)

This is sort of in my visualization. So quite often if I'm asked to come in now, sometimes I'll come in a team has been running for a while. Sometimes you're starting a team up. Okay. In different situations. But in general I would have a backlog of what I would consider to be improvements in my head. Or sometimes it's a physical one where I literally have it in Excel sheet or something like that. Just a. Just to keep a track in it are written down in my notebook basically where I think, okay, here, this change, we need to bring this in because I think this is going to have the most effect on our performance. So if we say that a Scrum Master is accountable for high performing teams or the effectiveness of the high performing teams, like what change? If I can make one change, what's this one change I would like to see happen that I think would bring the greatest step forward? Now, I'm a fan of focusing on one or two things, so work in process limits. Okay? One or two things at a time. So when I'm considering improvement, what's actually happened? Generally speaking, I have something that I'm aiming towards them seeing. Are we actually getting there or not getting there. For instance, I have gone into teams where they were completely against estimation. Estimation is a waste of time. Okay. I could see though that they weren't delivering on any of their sprints. There was no predictability about when something would be finished. Okay, so I'm looking, I'm a fan of estimation because generally speaking I want to know we're going to hit this deadline, this release date or not. That's why we're doing this actually less so than you might think about getting it right between two or three points. Can we deliver this on time for the company or not? And this is the kind of thing where, you know, I'll go, we really need to get this sorted out now. There's several steps maybe to get that estimation done. I had to do is, you know, basically give them a grounding in what Scrum and Agile actually is. Quite often that's missing. Surprising how many people have never had any kind of training about Scrum or Agile. Don't understand why we work this way and then trying to get them to experiment, can we do a few weeks drop where we actually do some estimation and stuff like that. And in the end, at the end what they call success, success was about four or five sprints later where they used to print out the burn down chart and leave it on my desk. They'd say look, we got it, you know, we got it done. We're, you know. And also what we were able to do with that, we were able to, we had two or three teams working on a bigger project. We were able to do a release burn down across the three teams and take a look at it and start descoping if needs be really early, way earlier than not. Not like at the last minute going oh, we're not going to be able to deliver that. We would just keep scoping way earlier saying we're not going to make this, we can make it, maybe we can add something to it or not. So I've, so how do I judge the improvement? There's things I see and there's things I put emphasis on. I am hoping to see those things change now. Sometimes it is, it's not always something as concrete. Maybe it's estimation, it may be the atmosphere in meetings, it may be about the way they talk to each other. It may be about the kind of finger pointing that might be going on or something that, where you think, oh we've got a, you know, we have a trust issue here. I'm going to have to work at a much lower level or on the personal level rather than let's say on the practice level which can also be the case. So this is how I would, you know, I'd be looking for, looking, looking to see what's happening. And the other thing maybe to add to that is I love it when I don't. So if I'm sitting there and I'm thinking something like, stop putting stories in Sprint. You're not going to finish it. And then they say it and then I go, ah, we're getting to the point where, you know, the mind, it's great to be the agile conscience, but it's great when you don't have to be the agile conscience anymore. Okay.

Vasco Duarte (12:06)

Yeah. When it's already inside of their own thinking. Right.

Robert Finnan (12:10)

Mentally, these are the wins when they say something like that. But like I had like the developer saying, no more. We don't do any more than that. I'm not going internally. I'm just going, yes, yes. And then there was another time, another time, the product that not the stakeholders said to each other they wanted to bring in some. Some kind of something like electronic signature. And they said, oh, so we're not going to be able to. We're not going to be able. Or we're not going to be able to do XYZ because we want to bring electronics. No, no, no, no. We've got to decide whether we do this and if we do, we can't do the other. We have to swap things out. We can't. And I was like, oh, God, yes, thank God we have capacity. And they're the bits where I go, ah, there's the mindset. I didn't have to say anything. They're the, they're the win.

Vasco Duarte (12:56)

Those are the big wins. I totally agree.

Robert Finnan (12:59)

I had some guys recently do magic estimation and I looked at them do the magic. I was helping them and I looked at them and said, guys, you really think you're going to deliver this? Yeah, yeah, yeah, yeah, we'll be okay. We'll be okay. We'll get it done. They didn't. Okay. And then I heard they went and did magic estimation for the next set of features they should release and immediately realized they weren't going to make it and they were going to scope some stuff. And that for me is a win when I wasn't even there. But they went and did it on their own. And I think, great, you're spreading the virus of thinking like this, basically, and people are going, oh, we need to.

Vasco Duarte (13:32)

They're the kind of things when the ideas live on their own. I think that's a great way to. Yeah, yeah.

Robert Finnan (13:37)

That's a lovely way of seeing it. Yeah, yeah.

Vasco Duarte (13:39)

Awesome. Thank you for sharing that, Robert. 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.