AgileData #5 - Tips for a New Scrum Master

Welcome to the Agile BI Podcast, where we chat with guests or sometimes just to ourselves about being agile with teams who are delivering data analytics and visualizations. Hi, I'm Shane Gibson.

Hi, I'm Blair Tempro.

And today Blair and I are on our own for our first chat between us, first podcast where we don't have a guest. And today the thing we're going to go through and talk about is the idea of what do you do when you have a new Scrum Master? So I'm working with a new customer and I'm coaching the team, the data team, around some stuff they want to build. And as part of that, the customer's brought on a new person that they need to train up and coach as a Scrum Master for the team. And so we're kind of sitting back going, hell, we have a new person, they need to become a Scrum Master. Do we just send them on a 2-day Scrum Master course and let them get a certificate and let them learn, which we all know the answer is no. It might be a good start, but it's certainly not the whole part of the journey. And so as I was thinking about, you know, what do we need to do, what are the patterns that we can apply to help this person grow, I kind of thought, Blair, about, you know, years and years ago when you first started.

Wow, yeah.

As a, you know, thrown in the deep end of, congratulations Blair, you're the new Scrum Master.

Fill your boots. Fill your boots.

So really just thinking about what things did you try, were you coached on, what things worked, what things didn't, and from there maybe we can come up in the end with a bit of a checklist of patterns that people should probably at least, you know, have a look at first when working with a new Scrum Master.

Yeah, sure. I was lucky enough to have you and Geoff on my journey, and I think the first lesson I learned was, you know, you've got to have regular ceremonies. So those are the patterns that you have to get in place first of all. You've got to get everybody used to meeting, you know, at that certain time in the morning and bringing their A-game. So as well as getting them on time, I guess Being the energy of the team was really important. So even if things are going to custard, I just found that you had to be the one that brought that team up to that other level or to that next level. Yeah, so really the ceremonies and the energy were the two big things I picked up first.

So when we look at what you did though, so the natural behavior is to go and do a Scrum Master course course, right, a 1-2 day course, which for me still has a lot of value because, as you mentioned, it helps the people, the new people understand some of the terms, right, you know, what's a retro, what's a stand-up, why do we refine things, and how often should we do it. But you didn't do that, you didn't actually go on a course to get started. So how did you find, you know, I think we ran some workshops, we explained some concepts, so they were a little short kind of intros to the terms and a little bit of a framework or a description of context, actually is probably a better word, context about what they were. But do you think in hindsight going on to a course for 2 days to give you those to begin with was the right thing to do?

Yes and no. I mean, I was lucky enough that we did have that interaction with Geoff and yourself, so I quickly picked up those terms. It didn't take long at all. I wasn't just coming in and reading a textbook, so to speak. So yeah, I guess like 2-day course learning the fundamentals wouldn't be a bad thing, but it's not the end of the world. I think the Scrum Master as a person is way more important, so you get the right person into the gig. You get the right support, so you know, that could be a course, but it's we were so spoiled to have you guys in there that I think that's the ultimate model to follow if you're able to. I think if you were to do a course, it would be the technical stuff, how to run a burndown sheet, how to build user stories, how to, you know, how to size a card, how to size a story, that sort of thing.

Yeah, and for me, what I find is having the Scrum Master and the team learn that together together has high value. Absolutely. So, you know, the idea of using poker points and doing some estimation of the stories to figure out what we can commit to in an iteration or a sprint is where the value is. It's the value of the conversation. So, I kind of worry that if it was only the Scrum Master going off and learning that, you know, and they're not really at a coaching level yet, they can't, they still don't know it enough to be able to teach or coach the team, that it starts getting done in isolation. But then I look at some of the stuff that I don't coach strongly on, like burndown charts.

Yeah.

It's not something that I strongly work towards, so there's probably a whole lot of other stuff that Scrum Master will pick up on that course.

Yeah, and with the burndown chart, I've found that because we're running 3 or 4 sprints at the same time, it's quite an overhead in terms of admin and And I might be kicking myself in the foot here, but I've kind of dropped out of that activity just for the sheer volume of the work that we're getting through. I can tell if we're not hitting velocity. I can tell if we're running into trouble because people are starting to burn out.

I'm sorry, I don't think there's a problem removing that mechanism if you think it's not adding value. I mean, I was listening to a podcast the other day about no estimates, so is this whole discussion, shall we call it, about should we be Story Pointing or should we not. And the kind of approach that I heard that I really liked was that we start off Story Pointing in the beginning with a team because it helps that team learn and talk and figure out what does a right size look like. But over time, a high-performing team, a mature team, will naturally Story Point in their head, right? They will naturally decompose the stories down to almost the same size. You know, and they will typically, you know, if we said, you know, maybe it's a 5, but they will start breaking those stories down to 5 by default and really identifying when there's a 3 and when there's an 8, right? And they start naturally doing that, so the overhead of actually story-pointing has minimal value now because that team's naturally doing it.

Yeah.

Of course, if you broke the team and brought in some new people, then you'd probably have to go back. And maybe with velocity, the same thing for you, right? You have a team, they're a mature team, they've hit their velocity, you know a warning sign where you can help them when it wobbles. But if you split that team and created two teams out of them, you pretty much would need to go back to managing velocity via the data.

Yeah, but that's one thing that I'm really staunch about is keeping the storytelling, or the sizing, even if that size is irrelevant. It is, as you touched on earlier, the conversations that you have. And we have a bit of fun with it as well. So, if the whole team scores the same points for 3 different stories, then I have to buy cake.

Oh, wow.

Yeah. There's been some cheating on the cake.

I was going to say, no collusion, right? Yeah.

And you get these really interesting conversations, like a developer will say to a tester, "So, how hard is it?" And there's code in there. So, I've broken a few. Racquet, racketeering about. Yeah. But yeah, it's those conversations. So it's gold if somebody has a 20 and the other person has a 5. One person completely doesn't understand the story, obviously. So you get those conversations.

Yeah.

And we've gone past the 90 points is all we can deliver in a sprint. Was sort of getting used to underestimating is probably the big thing. Like, we'll have an 8 sitting in progress for a whole sprint. But then we'll sort of tackle that during backlog grooming and say, come on guys, you gave it an 8, it's taken 3 weeks, what's going on? And that'll start another group of conversations. It's like, how do we break this story down? It's obviously an epic if it's been sitting there for so long. So, you know, and that comes up in retrospectives as well, is we've got to get better at actually sizing the stories.

Yeah, and for me it's about, often the agile coaching, it's about experience or having seen it before and then figuring out patterns that might help. So, you know, one of the ones I've got at the moment is a very small team, so there's only 4 in the team, So there's not a lot of excess capacity and not a lot— and there's great— they do actually have really good T-skills, but they haven't quite come along on the T-skills conversation yet. So they unconsciously know about it, but it needs to be reinforced. So there was an example where one of the team members had to exit the sprint for personal reasons for a period of time, and they had a bunch of stories that were waiting on that person, and they had those stories sitting in done. So there was a whole conversation coming up about What's the definition of done even? We had defined what definition of done was, but it hasn't been reinforced because an in-flight story sitting waiting for effort from another team member wasn't the definition. But the way the Scrum Master I'm working with fixed that was to, again, we talked about it and it was like, okay, so why can't another team member pick it up? I know that the person that's not there probably has the best skills to solve that problem, they probably have the best experience, but there's enough skills crossover across the team that somebody else could pick it up and finish it. So again, it's about that reinforcement, that saying, "Hey, I've seen this before." Maybe we have this type of conversation that the Scrum Master needs to accelerate and get better. So what my thoughts are around the The idea of Scrum Master training was kind of a combination of what we did when we worked together and what I see happening a lot. And so for me, it's about an initial exploratory bunch of sessions with the team where we work through some concepts. Yeah. Get the team to this level where they understand the words. Thinking maybe that the Scrum Master should read the scrum.org Scrum Master Guide, right? They should read some—

The manifesto?

Not the manifesto, there's a really good document on scrum.org, which is a Scrum Master Guide. Explains to a Scrum Master what Scrum Master about, some of that training.

Oh yes, I've got my trainee looking at that at the moment.

So, something for them to read, which should raise some questions. Then we cover off the questions briefly in a small period of time when they have them. And then, when they're, after a little period of time, then they go on the course, right? Because now what they're doing is going in, understanding the concepts, and really starting to put the pieces together. And then they'll, in that course, they'll pretty much ask the hard questions. Now, the bit I don't know is whether the course can handle that, right? What somebody said to me when I was looking around and saying, well, you know, if we're going to send a Scrum Master off for training, where do they go? They said don't worry so much about the course or, yeah, they're all pretty much the same kind of course, the same kind of content. Really worry about who's taking it.

Yeah.

You know, it's, you want a person that's been there, done that and can bring those stories and answer those questions, not just run through the training sheets. So, yep, for me that's, I think, you know, that using the course as a reinforcement if the course is up to date.

Yeah, because there's some activities that were— and I'll go over a few of them that we found really valuable with you guys and with us that I don't know that you can do without having the whole development team together. But you could actually just list them and sort of describe them in the course, I guess. But don't be that guy, be that guy. Yep, yep. Such a great concept and quite simple actually. And and it's self-managed, right? So just briefly, you describe all the traits that you don't want the team to exhibit, and that goes on "Don't be that guy." On the other side, you say, "Be that guy," and that will be things like listening skills, you know, the ability to help when it's required. Don't just do your own tasks. And on the On the other side, it's like talk over people and always late for meetings and finds excuses, that sort of thing. Found that just gold.

Yeah, and so, you know, one of the things I'm kind of working through now is when we use "don't be that person" and "be that person," do we do it early on with the team or do we wait? So, you know, do we put it right up front so we can set the scene and then point people back to it, or do we wait till we start seeing some of the behaviors in the team degrade where that type of conversation would help them get out of the problem, and then we introduce it at that time. So I'm still working through, struggling with this idea of how much is upfront, because as I say to the new teams I engage with now, you know, in the past I used to do a 2-3 day boot camp. And that was a combination of Agile, so it talks about Scrum and Lean and Kanban, talks about Agile teams and Agile ceremonies and disciplines and ways of working. And that was kind of a full day, and then the second day was more around patterns that you use for data and analytics when you're doing Agile. But that 2 days, it was intensive, and probably the content was so rich now that I probably need to extend it to 3. But that boot camp, they came away brain dead, right? It was a lot and we still then had to go back and reinforce it with submod, little 1-hour, 2-hour kind of interactive modules together. Not modules because I didn't treat those ones as training but more conversations. So then I kind of said, well, actually maybe it's just in time, right? Should we be going through just in time? I worry that then we don't actually don't have the big picture for them. And especially when it's a new Scrum Master, right, somebody hasn't done it before, then they need to be one step ahead of the team in terms of their understanding what we do next. So what do you think? Should we have the boot camp for the team and the Scrum Master and then kick off and then reinforce, or should we bring through the different things that are needed just in time and help the Scrum Master kind of understand what they are and where to go?

That's a good question. Like, we went through the boot camp type scenario and I found that really, really useful. So I'd probably go with everything that I— the way that I learned everything, and that's all up front, reinforce once you see the type of behaviors that don't align with what you're trying to teach, then quickly stamp them out. Yeah, I think so. So things like don't be that guy, you can sort of get them kicked off. My problem is when you get a new member into the team, they haven't signed up to that. Yeah. They haven't said that that behavior sucks and I'm not going to do it, I'm not going to stand for it. So what do you do? Do you go through that whole exercise again with the team? Because you really want that as a social contract, right?

Yeah, look, I— do you go through it with the whole team? Typically, I'd say, my natural reaction is say no, right? The cost of having the whole team go through that again, they've been there, done that. But then I look at it the other way and I go, the value of the new team member understanding why the team have behaving certain ways and how they got there and that social contract with their team members, that's where the value is. So yes, the other team members have been through it, but sure as shit they're gonna refine it again, right? They're gonna start, because we probably as a team, we haven't gone back and looked at our, this person, that person, right? And we've seen some new behaviors turn up that we never thought about that we kind of want to encourage or squash. So Yeah, I actually say, yeah, go back and figure out a way of refining the conversation so that they're more focused and slightly quicker than the first time because the team are reinforcing it. Be interesting to see whether the team could actually run each of those sessions themselves in a round-robin technique. That's a bit of a stretch. But actually—

wow, that looked great—

but actually also the other way of looking at it is that's a sign of success, right? An acceptance criteria for having a Scrum Master coach to the level that they're self-sufficient is if they can run through the team when a new person turns up. It's kind of a nice safe environment for them, right? Because they've got the team behind them, the team understand the concepts and why we do this, and then the new team member comes in and the Scrum Master is now leading from the side, and it's a great way for them to practice because going in as a Scrum Master with a team on day one is hard. You don't get to practice. The other one that we're kind of experimenting with at the moment is how do we get the Scrum Master to start leading, right, that coaching or that helping the team without them being at the front of stand-up and being the project manager, how do we help with that? And the one we've kind of picked on to experiment with is retrospectives, right? And picked that one because there's lots of cool games out there for retrospectives, where you can go and find different ways of running them. So what we're trialing is, as I've said to the new Scrum Master, you go find a retrospective game, that you think is interesting. You do the research and learn that game, and then you run the next retrospective with the team using that game. So it's a small toe in the water, right? You're completely on your own, you're doing all the research, and you're running that session. You've got support from me as a coach. I'll be in the room with you. We've actually tweaked the game a little bit based on where the team are. So making sure that, you we get the value of the retrospective itself out of that hour. Yeah, so we're going to go try that this week.

That's brilliant.

See how it goes.

Yeah, so I'm in a really good position where I've got a trainee Scrum Master that I'm getting up to speed, and you've just given me a great idea for his next development, and that is to run a retrospective. So I've slowly moved from He's been in the room for all of the ceremonies, all of the planning sessions, retrospectives. He's watched me run the team in the morning for the 15 minutes. We've talked about it afterwards, how everyone's a bit flat in the morning, the coffee might not have kicked in. It's your job to get everyone perked up. Well, it's a good role anyway. So now we can move into the retrospectives. Retrospective, so I'm quite excited about that.

So the benefit there though is that you're running, you're the Scrum Master, so you're helping the team as the Scrum Master, and this person's coming in kind of next to you and learning by example.

Yeah, that's right.

If you took a, if there was a different scenario, so for example, say you had another team and this person got brought on as their Scrum Master, they'd never done it before, and you didn't have the capacity to be the Scrum Master for that team?

I'd struggle with that.

How would you get him up to speed, right? What would you do?

I mean— We would have to find some serious time together to build that sort of fundamental backlog of knowledge. I probably would have to look for a course.

Yeah.

I probably wouldn't want to drop him into that. I think that would be a terrible thing. I mean, it's like throwing someone into the sea, isn't it? It'll be just, yeah.

Ah, so, I don't know.

It would have to be the right person. I'd be nervous.

So, you know what, I mean, I've seen this happen a couple of times now with customers I've worked with, and part of the reason is, is when I go coaching a customer, what I say to them is, I will never be the Scrum Master. I might start off helping with the ceremonies, right, just to get us going and in the interim until you identify a Scrum Master. I always recommend that the Scrum Master is a role within the organization. It's a way that you operate. It's not something that you bring a contractor in for the whole time because that's a project behavior, not a way of working. Typically, an organization won't have a permanent Scrum Master, or actually, the ones I've worked with where they do, they have one permanent Scrum Master and dirty agile teams, right? So that person's more of a coach than they are the Scrum Master for the team. So often the person will come into the team and they haven't done it before, and I'm not there full-time showing, you know, so they can learn by example. But the point that you made was you're dropping them in and it's kind of Maybe, maybe harsh, but yeah. It's harsh, but they'll either survive or they won't.

It would be a good way of testing who's going to be a Scrum Master and who's not.

They have to have the passion, they really want to have to do that job, that role, because it's hard. They have to do lots of learning. Yeah. You know, it's not easy. Yeah, they have to be empowered, and if they're not empowered by the team or by the organization, then it just won't work, and that's important to know. Not fear on them, but it's better to know that that's going to happen or not happen as soon as possible. And they're either the right personality style or they're not, and that will come out really quickly. But I suppose I've been lucky because most, you know, every time it's happened to me over the last few years, that Scrum Master's always rocked it. And I don't know if that's just luck or not. I think it probably is, but It's worked, right? So I'm like, it works. I mean, it must fail at some stage, but—

Yeah, it must do. I think it also, in that circumstance where you are sort of putting a novice into the role of Scrum Master, then the role of Product Owner probably has to be reinforced. Because when I came into my role, product ownership was a little bit of a little task that was tagged on to the end of somebody in the business's role. So it was, okay, I'm nominating you to be Product Owner, go and hang out with these guys, do your best. You don't need to lead, you just need to sit there and, you know, and take some feedback back to the business or have a guess on what comes next in the backlog. So I think if, you know, you need someone with a strong Agile background out of those two roles.

Yeah, that's a good point. So don't drop a new Scrum Master into a team where there's either an absent Product Owner or a Product Owner that's not experienced.

Yeah, or a proxy.

But what about a strong team, right? So if you drop a Scrum Master into a team that's mature, they're pretty much going to tell the Scrum Master how to do their job.

Yep.

Right, and so would the person ever be able to accelerate where they become the Servant Leader, not the Servant Slave?

Yeah, that would be a difficult one.

Or, you know, yeah, is that going to—

Yeah, I think the thing to look at there is, has the team designed their own best fit for what they're doing. So they're not taking agile advice from the Scrum Master. They've decided how it's all done. So I wouldn't want to drop a rookie in that's got a couple of days training under his belt and sees that everything is wrong according to the textbook and starts forcing that on the team.

But once we set the conversation up that the rookie Scrum Master— I like that term, rookie, I'm getting really big on this idea of football and using the coaching analogy, it's just flowing in so many different ways. So when the rookie hits the field, you know, the team are helping the rookie come up to speed, but as the Scrum Master, what we're saying to them is the first stage is come up to speed, understand the terminology, understand the way the team's working, get up to speed, to the level of the team, and then you need to look ahead, right? You need to start looking outside what the team are doing to the greater wide world, find things that will help the team accelerate, find ways of having conversations with the team about what they're going to do to improve the way they work next. So if we couch it with that, you know, accelerate up to you're running at the same speed and then figure out how to get in front of them and and be ready to help them get better in the way they're working, it's almost a two-stage process and we should be able to say, you know, that's what success criteria is.

Yep. So a rookie Scrum Master coming into a mature development team, they've got their own way of working, the Scrum Master, albeit a rookie, sees something that he thinks is, or she thinks is fundamentally flawed or broken in the way that that team's working. You've got to be very careful how you deal with that. You can't just say, "Nah, that's crap. We need to do it this way." And that's where I think that the subtleties that I've learned in being a Scrum Master need to come in. You need to suggest rather than command. You need to offer those alternative ways of doing it and selling the benefits of that. So it's You know, the soft skills of a Scrum Master really come to the fore there.

And that's why they're called a servant leader, right? The Scrum Master should never say they're doing it wrong. They should just help the team learn that there may be a better way of doing it.

According to page 5 of the manual, you are not doing this right.

Yeah.

They'll just spit the person out.

So the key thing then is, is when you have a new Scrum Master coming in, it's often about the context of what they're walking into. So if they're walking into a mature team with a mature Product Owner, then the way that they engage and learn and focus has to be different. So in that scenario, I'd probably actually say send them on the course at the beginning with a very clear conversation around the team doing Agile in their way. So don't come back and say, "The book says," right? Come back and say, "Hey, you know, on the course we talked about this. We don't quite see you guys working that way." Yeah.

How's your alternative way working for you?

Yep, and then you can do it that way, and then the whole goal of that is to accelerate the Scrum Master up to the same maturity as a team and then help them get ahead. Figure out how to help the team in the future. If we're walking into an organization where there's a rookie Product Owner, a rookie team, and a rookie Scrum Master, the more and more I'm coming back to actually we need multiple coaches to be successful, to be safe, right? I mean, you can always be successful, but to get there slightly faster and in a nicer way, We probably need a Product Owner coach, an Agile coach, and a Scrum Master coach for periods of time to help each of those teams or those roles kind of become the best they can be. And that may need to, the focus may need to change depending on where the problems come from.

Absolutely.

If you're walking in and you've got, you know, a strong Scrum Master already in place, then the learn by example, right, is great and you can probably live with some immaturity in the team or immaturity in the product owner because there's a safe pair of hands there full-time pretty much for that conversation with them. So yeah, I think it's about almost a balance.

Yeah, and it'd be a really good idea if we sort of name these use cases where rookie Scrum Master, mature team, rookie product owner versus Mature product owner, mature team, rookie.

Yeah, so a bit of a matrix.

And then how you deal with those different scenarios.

Yeah, I like that.

I mean, we'd have to, you know, hypothesize about it and get some examples going.

Well, I think if we just draw the picture, draw that matrix, at least we've got a frame there that people can understand the conversation they need to start.

Yeah.

And that not all things are equal. That's pretty cool. I hadn't thought about it that way.

Because you could have swim lanes for what training, whether it's coaching by coming into the organization, whether it's, you know, do you do your 2-day course, whether you need a mature Scrum Master in there for a duration of time, whether you need the Product Owner to be coached as well on the job. I mean, yeah.

And also about co-location, so, you know, depending depending on that matrix, the Agile Coach or the incumbent Scrum Master, there are times where actually you pretty much have to be co-located. You can't treat it as a 1-hour remote session because it's just not going to work, right? The person's going to be left on their own and there's no feedback. And that's one that I'm finding interesting at the moment. Is a lot of the coaching I'm doing now is starting to be remote. And it takes a while for the, for that, you know, when I'm coaching a Scrum Master or an Agile Coach as part of the role within that organization, because you're not there 100% of the time, they feel like they're interrupting you, right? And so that conversation about, actually, I'm here to coach you, I'm here when you need me, I have a bunch of techniques about how they can get a hold of me. If it's urgent, there's a way. If it's top of their mind and they just need to put it down and then we can come and even, you know, I can even reply as soon as I'm free or, you know, we can make a time to talk about it. There's different techniques depending on the urgency of the question.

But then naturally, I don't know if it's a Kiwi thing or not, is that, "Oh, I'll wait till you're here next time." It's like, no, no, buddy, we've got a deadline on this, or velocity goes to a standstill and you start looking for those BAUs, sort of tasks that are adding no value, but you're comfortable in your own skin doing them.

Yeah, so I think again, you know, with new Scrum Masters, it's making sure they have that lifeline. So we talked a while ago, I think it was earlier, we talked about the idea of Product Owner Mentors, right? Having an experienced Product Owner that's available for the new ones to just have a coffee and ask those dumb or uncomfortable questions. I think the same is with a rookie Scrum Master, is that even if it's not in that organization, as well as the coach, the person that's helping them, I think forming a buddy system where there is another Scrum Master that they can have a coffee with and be safe.

Well, I did that. I did that.

Okay.

Yeah, so I met with my mentor and it was purely, it wasn't sort of like every week, it was if I came across a problem, it might be something that he's come across before that he can help me with, or maybe it's not a problem and just go with the flow. So it was those sort of conversations I found really valuable.

Yeah.

And, you know, some of them, some of the answers I got were just, you might just have to let it break before it gets fixed. And it's like, okay, how do I do that? But no, having the, the mentor or buddy system's just, it's gold.

And it's not something I see at the moment. I see, well, it's not, you know, people have people they can call on, but some people don't. And especially if they're moving into that Scrum Master role from from scratch, right, if they're becoming, you know, coming in at blank, they probably don't understand the network. So maybe part of that is encouraging the rookie scrum masters to look at the meetups, look at the different things in their space, and having a conversation with them upfront saying, you know, you used to be coaching, you used to be training, and you used to have experience on the job, but actually because this is a whole new role for you, like anything when you change what you do, you need to invest. You probably need to invest some of your time in the meetup or work out with your pastoral care manager on how you're going to manage that. But you need to find that network and plumb in to help you on your journey.

And the model could be to, you know, if you're bringing a mentor in for coach-to-coach sort of sessions, is to build, you know, if you're negotiating with them for their time just to maybe have a few more hours billable that you can reach out to them. I don't know, but—

Yeah, but even taking the pattern that you've got, also talking to the Scrum Master's pastrikuri manager, the person that looks after them and their time, their commitment to the role, saying actually as part of them coming into that role, you need to give them 5% or 10% or 5% 5% of their time to go outside the organization and find that community, right?

Absolutely. And we all know that we've got that 5% and—

Yeah, you're lucky, but most organizations I work with, it's not a conscious thing. It's not conscious.

It's not a new development plan.

No, no.

It's not real unless it's in there, I kind of think. So it could be just Just words.

Right, so what I just kind of closing it out there, what I think we kind of talked about is, you know, bringing on a rookie Scrum Master who's working with a team is hard. Ideally, there'll be an incumbent Scrum Master there and we can learn by example.

Check.

But the most, you know, if that's not possible, then actually we need some way of understanding where the maturity of all the roles or the players or the parts of that are, and that affects the way we kind of engage and when the Scrum Master will go on training in terms of early versus middle. We need to kind of negotiate then to have time to go outside the organization if there's not a strong Agile kind of cohort in that organization as a percentage of their time to give them somebody to talk to. We need some way of helping them feel that they can safely ask questions at any time they need to, and they're not, you know, and they have that right because they're learning. Is there anything else we covered?

No, I think the key thing is the maturity of the different actors in the actual process. If you can nail that, that sort of customizes how you're going to deal with, you know, the weaknesses or the development opportunities within that whole team.

Yeah, understand the context.

The context.

Which is always important. But yeah, create a pattern where you can really identify the areas and kind of an approach of how you bring that person on the journey based on the context that that currently exists, and of course change it when the context changes.

That's right.

So, you know, if you walk in and you have an inexperienced Product Owner, and then, you know, for some reason the team pick up some work and an experienced Product Owner comes in, you probably want to change a little bit about how you're approaching this.

That's right. So you've got to identify where that, I'll call it the weakest link, has caught up with the rest of the the chain. So it's when do you let go, when do you say that this team's ready to, you know, to go off on its own and build wonderful BI products without your interference.

And what you might end up, if you're running multiple teams, you might end up having a mature team that loves mentoring new Scrum Masters. So actually, they become the incubator team. As long as, you know, they're not training them to behave badly.

Oh yeah, that could tend to— Yeah, that could go a bit to the head.

But yeah, you have a natural team that love incubating or mentoring the new Scrum Masters to build their capability. Yeah, I hadn't thought about that. That's actually, if you're a large organization with multiple teams, that may be something that you consciously want to do.

Yeah, and so we've identified that our weakest link is product ownership. We've been doing Scrum Mastering and BI development for a number of years now, but we haven't poured the time and effort into getting product owners up to speed. We've always thought that that's the business's call, but we've identified if you want agile business, you have to make the first move.

Yeah, and look, it's the business's responsibility to make a call on what the value is and provide product owners that are committed, but I still think as in our roles, we need to help them understand what that means and how they can make that happen. So, you know, we do need to have a coaching role in coaching business users on what product ownership means, and what's the commitment, and how do we take them on that journey, and I think at some stage in the future, we'll bring Helio back and have a chat on product ownership part 2. What do you need to do? What's the checklist to coach a product owner?

And what annoys you the most as a product owner from a team and a Scrum Master?

Yeah, actually, it'll be great to find another experienced product owner to get another perspective on what annoys them. About the delivery team and the squad last night.

Well, let me flip it around. What makes your day wonderful?

Oh, I'm happy with a glass half empty. It'll be a volatile but exciting podcast.

Yeah, we all love social experiments.

We do indeed.

Excellent.

Right. Well, I think we're done time-wise and I think we're pretty much done content-wise, which is always a good thing when those two align. So yeah, catch you next time.

Catch you next time. You've been listening to another podcast from Blair and Shane, where we discuss all things agile BI. For more podcasts and resources, please go to agilebi.guru.