Tips for a New Scrum Master – Blair Tempero

May 8, 2019 | AgileData Podcast, Podcast

Join Shane and Blair as they chat about tips for up skilling a new scrum master

Recommended Books

Podcast Transcript

Read along you will

Shane Gibson: Hi, I’m Shane Gibson.

Blair Tempero: And I’m Blair Tempero.

Shane Gibson: And today, Blair, and I are on our own for our first chat between us. First podcast, 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 on 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 board on a new person that they need to train up and coach as a Scrum Master for the team. And so we can’t assume that 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 then get a certificate and make them learn? Which we all know the answer is no, there might be a good start, but it’s certainly not the whole part of the journey. And so as I was thinking about what do we need to do? What are the patterns that we can apply to help this person grow? I caught us off earlier about years and years ago, when you first started as a thrown in the deep end of “Congratulations, Blair, you’re the new Scrum Master”.

Blair Tempero: Fill your boots.

Shane Gibson: Fill your boots. So when your boots. So Ray is thinking about what things did you try when you’re coached on what things worked, what things didn’t. And from there, maybe we can come up at the end with bit a checklist of patterns that people should probably at least have a look at first, when working with a new Scrum Master.

Blair Tempero: I was lucky enough to have you and Jeff, on my journey. And I think the first lesson I learned was, 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 that certain time in the morning and bringing their ‘A’ game as well as getting them on time. Being the energy of the team was really important. Even if things are going to cost it, I just found that you had to be the one that brought that team up to that other level to that next level. So really, the ceremonies and the energy were the two big things I picked up first.

Shane Gibson: So we will look at what you did though. So the natural behavior has to go into a Scrum Master course. One, or two days course which for me still has a lot of value, because as you mentioned, it helps the new people understand some of the terms. What’s a retro, what’s a stand up? Why don’t 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? I think we ran some workshops, we explained some concepts. And they were a little short, kind of intros to the terms and a little bit of a framework or description context, actually has probably been a word context about what they were. But do you think in hindsight going on to a course for two days to give you those to begin with was the right thing to do?

Blair Tempero: Yes and no. I was lucky enough that we did have that interaction with Jeff 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 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 is a person is way more important. So you get the right person into the gig. You get the right support. So that could be a course but we were so spoiled. Have you guys in there that? I think that’s the ultimate model to follow if you if you’re able to. I think if you were to do a course it will be the technical stuff, how to run a burn down sheet, how to build user stories, how to size a card, how to size a story, that sort of thing.

Shane Gibson: For me, when I find is having the Scrum Master and the team learn that together 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 iteration or sprint is where the value is as the value of the conversation. So I kind of worried 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 their course.

Blair Tempero: And with the burn down chart, I’ve found that because we’re running three or four Sprint’s at the same time, it’s quite an overhead in terms of admin and I might be kicking myself and 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 running into trouble because people have started to burn out.

Shane Gibson: So I don’t think there’s a problem removing that mechanism, if you think it’s not adding value. I’ve listened to a podcast the other day about no estimates. So is this whole discussion, 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 started 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 the head. 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 these are three and when these are ain’t. And they start naturally doing that. So the overhead of actually storyboarding has minimal value now, because that team’s naturally doing it. Of course, if you broke the team and borders new people, then you’d probably have to go back and maybe with velocity, same thing for you. You have a team, they’re a mature team, they’ve had the velocity, a warning sign where you can help them kind of wobbles. But if you split that team and create a two teams out of them, you pretty much would need to go back to managing velocity via either data.

Blair Tempero: 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 that as well. So if the whole team scores the same points for three different stories, and I have to buy a cake. There’s been some cheating.

Shane Gibson: No collusion.

Blair Tempero: And you get these really interesting conversations like that developers will say to a tester. So how hard is it? And there’s code and then I’ve broken a few racketeering event, 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 compensations. And we’ve gone past that 90 points is all we can deliver in a sprint was sort of getting used to under estimating is probably the big thing. We’ll have an eight 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 EIGHT. That’s taken three weeks, what what’s going on?” And then we’ll start another group of conversations. It’s like, how do we break the story down? It’s obviously been sitting there for so long. So when that comes up, and retrospectives as well as we’ve got to get better at actually sizing the stories.

Shane Gibson: 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 one of the ones I’ve got at the moment is very small team. So this is 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-Schools conversation yet. So they unconsciously know about that needs to be reinforced. So there was an example where one of the team members had to exit the sprint for some 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’s a whole conversation coming up about what’s the definition of done. And we had to find what definition of done was, but it hasn’t been reinforced because inflight story sitting and 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. 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 their 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 they’re saying, 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 idea of Scrum Master Training was kind of a kind of a combination. So what, what we do when we work together and what I see happening online. And so for me, it’s about an initial exploratory bunch of sessions with a team where we work through some concepts and get to the team to this level where they understand the words thinking maybe that the Scrum Master should agree to the Scrum Master Guide, rather should not read the manifesto. There’s a really good document on, which is Scrum Master Guide explains to a Scrum Master what Scrum Master is been.

Blair Tempero: I’ve got my trainee looking at that.

Shane Gibson: 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 after a little period of time, then they go on the course. Because now what they’re doing is going in understanding the concepts and really starting to put the pieces together. And the course, they will pretty much ask the hard questions. Now, the better I don’t know is whether the course can handle that. What somebody said to me when I was looking around and saying, if we’re going to see in the Scrum Master role for training, where do they go? They said, don’t worry so much about the course or they’re all pretty much the same kind of course, the same kind of content, really worried about who’s taking it, that you want a person that’s been there, done that, and then can bring those stories and answer those questions, not just run through the training sheet. So for me, using the course as a reinforcement, if the course is there.

Blair Tempero: Because there’s some activities that were, and I’ll go over a few of them that we found really valuable with you guys. 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. But don’t be that guy. Such a great concept and quite simple actually, and itself managed. So just briefly 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 the ability to help when it’s required. Don’t just do your own tasks. And on the other side, talk over people and always late for meetings and find excuses, that sort of thing. I found that just gold.

Shane Gibson: 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 see the scene and then point people back to it, or do we wait to we start seeing some of the behaviors in the team to grave 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 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 Bootcamp and that was a combination of agile also talks about Scrum and Lean and Kanban talks about agile teams and agile ceremonies and disciplines and ways of working. And that was a full day and then the second day was more around patterns that use the data and analytics, you’re doing agile. But there two days that was intensive, probably the content was so rich now that I probably need to extend it to three. But that bootcamp, they came away brain dead. It was a lot. And then we still had to go back and reinforce that might be a little one hour, two hour interactive modules together, not modules, because it wasn’t. I didn’t treat those ones as training, but more conversations. So then I said, actually, maybe just in time. Should we be going through just in time, then we don’t actually don’t have the big picture for them. And especially when it’s a new Scrum Master, somebody hasn’t done it before, then they need to be one step ahead of that team until they’re understanding what we do next. So what do you think? Should we have the Bootcamp for the team and the Scrum Master and then kickoff 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?

Blair Tempero: That’s good question. We went through the Bootcamp type scenario, and I found that really, really useful. So I’d probably go with everything the way that I learned everything. And that’s all upfront. Reinforce, once you see the type of behaviors that don’t align with what you’re trying to teach them, quickly stamp them out. 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. They haven’t said 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 with the team, because you really want that as a social contract?

Shane Gibson: You guys are a little team. Typically, I would say, my natural reaction to say “No”. 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 behaving certain ways and how they got there. And they’re called social contract with the team members, that’s where the value is. So the other team members have been through it. But shorter shit, they’re going to refine it again. They’re going to start. Because we probably as a team, we haven’t gone back and looked at our this person, that person, and we’ve seen some new behaviors turn up that we never thought about that we kind of want to hear encourage or squash. So I actually say, go back and figure out a way of refining the conversation so that the 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 is a bit of a stretch.

Blair Tempero: Well, that would work.

Shane Gibson: But actually also the other way of looking at it as that’s a sign of success. Acceptance criteria for having a Scrum Master Coach to the level of self-sufficient as if they can run through the team when a new person turns up. It’s kind of a nice safe environment for them. 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 site. And it’s a great way from 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 we’re kind of experimenting with at the moment is, how do we, how do we get the Scrum Master to start leading that coaching or that team without them being at the front of stand up and being the project manager? How do we helped with that? And the one we’ve kind of picked on to experiment with is retrospectives. 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 obviously, to the new Scrum Master, you go find a retrospective game that you think is interesting. You do the research and learn their game, and then you run the next retrospective of the team using the game. So it’s small time in the water, you’re completely on your own. You’re doing all the research and you’re running this session. You 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 we get the value of the retrospective itself out of that hour. So we’re gonna go try that this week and see how it goes.

Blair Tempero: That’s brilliant. So I’m in a really good position where I’ve got a trainee Scrum Master, but 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 the planning sessions, retrospectives. He’s watched me run the team in the morning for 15 minutes. We’ve talked about it afterwards how everyone’s a bit flat in the morning that coffee might not have kicked in. It’s your job to get everyone picked up. Well, it’s a good role anyway. So now we can move into the retrospective some products heard about there.

Shane Gibson: So the bit of idea though, is that you’re the Scrum Master. So you’re helping the team as a Scrum Master. And this person is coming in and kind of next to you and learning by example. If there was a different scenario. So for example, say you had another team, and this person got brought on as a Scrum Master, but never done it before. And you didn’t have the capacity to be the Scrum Master for that team.

Blair Tempero: I’d struggle with that.

Shane Gibson: How would you get them up to speed? What would you do?

Blair Tempero: 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 there. I think that would be a terrible thing. It’s like throwing someone into the sea, isn’t it?

Shane Gibson: I don’t know.

Blair Tempero: I have to be the right person. I’m bit nervous.

Shane Gibson: 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, when I say to them as 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 has a role within the organization, that’s a way that you operate. It’s not something that you bring a contractor in for the whole time. If that’s a project behavior, not a way of working. So 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 30 agile teams. And so that person is more of a coach than they are a 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 do by example. But the point that you made was you’re dropping them in, and it’s kind of

Blair Tempero: Maybe, maybe harsh.

Shane Gibson: It’s harsh. But though we’re survival, they’re not.

Blair Tempero: To be a good way of firm testing, who’s going to be a Scrum Master and who’s not?

Shane Gibson: They have to have the passion, they really want to have to do that job. 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 over the right personality style, or they’re not. And that will come out really quickly here. But I suppose I’ve been lucky, because every time it’s happened to me the last few years that Scrum Masters always rocked it. I don’t know if that’s just luck or not. I think it probably is, but it worked. I mean, it must fail at some stage.

Blair Tempero: I think it also in that circumstance, where you 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 on to the end of somebody in the business’s role. So 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 and the backlog. So if you need somebody with a strong, agile background, out of those two roles.

Shane Gibson: That’s good point. So don’t drop a new Scrum Master into a team where there’s ever an absent product owner or a product owner is not experienced yet. But what about a strong team? So if you drop a Scrum Master into a team that’s mature, they pretty much going to tell the Scrum Master how to do the job? So would the person ever be able to accelerate where they become the serving leader, not the serving slave.

Blair Tempero: They’re difficult one. I think look at the errors there 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.

Shane Gibson: The ones that we cope if we see the conversation up there, the rookie Scrum Master. I’m getting really big on this idea of football and using the coaching analogy as just flowing in so many different ways. So when the rookie hits the field, the team 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, get understand the terminology, understand the way the teams working, get up to the level of the team. And then you need to look ahead, you need to start looking outside what the teams 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 catch up with that to accelerate up to your running at the same speed, and then figure out how to get in front of them and be ready to help them get be on 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.

Blair Tempero: So rookie Scrum Master coming into a mature development team, they’ve got their own way of working. The Scrum Master will be at a rookie, see something that he thinks or she thinks is fundamentally flawed or broken in the way that that teams working, you’ve got to be very careful how you deal with it. You can’t just say that’s crap, we need to do it this way. And that’s where I think the subtleties that I’ve learned and being the 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 the soft skills of a Scrum Master really come to the fore there.

Shane Gibson: And that’s why they call it a servant leader. As a Scrum Master should never say they’re doing it wrong, they should just help the team according maybe a better way of doing it.

Blair Tempero: According to page five of the manual, you are not doing this right. They’ll just split the person out.

Shane Gibson: 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 probably actually say, send them on the course at the beginning with a very clear conversation around the team doing Agile on their way. So don’t come back and say the boxes, come back and say, on the course we talked about this. We don’t quite see you guys working that way.

Blair Tempero: How’s your alternative way working for you?

Shane Gibson: 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. I mean, you can always be successful, but get there slightly faster and in a nicer way. We probably need a Product Owner Coach and 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 the focus may need to change depending on where the problems come from. If you’re walking in and you’ve got a strong Scrum Master already in place, then lead by example, is great. And you can probably live with some immaturity in the team or maturity in the product owner. Because there’s a safe pair of hands here full time pretty much for that conversation with them.

Blair Tempero: It would be 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.

Shane Gibson: So a bit of a matrix.

Blair Tempero: And then how you deal with those different scenarios?

Shane Gibson: I like that.

Blair Tempero: I mean, we’d have to hypothesize about it and get some examples going.

Shane Gibson: I think if we just draw the picture, in all that matrix, at least we’ve got a frame there that people can understand a conversation they need to start and not all things are equal. Now, that’s pretty good. I haven’t thought about it that way.

Blair Tempero: Because you could have swim lanes for work training, whether it’s coaching, by coming in to the organization, whether do your 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.

Shane Gibson: And also about co-location, so depending on that matrix, the Agile coach, or the incumbent Scrum Master, there’s times where 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 is 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. When I’m coaching a Scrum Master or an Agile Coach as part of the role within that organization, because you’re not the 100% of the time, they feel they’re interrupting you. And so that conversation about I’m here to coach you, I’m here when you need me. There’s a bunch of techniques about how they can get a hold of me. And if it’s urgent, there’s a way if it’s the top of their mind, and they just need to, to put it down, and then we can come and leave me. I can leave a reply as soon as I’m free, we can make a time to talk about it. The different techniques depending on the urgency of the question, but the naturally, I don’t know if it’s a kiwi thing or not.

Blair Tempero: We’ve got a deadline on this. But velocity goes to a standstill when you start looking for those BI use sort of tasks adding no value, but you’re comfortable in your own skin doing them.

Shane Gibson: So I think again, 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. Having an experienced product owner that’s available for the new ones to just have a coffee and ask those dumb more uncomfortable questions. I think the same is whether with a rookie Scrum Master is even if it’s not in that organization, as well as the coach, the person that is helping them I think, forming a buddy system where there is another Scrum Master that they can have a coffee with.

Blair Tempero: Well, I did that. And it was okay. 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 there’s those sorts of conversations I’ve found really, really valuable. And 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 now having the mentor or buddy systems just that goal.

Shane Gibson: It has nothing to say at the moment I see. Well, it’s not people who have people they can call on but some people don’t and especially if they’re moving into their Scrum Master role from scratch or if they’re becoming 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 Meetup’s, look at the different things in their space and having a conversation with upfront saying, used to be coaching, you used to be training and you said the experience on the job, but actually because There’s 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 meet up or work out with your pastoral career 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.

Blair Tempero: And the model could be too. If you’re bringing a mentor in for coach, the coach sort of sessions is to build, if you’re negotiating with them for their time, just maybe have a few more hours, build all that you can, you can reach out to them.

Shane Gibson: Even taking the pet in the you’ve got also talking to the Scrum Masters, person recruiting manager, and the person that looks after them and their time, their commitment to the role, you’re 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 that community.

Blair Tempero: Absolutely. And we all know that we’ve got that 5%.

Shane Gibson: You’re lucky but most organizations I work with, it’s not a conscious thing.

Blair Tempero: It’s not a new development plan.

Shane Gibson: No.

Blair Tempero: It’s not real, unless it’s in the era. So it could be just words.

Shane Gibson: So what I just kind of closing it out there. I think we kind of talked about is, 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 we can learn by example. But that’s not possible, then actually we need some way of understanding where the materials and all the gear roles, or the players or the parts of that affects the way we kind of engage. And when the Scrum Master will go and 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, and then organization, as a percentage of the time to give them somebody to talk to. We need some way of helping them feel that they can safely ask questions anytime they need to and they’re not. They have that because they’re learning. Anything else we covered?

Blair Tempero: No, I think that the key thing is the maturity of the different actors and the actual process, if you can know that sort of customizes how you’re going to deal with, the weaknesses, or the development opportunities within that whole team.

Shane Gibson: Understand the context it’s important. But create a pattern where you can really identify the areas and an approach of how you bring that person on the journey based on the context that currently exists. And, of course, change it when the context changes. So if you walk in and you have an experience product owner, and then for some reason, the team pick up some work, and then the experienced product owner comes in, you probably want to change a little bit about how you’re approaching this.

Blair Tempero: That’s right. So you’ve got to identify where that call it the weakest link has caught up with the rest of the chain. So when do you let go? When do you say that this team is ready to go off on its own and build wonderful BI products without your interference?

Shane Gibson: 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 we actually become the incubator team as long as you’re not training them to behave badly. But you have a natural team. They get love incubating or mentoring the new Scrum Masters to build their capability and thought about that. That’s actually if you’re a large organization with multiple teams, and maybe somebody that you consciously want to do.

Blair Tempero: So we’ve identified that our weakest link is product ownership. We’ve been doing Scrum Mastering and BI development for a number years now. But we haven’t poured the time and effort into getting product owners just feet. We’ve always thought that that’s the business’s core. But we’ve identified if you want agile business, you’d have to make the first move.

Shane Gibson: Look, it’s a business’s responsibility to make a core on what the value is and provide product owners that are committed. But I still think as is in our roles, we need to help them understand what their means and how they can make that happen. So we do need to have a coaching role and coaching business users on what product ownership means. And what’s the commitment and how do we take them on their journey. I think some stage in the future will bring back in, have a chat on product ownership part two. What do you need to do? What’s the checklist to coach a product owner?

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

Shane Gibson: It shall be great to find another experienced product owner to get another perspective on what annoys him about the delivery team and

Blair Tempero: Flip it around and what makes the day wonderful.

Shane Gibson: It’ll be volatile, but exciting podcast.

Blair Tempero: We all have social experiments.

Shane Gibson: Excellent. 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 we’ll catch you next time.

Blair Tempero: Catch you next time.


PODCAST OUTRO:  You have been listening to another podcast from Blair and Shane, where we discuss all things AgileBI. For more podcasts and resources, please go to