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 customers 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 two 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 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 of a bit of a checklist of patterns that people should probably at least have a look at first when working with a new Scrum Master.

Yeah, sure. I was lucky enough to have you and Jeff, 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, that's 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 into a Scrum Master class course. Right. A one, two 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 context actually is probably a better word context about what they were. But do you think in hindsight going onto a course for two 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 two 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 burn down 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 to get has high value. So 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, and they're not really at a coaching level yet, 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 burn down charts. 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 burn down chart, I've found that because we're running three or four 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.

So 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 there's 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 the 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. And they will typically, if we said maybe it's a five, but they will start breaking those stories down to five by default and really identifying when there's a three and when there's an eight. 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. 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 three different stories, then I have to buy a cake.

Oh, wow.

Yeah, there's been some cheating on.

I was going to say no collusion. Right.

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. I've broken a few.

Racketeering about. Yeah.

But yeah, it's those conversations. So it's gold if somebody has a 20 and the other person has a five.

Right.

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 eight sitting in progress for a whole sprint.

Right.

But then we'll sort of tackle that during backlog grooming and say, come on guys, you gave it an eight. It's taken three weeks. What's going on? And that'll start another group of conversations. It's like how do we break the 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 as 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 it's a very small team. So there's only four 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 and 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 fix 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 in the lot. And so for me, it's about an initial exploratory bunch of sessions with the team where we work through some concepts, get to 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 the manifesto, not the manifesto. There's a really good document.

On scrum.org, which is a Scrum Master Guide. It explains to a Scrum Master what Scrum Master about. And some of that.

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

So something for them to read 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 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, 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, 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 sheet. So yeah, for me that's. I think you know that using the course as a reinforcement, if the course is.

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.

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 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, struggling with this idea of how much is up front because as I say to the new teams I engage with now, in the past I used to do a two, three 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 two days, it was intensive and probably the content was so rich now that I probably needed to extend it to three. But that bootcamp, they came away brain dead, right? It was, it was a lot. And we still had to go back and reinforce it with sub mod, you know, little one hour, two hour kind of interactive modules together. Not modules, because it wasn't. I didn't treat the. Those ones as training, but more conversations.

Yeah.

So then I kind of said, well, actually maybe it's. It's just in time, right? Should we be going through just in time? I worry that, you know, then we don't actually have the big picture for them. And especially when it's a new Scrum Master.

Right.

Somebody who 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 behaviours that don't align with what you're trying to teach, then, you know, 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. 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 are putting, 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 going to refine it again. Right. They're going to 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, you know, from the side.

Yep.

And it's a great way from them to Practice. Because, you know, going in as a Scrum Master with a team on day one is hard. You know, it's hard. You don't get to practice.

Yeah.

The other one we're kind of experimenting with at the moment is.

How do we. How do we get this Scrum Master to start leading? Right. That. That coaching or that helping the team without them being. Been 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. Pick 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, I've said to the new Scrum Master, you go find a retrospective game.

Yeah.

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 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 got support from me as the 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 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 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, yeah.

If you took a. If there was a different scenario. So, for example, say you had another team and this person got bought on as their Scrum Master, but 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 speak? Right. What would you do?

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.

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.

So I don't know.

Doesn't 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 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 just to get us going. And 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.

And 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 this dirty agile teams. Right. So that person is more of a coach than they are. That's the Scrum Master for the team.

So often the person will come in to the team and they haven't done it before and I'm not there full time showing, 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'll be a good way of testing who's going to be a Scrum Master and who's not.

It's. They have to have the passion. They really want to have to do that job because that role. Because it's hard. They have to do lots of learning. It's not easy.

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. It must fail at some stage.

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 in to my role, product ownership was a little bit of a little task that was tagged onto 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.

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 is either an absent product owner or a product owner'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 the 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, I think the thing to look. 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.

The ones if we set the conversation up that the rookie Scrum Master. I like that term, rookie. That again, 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, the team are helping the rookie come up to speed. But as the Scrum Master, what we're saying to them is the first stages come up to speed, understand the terminology, understand the way the team's working, get up 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, improve the way they work next. So if we couch it with that, accelerate up to your 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 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 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 serving leader. Right. A Scrum Master should never say they're doing it wrong. They should just help the team learn. It may be a better way of doing it.

According to page five of the manual, you are not doing this right. Yeah, they'll just spit the person out.

So the key thing then 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, so don't come back and say the book says come back and say, hey, on the course. We talked about this. We don't quite see you guys working that way.

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, 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 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, so I think it's about almost.

Yeah. And it'd be a really good idea if we sort of, 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, you draw that matrix, at least we've got a frame there that people can understand a conversation they need to start and that not all things are equal. That's pretty. I hadn't thought about it that way.

Because you could have swim lanes for what training. Whether it's coaching by coming in to the organization, whether it's, you know, do you do your two, two 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, and also about co location. So you know, depending on, depending on.

That matrix, the agile coach or the incumbent Scrum master, there is times where actually you pretty much have to be co located. You can't treat it as a one hour remote session because it's just not going to work. 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 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 I can never reply as soon as I'm free, or 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. There's that I'll wait till you're here next time.

And is like, no, no, buddy, we've got a deadline on this. Or velocity goes to. To a standstill and you start looking for those BAU sort of tasks that are adding no value, but you're comfortable in your own skin doing them.

Yep. 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 Helia, 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.

Well, I did that. I did that and it was 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's those sort of conversations I found really, 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 mentor or buddy system's just, it's gold.

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 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 that space, and having a conversation with up front saying, you know, you still be coaching, you still be training and you still be experienced 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, you can reach out to them. I don't know.

But yeah, but even, you know, taking the pattern that you've got, also talking to the Scrum Masters pastor cooey 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% of their time to go outside the organization and find, find that community. Right? Find that.

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. It's not a conscious thing, right? 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 them to have time to go outside the organization. If there's not a strong agile kind of cohort in that organisation 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 the weaknesses or the development opportunities within that whole team.

Yeah. Understand the context. 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. To go off on its own and build wonderful BI products.

Yeah.

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 become the incubator team. As long as, you know, they're not training them to behave badly.

Oh, yeah, that could turn.

Yeah.

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 larger organization with multiple teams, it 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 core, but we've identified if you want agile business you have to make the first move.

Yeah. And look, it's the businesses responsibility to make a call on what the value is and provide product owners that are committed. But I still think in our roles we need to help them understand what that means and how they can make that happen. So 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 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.

Actually it'll be great to find another experienced product owner to get another perspective on what, what annoys them about the delivery team and the squad.

Let me flip it around. What makes their day wonderful?

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

Yeah, we all love social experiments.

Excellent. Right, Well, I think, 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 alignments. 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 resources, please go to agilebi guru.