Lindsay Velecina: 0:03

Welcome to the scrum.org community podcast, a podcast from the home of Scrum. In this podcast we feature professional scrum trainers and other scrum practitioners sharing their stories and experiences to help learn from the experience of others. This episode is a previous recording of our live ask professional scrum trainer series, where a live audience asks questions of professional scrum trainers. We hope you enjoy this episode.

Eric Naiburg: 0:30

Good morning. Good afternoon. Good evening, depending on where you might be in the world. Thank you for joining today's webinar. Or today's Ask a PST and I'm My name is Eric neighbor. I'll be your host today as I am the CEO of scrum.org, and run marketing and operations and different pieces. And I'm joined today by one of our professional scrum trainers, Steven Dinair. And Stephen joins us from Belgium today. And is going to take your hardest and most difficult questions and hopefully try to answer them to the best that he can. Just briefly. Oh, some quick guidelines, your microphones will be muted. The session will be recorded and will be available within the next 24 hours or so up on our website. If you want to revisit it. If you have friends, you want to point to it and so on. If you have questions, please use the q&a button. You'll see that on your panel. And we're all very familiar with Zoom these days. So just use that q&a panel to ask your questions. And we'll go through those and take them the best we can. So briefly, excuse me, who is scrum.org scrum.org is a mission based organization and focused on helping people in teams solve complex problems. were founded by CO creator of Scrum, Ken swaybar, who's our chairman. And as I said, founder and we focus kind of in three areas. We do training, we do certification, and continued ongoing learning. There's 1000s of free resources, blogs, many blogs from Stephen, for example, videos, webinars like this and other things that are available on our website to continue that ongoing learning and hope helping you to keep growing as you get more experience and as you need more. So with that. I will turn it over to Steven for him to introduce himself briefly. And then we'll start taking your questions.

Steven Deneir: 2:34

Cool. Thanks, Eric. So yeah, Steven from today Sunny Belgium. And contrast to the to the previous days, it was raining like crazy. My background in scrum dates since 2001. Where there was not so much available of information available in my region. So I did some sidetracks in project management, which also helped me to learn a lot why Scrum is helping us so good initiatives compared to other frameworks or methodologies. In the back, you'll see my biggest hobby, which is Lego. And for the rest time, I'm looking forward to get all your questions and get started with it.

Eric Naiburg: 3:19

Perfect, so I think we're ready to get started. We've got some questions already starting to come in. And please like I said, type your type your questions in that q&a box as you have any and we're happy to take them as they come. So the first question Fabio asks, Can you describe a bit about how the an architect on a scrum team would work with the rest of the team? How are they involved? Can you talk a bit about architecture and how that fits and how an architect can can bring value to the team?

Steven Deneir: 3:53

Yeah, that's a good question. I see it happening quite a lot in companies that that the role stays what it isn't as it was in the past. For me or he texture is a skill just as as any other skill like software development, software testing, analyzing designing. So for me, I would hope that the architect is open to share his skills, knowledge, insights with the other colleagues so that they can learn from him or her. And vice versa that the architect is open to learn other skills from from the team. So he's not only limited anymore to architecture, but can also for example, help with with validations. With reviewing with testing with analyzing more, because it's a key skill. It's really a key skill. And only depending on one person would be quite a risk in a team I would expect especially if you are scaling Scrum and you have multiple teams even going on and you only have one architect as part of one specific team. This skill should certainly be be taken up by audit also This is answer Fabio, do you have follow on questions on that one?

Eric Naiburg: 5:06

If you do, please feel free to, to add those to the q&a, excuse me to the q&a and, and Steven will will take that. And we'll continue to go through. So next question. How do you deal with projects? In Scrum? How do you handle? We, we talked about a product mindset, we talk about products, but people often still think in that context of project, how's that handled? Yeah, yeah,

Steven Deneir: 5:35

I'm currently facing that, in fact, with my current customers who had my main customer, the main question I always ask to, to people coming in with that with that point is, first of all, is this project as they call it, addressing one specific product? And if that is the case, I typically advise people to put that question that challenge that opportunity, which they call project as a big item, or maybe a smaller item and their product backlog. And as such, it becomes an item that can be further investigated, further refined, and as such the product improved step by step through means of what they currently call projects. Fair enough. On the other hand, sometimes the question arises yet that is covering multiple products, in fact. And so my follow up question to these people who say, our project discovering multiple products is aren't really separate products, then because very often I see an artificial split and, and companies, they say, Hey, but we have, we have the front end of our solution, you have the back end of our solution, we have this team on end. And in fact, these people don't receive separate projects, it should be one big product. So in that case, I advise the organization to put that request in this specific product backlog of their products. In that way, they just start managing it as as product requests. And sometimes there are very hard dependencies. And then I advise the product owners to align with with one another and to see how they can improve their product to answer the overall request of the organization or of customers. So a lot of different ways of tackling projects in a scrum context. Always think about focus on products, please, and see how these requests then come in the in the product backlog of the different products or if it's only one that's even easier.

Eric Naiburg: 7:51

Right, thanks, dude. Next question, what are your suggestions for convincing management of the value of enabling the scrum team by providing all the required skills within the scrum team? Is it clearly communicated? But but the response is almost always that lack of capacity, lack of time lack of people? So how do you get management to buy into the need that the scrum team needs to be enabled to have all the skills required to deliver?

Steven Deneir: 8:28

Yeah, yeah, it's a big pitfall for me, and they tell adoptions that it's for me it's a timing aspect if an organization is not open to free up time and free up is maybe not the correct word, but, but to allow people to learn and to grow, they will stay in accordance with their within their current mindset and they will hardly ever benefit from the advantages scrum can bring convincing people is very hard, if they have a certain mindset, a certain a certain meta model in their mind. So, what I tried to do with these people is to create together with them system systems model, what is a systems model? It's a model showing what parameters attributes are linked to one another, making the situation what it is today. And very often for example, if people are not multi skilled or teams are not cross cross skilled, what you will see in such a model the relationship with it if you for example, push more skills or less skills and such a model is that dependencies will raise or lower depending on the push you give to the skills and giving more or less dependencies will impact time to delivery will impact quality to deliver and if they see if they meaning man increment of management sees how the model the system, their system model functions in their own context, they can start understanding that their mental model about skills and giving people time to learn new skills, how that is impacting what they actually want. And typically, actually, what I want, in my experience is is time quality. And by learning, we can show that in that model, if we push more learning, people are more cross skilled teams are more cross functional, that in fact, it has in the end a positive advantage on what they are looking for. Now, of course, that is in time, that will not happen tomorrow, they need to have some patience, to see the effects of it. And so I tried to do it in that way, make it very visible what their situation is through a systems model, and then influencing which parameters give a positive impact on what they are looking for.

Eric Naiburg: 11:03

Awesome. Thank you, Steven, I think there's kind of a bit of a follow on question here for one of our other attendees, but I think it ties well to where you are going, which is. In this case, they're rolling out Scrum. And they're using it in their team within an it actually a development organization, or development team of software. And they're looking at growing scrum beyond that to other areas within it and and outside of it in the organization. But people do not have the time right to to learn the time to start experimenting with Scrum. So kind of tied to what you were just talking about. How would you approach this? How would you get people to understand that that Scrum is about helping deliver value in? How would you? How would you take that on?

Steven Deneir: 11:58

Yeah, so even in my first chats with such an order with any organization that is contacting me to help them out. My first question is, why? Why are you reaching out to me for implementing Scrum? And then we get into a conversation. Typically, it is it's not fast enough, we need to scale quality is not the case. All those types of reasons come up. And so we I get into the conversation, like Okay, so let's be very clear. It's not about Scrum. In fact, it's about getting our challenges and your organization solved. Once that gets clear in their mind, I can go into the conversation about it's not just your IT team that will have to change, because we want to solve an organizational challenge. And once they understand that, it's not just about it anymore, we can start addressing these other departments, for example, my current customer is, is doing vision artificial intelligence initiatives for different customers. So they have about at this moment, I assume 19 projects that they are trying to deal with, with five teams. And I was like, Yeah, cool. That sounds very interesting. How is it going? Yeah, we have deadlines and milestones and etc, in our contracts. Okay, fine. That means if you want to challenge scaling in our organization, and scale up from 19, Initiative's to 2025 30, maybe more even, we will have to do something with those contracting, because if everything is carved in stone in those contracts, we are screwed. We will not be able to, to learn fast enough to answer to all the deadlines. So this example clearly show to them that they need to do something in their sales department with contracting. Can I have sales in those teams? Not really, that will be constrained. Fair enough. But at least we have now a step into the game to ensure that they will start dealing with contracts in an agile fashion. And that goes for all departments. You will see the same for example, with the HR department bonus systems, it's critical for me to ensure people start collaborating, you want different bonus systems typically. And so step by step I try to explain to them it's not about it's not about Scrum. It's really to deal with challenges and everything that block says we need to remove.

Eric Naiburg: 14:40

Great, thanks, Steven. Here's an age old question that I know we get quite a bit. What do you think about the product owner being the same person as the scrum master? At the same time? It happens a lot we know. What are your thoughts on that? How do you handle the conflict of interest? How do you handle the fact that someone's having to try to wear multiple hats at the same time?

Steven Deneir: 15:09

The words that have been chosen here are very correct is try to we all know that they have different accountabilities. I've seen I've seen product owner scrum master combination. And loi initiatives has been rare. But I have seen product owner having also the title of, of team lead, Scrum Masters having a management role. And each time I see combinations, I point that out to people like your wedding now two hats. And that's fine. But be aware of the risks of it. And so for me, it is about can we deal with the risks that bring having multiple roles, we already have enough risk. So we've got currently doing this we are in fact adding more risks. Dangerous. So I pointed out to them a product owner who is also scrum master will have a preference. So where the scrum master is accountable for growing the team, product owners accountable for maximum value maximizing value, what if there is an issue coming up in the team? What's the preference of this person? Is it maximizing value? Or is it growing the team? And depending on what it is something we will suffer? It will it just it's just natural. I'm trainer, I'm coach. I'm also my own accountant. And I know what my preference is. So my accounting sometimes selfish. Do I take the risk? I do. Fortunately, I have also an independent accounting supporting me who now has done wonders for me up a bit. Steven and Oman's coming up. Are you ready? And it's the same fuel mix pure scrum master even developer I've seen scrum master and developer is more common to me. Yeah, it's a big risk. Is it hard to deal with it? We can only point them in the right direction. And sometimes say, Hey, you feel you overlooked something here? Because you have to have some

Eric Naiburg: 17:12

nice do with it? Yeah, I mean, we talked about this a lot. We talked about phobia. And the need to focus in once I start trying to wear those multiple hats. Once I start having to divide my focus, I become potentially less effective now and it becomes more and more difficult for me to to execute successfully on job that I need to do. I think there's also that. To me, one of the biggest problems I see in someone playing both the scrum master or taking on the scrum master accountabilities and the product owner accountabilities, one, they're both very big jobs. But but also, there's a conflict of interest where as a Scrum Master, I'm helping to support the team, the organization, the developers, the product owner, and so on. And if I'm trying to do that, and I'm the Product Owner, I've now got a bias. And is is good and honest in everything is I am it's very difficult to overcome those biases of pushing for what I as a product owner thing versus what I as a scrum master should be doing to help support in really empower the entire team. Yeah. And

Steven Deneir: 18:34

what I want to still add to that the combination of these two is there's a very big difference in focus in the sense that, for me, a product owner should be more outward focusing toward the markets towards the users towards customers. Whereas the scrum master is more inward focusing within the organization and the team, surrounding departments, the management environment of that team. It's quite different these two

Eric Naiburg: 19:00

definitely, most definitely. So next question. I'm trying to get the team to use more discovery methods and fully embrace it in this case, James is looking at the opportunity solution trees. What other methods in in tactics have you used? And have you seen being successful in doing discovery type work? And what I'd add to this and he doesn't mention this here, but also validation, right? Discovery is great, but we need to also do that not just discovery, but we need to do that validation.

Steven Deneir: 19:37

Um, explicit practices, explicit methods, not immediately jumping to mind. My current product owner, for example, is has done recently a competition competitive analysis. And that was very interesting for them to see. Like, okay, We are discovering here the market better not not really by checking with prospects or service, but really by looking at what are our competitors offering, and then not just blindly following, but really identifying, okay, this is their strength, this is not ours. So fair enough, we don't, we don't cover that it's not a basic item we need to cover and our product. On the other hand, he saw competitors offering certain things where he said, but we are way better than that. And as such, let's, let's put some more efforts in those to show the market that this is this is, this is us, this is really us. And then he went to a number of prospects with that, with that data with that information, validating it with them. So it's not just a specific practice or method, it's just a way of stepwise finding out based on both competitors and prospects about what's making most sense for them to focus on right now. I hope this helps a bit.

Eric Naiburg: 21:08

All right. And thank you, and I'm sure if if not, there'll be more questions about it as well. So question around change management and having people who are responsible and helping in manage change management, if you will. Do you see that work best as a standalone organization? And this might be a leading question, but we'll say or should we have people who are responsible or accountable for change management? assigned in within the scrum team? What works best? What have you seen work?

Steven Deneir: 21:43

Yeah, my experience is that I cannot change people. So a role or people or departments fixed on change management, in my experience, I have not seen it been very effective. What we can do though, is we create an environment where people are starting to be open, like, Okay, this could be an ideal, let's try that let's, let's figure out how that could work for us. And the people who can create that environment are typically in a management position. So when I do Agile adoptions, and Scrum implementations, the idea is really work together with the people so that there is a safe place to start trying and sharing things. And through that, change typically, is more accepted by people. It's not other a change manager there who says that it's really it comes from themselves, because the environment allows them to do it. It's quite tough work, honestly. But I love to do it.

Eric Naiburg: 22:58

It is and I think, having having people, part of that team really ties that together, right? And makes us feel as a team rather than outside, which actually ties to the next question, which is a follow on to the architect question. So if Fabio kind of adds on to that and says, you know, the architect is saying, I'm the architect, and I decide the architecture, and doesn't involve the rest of the team? How do you mitigate that? How do you start to bring them in as part of the team? How do you start to get them to see the value of group thinking and in collaboration versus us versus them?

Steven Deneir: 23:47

Yeah, nice question. That really depends on the person on how to approach that thing. What's for me is important is that we get the person into learning that other people are also probably interested in architecture, and that it's not a one person thing, that the more people can bring in their point of view, that the architecture will become better and better. It's, for me related to the values of Scrum really, is that person, why isn't that person open to it? So openness is a big one there. Do others feel respected? If he only decides alone? There are two values that come to mind for me they're one of the things I tried with people and teams with success is to let them list the skills they feel they have right now. And it doesn't matter if others agree with it. There's just if I feel I have the skill, I just put it on there and on the on the board and that's it. That's one step. The second step is then what skills do I want to learn as a person And then the next step was, how can we help each other? Now? Look, there's someone who apparently wants to learn architecture. And we have a great guy who's doing architecture. How can we now make sure that they start sharing information? Of course, here, if the architect says, No, thank you. Let's have a look at the other side, we have that architect who hopefully wants to learn other things. So the rush is like, what do you want to learn? And probably there's someone else in the team who can help that person. And so by setting a connection between people who wants to learn, it might be that this person starts to be open, like, okay, I can learn things, the only thing that is expected from me is that I also help other people to learn. And like that you you build a connection between people, and they start learning together. That's one approach I tried. If the person really says, No, thank you, I'm not interested, I don't care. I want to do architecture. And that's it. I'm questioning if the person is a real good fit within an a scrum team. What could be though that is that he is becoming an expert within that organization for something. And he is not part of a team, but he is called in as needed. As as an expert, so as an advisor, maybe. And of course, then he cannot decide the architecture at all anymore. He will be out of the teams. And people will only call him if they are blocked with something like, Hey, dear Asha that we have we have a blocking issue here. Can you help us out on the architecture? That could be another way out? I'm not sure what the best way is in that organization with that person. But that are two options that immediately jumped to mind.

Eric Naiburg: 26:49

Right, thanks, Stephen. Here's a going back. Because it's been a long time since you were a new scrum master, but you're helping a lot of Scrum Masters. Do you have any? What What would be your one must read book for a new scrum master someone kind of just getting started. And what I'll say as well, James is definitely check out the scrum.org learning task for Scrum Masters and we've got a lot of content now. There's a learning series on getting started as a scrum master. So check that out. I'll throw the link in the chat in a moment.

Steven Deneir: 27:23

Okay, yeah, I read quite some books. The one that I would immediately recommend is from one of our colleagues is from Stefan Yokomen. And it's mastering professional Scrum. I think that is that's a must read book for people who are getting into it. That's one. I also love fixing your scrum by another one of our colleagues, trainers. So these are these are two books I really like. There are of course, multiple oldish the scrum book and book from Hunter for Hayden is also quite good for starters. So yeah, that's already three.

Eric Naiburg: 28:06

Thank you. And I just threw that link to getting started as the scrum master learning series out in the chat as well for anyone interested you can find it out on the Resource Center. Yeah,

Steven Deneir: 28:17

that that's really recommend that I always say to all my students, all my participants in all my classes, go check that one out and keep monitoring it because very often, there's some new stuff also on it. So

Eric Naiburg: 28:28

exactly. We were always putting in those are all primarily free resources available for you. So next question, Lewis wants to understand a little bit about your thoughts on the value of scaling Scrum. How do you what do you see? What are your thoughts around around scaling Scrum? Yeah,

Steven Deneir: 28:50

nice. Nice one. I think we don't have a choice anymore. In this world. We are in the beginning, it might have been that there was one team working on a product. I hardly see that anymore. Always 2345 And even more teams working on the same product at the same time. So scaling Scrum is no it's no longer a question that just we will have to do it. Scrum of scrums in the traditional sense that I've heard from where Scrum Masters come together after a daily and start discussing things that one I don't believe in. I feel that a practice that goes against self managing, even so I want that teams connect themselves with one another so that they grow and learn together that they grow the product together. So for me, it has to be a team member, a developer exercise. More than it's a scrum master exercise where of course scrum master will support it, no doubt. So that's my remark on scrum of scrums. Last Great, great. I can't even Call it a framework. It's more a set of principles, which I really like. It's a very, very good set of principles guiding principles for scaling Scrum. We also have nexus in our portfolio. So these, these two are really the ones I look into for scaling Scrum. I think that the biggest tension point for me with scaling is, you want to try to reduce dependencies between the different teams as much as possible. So during, for example, a sprint planning a common sprint planning, for me, it's important that teams select items from the product backlog that they can work on as independently as possible from the other teams. And if there are dependencies that they solve them ASAP, during sprint planning, or shortly offset, and to me that is, that is the biggest attention point I've seen with scaling Scrum.

Eric Naiburg: 31:01

And just, to me, I think just remembering scrum was just Scrum. And coming together and making sure we're able to deal with the dependencies across teams. And in understanding how we work together in understanding the things that need to get accomplished toward a common practical. And keeping that product goal, always top of mind helps helps kind of guide people that that North Star is someone talking about

Steven Deneir: 31:33

no product goal, and everything goes in all directions. So that is that is a key factor. Even without scaling, it is crucial.

Eric Naiburg: 31:42

Exactly. So next question. I guess it's kind of a bit of a follow up. We're trying to replace our manager heavy steering committee with a product owner from the business. What's some good advice on how to convince those traditional managers that a product owner is a good option? Or actually is a better option? Right? Or the best option? And would you suggest to keep a steering committee in order to ensure information and commitment is ensured. Amongst that team, how do you how do you kind of handle that? Right? I mean, those folks certainly are stakeholders and should be playing that the role of stakeholder for sure. So how would you help to ease that fear of? I'm guessing, and I'm reading into this a bit, but I've experienced that as well, that fear of a loss of control and delegating that control to the product owner?

Steven Deneir: 32:40

Yeah, yeah. Yeah, nice question. I even faced it today, also with my current customer. So what we will do with that customer, the key aspect, in all cases, by the way, is keep things transparent. So that steering committee might feel like we're losing control. So Transparency is key here, have the product goal crystal clear all the time in front of them, have the items that are on top of mind for that top of the product backlog, always crystal clear for them. And short, the product backlog shows a roadmap even with the big steps to get to the vision. So so that that is the first thing I strongly recommend make sure there is transparency for these people who weren't in the steering committee to ensure that they feel comfortable. I think it's about comfort for these people. At that moment. Do you still need the steering committee? That's that's another question. That's context dependent. For example, my current customer will keep the committee but more as an information sharing session, like with people from sales, this is in our current pipeline, with people from marketing, this is what we're getting from the market, the product owner who's informing them, this is the roadmap and, and those kinds of things. And together, they, they finally discuss, and the product owner decides on this is what it will be. And the last thing stays important to me, it's still a product owner decision. And then it's not the status quo decision. But the product owner has listened to that group of stakeholders. I assume with my current customer, we will be able to get into the future that that specific committee is no longer needed, because these people will start joining sprint review sessions where the transparency will also be available. So for me, it's an in between and at my current customer, we still have to keep it because of the comfort level the control level the transparency, that's not yet enough. But gradually I will I will certainly make sure that the sprint review should be enough also for nice people. I'm not trying to convince sorry, Eric As

Eric Naiburg: 35:00

I say it, I think that's one of the big things. And I think this is somewhere that that often we fall down as well as helping folks understand their role in the sprint review and their role overall as a stakeholder. Right? Yeah, I think I think the role of the stakeholder is often underestimated. And I think getting them to understand that and getting them to understand the value that they continue to bring from the organization is critical.

Steven Deneir: 35:33

Yeah, it is. And that's committee at all, it always depends who's always who's always there and what their decision power is. But in the end, if these people join a sprint review, and they HEAR FROM Users, customers, prospects, who join the sprint review, input and feedback, if they hear that they also learn a lot from that, and it guides them in their own organizational mission and strategy very often you so it's very positive that they get into contact during a sprint review. With these people, it's very useful practice.

Eric Naiburg: 36:09

Absolutely. Perfect. Here's, here's one that I think we probably see quite often I know, I've seen this. On my team. There's a powerful and high technical, technically skilled person, who is of course, respected quite well by the team. They show strong resistance to scrum however, and that influences the team. Any tips on how to get in, keep moving forward and in get them to understand and be be a champion, rather than maybe a deterrence?

Steven Deneir: 36:48

It's a brushing thing again, so I'm not sure who that person is. The thing is, the advantage for me is he's already highly respected by the team. And I like that. So if we can convince this person, we probably have everybody with us. So this is an advantage I see there. I would try to find out why he is resisting to Scrum. Because there are so many great things we can do. So why why is this person resisting? Is it because he's afraid of losing his job? It could be. If that's the case, I can already guarantee the person, there's no, there's no real risk that he will lose that. Because there's always a lot of work to do. And we can use all his skills very well. So that's not, that's not a big a big issue, we just have to have that chat. If it is losing status, maybe because all of a sudden, other people are also doing that role, then we could indicate to that person Hey, but your skill is key for us. You are very technically skilled. And instead of you doing the job yourself, we promote you to also teaching coaching mentoring people. And yeah, if it's a status thing, promoting people is all as always something positive. I'm not saying promoting with bonuses and stuff, I'm just saying, you have an additional accountability right now, and that is mentoring and coaching people. So it really depends why the person is is blocking on Scrum.

Eric Naiburg: 38:23

It I wonder if there's also some myths in their mind, they're often are that maybe you can start to uncover by working with them in understanding those myths. They may think that this is just about meetings or, or the like and not, excuse me, not understanding really that all we're doing here is focusing on deliver value delivering value, and we don't know everything up front. And how do we get the team to work together and focus on delivering that value toward that product? And sprinkle? Yeah,

Steven Deneir: 38:55

definitely. There are a lot of myths going on. And with everything's going on, honestly, with chat GPT. That's an AI system that is based on existing knowledge. But that knowledge includes quite a lot of myths. And they get promoted even I see these days. Yeah, I think

Eric Naiburg: 39:16

it's an interesting point, Stephen, because we actually did some testing of some chat GPT stuff. And the problem is the right answers. And the wrong answers are just as come across exactly the same from a confidence perspective. And there's no way to determine is this right, or is this wrong? And it's very, very interesting and very scary at the same time. Yes.

Steven Deneir: 39:40

Yeah. Agreed. Yeah.

Eric Naiburg: 39:42

So, next question. I'm a project manager and I'm looking to become a scrum master. any guidance on on the skills that I need? The what I need to learn how tough is it to adjust and change and So on, I'd add to this. I actually wrote an article on this. I'm a scrum a project manager. Does that mean in my company's going Agile? Does that mean I'm now a scrum master? And it's the typical, I'll say consultant answer of it depends, right? I know some very, very good project managers that may not be good at scrum master, and might be very good at helping the team deliver, and tracking, but not maybe have all the personal skills to really help coach in mentor and teach the team. And I know some very good Scrum Masters who probably wouldn't be great project managers as well. But, Stephen, your thoughts? Yeah,

Steven Deneir: 40:43

been there done it. So I was project manager in the past. And it does depend on your current way of dealing with projects, if it will be easy or not. So a traditional project manager typically wants to have all control and, and decision power. Whereas we are not expecting that at all from a scrum master not at all You don't you don't have control over how the team will, will deal with a challenge, you don't have control about what they will size, what they will take on first you guide them, you give them tips and tricks, you give them practices, you facilitate them. But in the end, it's up to the team. So it's a big shift for this type of people. On the other hand, if you're a project manager, that's, that's really already in the facilitating mindset and guiding team members to, to come up with estimates on that project and let them do their planning themselves, that that's a whole different, different change that the person will have to go through. With regard to the skills that the person needs, I think it's really about people, we are really a people role. We want to connect people, we want to guide people that they collaborate more, we want to guide people that they learn new things to gather, we want to facilitate them in dealing with conflict themselves. So there's quite a lot of skills. And if I would pick out the ones that that were most useful to me. Conflict handling is a big one facilitates teams and conflict handling. Another one that I that was very important to me was facilitate workshops in different ways than than I did in the past with PowerPoints and stuff like that. Coaching, I followed quite some sessions myself about what is coaching, what is team coaching, how to deal with it. So that would be my top three of skills to focus on based on my experience. And again, it depends where the person comes from, of course. Right.

Eric Naiburg: 42:52

Right. Thanks, Steven. We've got a couple of questions that I'm grouping together here, because they're very similar. And have I think the answers will tie to both of them, although the questions are a bit different. The first being, you know, my stakeholders aren't available. I don't have any internal or external stakeholders available for the sprint review, should we reschedule? So that we can atop accommodate the stakeholders are? How would we handle that? And I'm gonna then add on to that a separate question, which is, how do we adapt to increase that availability of key stakeholders to come into the Sprint Review? Who don't actually don't say this in the question, but I'm reading into it a bit, they'll understand really the goal and the value of the sprint review and would rather just see demonstrations or a personalized presentation. And I think in this case, they're missing some of that what we were talking about earlier, is understanding what you are as a stakeholder, and that sprint review is much more than just feed review. But it really is an opportunity to learn and feedback. So I'll take those two questions, you know, should we reschedule if we can't get the availability? And then if it's a consistent problem, how do we get them to understand the value of and why we want them at that sprint review for group thinking? So on?

Steven Deneir: 44:15

Yeah, that's a nice question rather than a question. I follow the provocative coaching session. So let me be provocative a bit now, towards the stakeholders. These stakeholders, it's your product, right? It's your initiative, it's it has to serve you. If this is not important enough for you, why would we need spend time for you? So that would be my provocative stance at that moment might be dangerous, no your stakeholders if that would be accepted or not? I've done that with a few with positive results. You might have different results with a reschedule. Not really. We want to have a heartbeat. That's why sprint exists amongst others, to have a heart We'd like every day, you know, this is it. This is the moment where we have the review. This is the moment where the team knows we have to be ready to give it into the hands of users to get feedback. If you delay, if you reschedule, the heartbeat is gone. And without heartbeat through debt, right? That's one thing. But it's also you people will feel lost, like, Hey, is it? Is it now okay to delay? Is it now accepted to say we are not ready? Is it now accepted to to be late and meetings to just not show up too? So that's the wrong message we would give. So no, don't don't delay. Now, in order to show people the importance of it. I have used a practice lately, I have a little app on my mobile phone. It's an app for my cart. And I demonstrate it, I really do a demo before people and say, Look, this is the app. This is how it works. How do you feel response? Almost always zero, except from a few remarks for people who also drive a similar car. And they say, oh, yeah, that's cool work. So yeah, thank you so much for the demonstration. So I Okay, fine. Thanks. And then I switch to review mode. And review sprint review mode, by which I mean, I give my mobile phone in the hands are one of these people, stakeholders, and they try out this with my app, find my car. And then you see the person looking at my mobile phone, taking a bit left and right, and all of a sudden the person is I found your car, here it is located. And typically, it's wrong. And then I give these people feedback. Look, you've just used the app, I now notice that you've done five, six steps on my mobile phone, which was not needed. But apparently the user interface is not okay. And moreover, I know that now you have the wrong results. So the icons shown on that app probably are not the right ones. And like that, I show them the importance of of really be present in the sprint review. Because I want people to use the result, the outcome, the increment. And through that, I immediately show them also that we can do something with their input, which is the second part of for me, the sprint review, is to now decide, maybe not always decide, but at least take that feedback seriously and show okay, how important is it? Is it important for the next increment? Can we delay it and take on the other items that were on the product backlog as it is knowing these these new insights. So through that little exercise I do with them, I let them learn that using the product by themselves during the sprint review has very, very valuable input not only for the team, but also allows them to see down that that was not it. It really needs to improve in this or that or that way. And for me, it helps so far, just that little exercise it takes it takes about five minutes max, to show them that the time they spent in the sprint review is really well well spent time for them.

Eric Naiburg: 48:24

Great. Thanks, Steven. Next question, you open this can so I'm gonna let it keep going. How have you been using AI to enhance your RA? Or have you been with how do you see it being used?

Steven Deneir: 48:36

In my role?

Eric Naiburg: 48:38

Yeah,

Steven Deneir: 48:38

the lately I said, the HR GPT. I'm having a visioning workshop. In a few days. The goal is this. This is the context, please come up with a sequence of steps to do visioning workshop. And it's very impressive what it can do. But you need to take it with a grain of salt, and give it your own twist. So for these things, it was very useful. If I asked GPT to answer very specific questions like PIO and Scrum Master combined, that's something else that you need to really pay attention to, to the myths that exist and take care that you don't fall in the traps following limits. But for outlining a workshop, for example, very useful things come out. And one

Eric Naiburg: 49:29

of one of the great things up are ways I've heard it described Microsoft does this is they talk about it as companion technology, not standalone technology. And they talk about how you can use it together with your own intelligence can help make better decisions and I think that's a great way to think about it. All right. Well, one of the things I was a face to face engagement Last week in Germany with a number of our trainers, and we were talking about this and how they're using as product owners using chat GPT and other technologies to help enhance what they do. They're feeding it things and getting suggestions back and reviewing that. They're pointing it to a set of content and asking it to help write user stories and then reviewing those. So they're not just letting it go off and do its own thing. But they're using it as a way to enhance what they do. And also reap tako. Take away some of the repeatable tasks that are more mundane as well. Yeah, yeah,

Steven Deneir: 50:43

sure. Sure. The thing is, you have to understand how AI works a bit. It's a predictive model, in fact, based on past, past knowledge, and the knowledge has been indicated by people. So if those people follow your reasoning, it's pretty much aligned. If not, that will be different. But typically, for example, Chad GPT, has been trained to be pretty positive. And you always get pretty positive answers as a result, of course. Exactly.

Eric Naiburg: 51:13

It's it. Yeah, like I talked about earlier, we were trying it for certain things. And those those, those incorrect answers were just as positive as the correct answers, which were pretty misleading. So next question. How do you feel about agile metrics? And how do you feel agile metrics could be used by management? How do we hold a healthy relationship with these metrics so that they're not over? There? So that we're getting true answers, right? So that we're not setting it up for, for for success and getting really true measure? So how can management use agile metrics? Do you have some some suggestions? Some thoughts and experiences there? Yeah,

Steven Deneir: 51:56

yeah, I already question AGL. Metrics. What? What about HR metrics? For me, it's about business metrics. It's not about HL in itself. We do HR because of the business. So So I guide my my teams, my my organization's I coach into what's important for us, what's our Northstar? What our capabilities we need, and see how to measure those. For example, my current customer, we have a challenge with technical excellence. That's great. So how will we measure technical excellence? Well, our show metrics, and I always try that people, the teams themselves come up with those things. And management. Because, for me, it's to guide the teams to be more effective, that we implement Scrum and other agile practices. So for example, they came up with for us the code coverage at this moment is bad. Okay, then we'll come up with a metric for for code coverage, which is an easy straightforward one, in the end. Another one that they started now was the CI CD pipeline availability, how many times is it crashing? How many times it? Is it having arrows? So for me, it's really about metrics that the team come up to solve their challenges. Another one that they came up is refinement sessions are heart. Why? Because we don't know a lot of techniques. Okay, cool. So how many techniques that we learned, how many techniques that we apply? And what are the results now, and they came up with some metrics for them. So it's not just AGL metrics for management, it's really metrics for the teams themselves to guide them solving their challenges. And attention point is, don't start comparing teams. A typical one is velocity. And then management starts, sorry, starts comparing teams based on velocity and like, Yeah, but that's easy to gain and it will be gained. So as soon as you start comparing, whatever metric across teams, it will be gained. And that's not the purpose at all.

Eric Naiburg: 54:09

Basically, when I just added a link into into the chat to evidence based management, and thinking about what we need to do is not it's not about outputs, as you said, it's not about velocity. Definitely not. And I wrote another article on don't use velocity as a weapon. And it's not I don't care how much output you have I care about the value you're delivering and how are we going from opportunity? How are we closing the opportunity gap? And you know, agile metrics? Honestly, as you said, I'm not quite sure what they are. I want to have metrics that measure the value that we're delivering and how are we closing that that gap in achieving our goal in really looking toward how do we get to that goal, and then how do we learn from those metrics to improve as As we go and improve the work that we're doing, and

Steven Deneir: 55:03

this is exactly evidence based management, it's not about AGL metrics. These are really examples of business metrics. Organizational metrics. Yep, absolutely.

Eric Naiburg: 55:14

Cool. Um, I think we have time for probably one or two more. Here's one that comes up quite often, we often see agile equals Scrum. But we know that's not really the case. Scrum projects. Yeah. How do you how do you overcome that? How do you have that conversation with people who just think, you know, I'm going through the motions of mechanical scrum now on agile?

Steven Deneir: 55:46

Mechanical Scrum, for me, you quickly see what's happening, people come to meetings in the beginning, they hardly speak up, and then they check out again, and then after a while, they don't come anymore. And this is what I'm telling you people, if you're just doing the mechanical aspects of Scrum, or any any other methodology or framework for that matter, if you only do the mechanics of it, people will quickly feel like robots. They don't see value in it. And they will check out. So for me what's very important, any of the of the scrum events is that people feel that they do inspect things, and things are adapted that there is change happening, because because of those events, and that each of the artifacts, bring transparency, the transparency that's needed to do inspections and adaptations. And if you start having that in each of the events, then then the mechanical stuff gets out. And people start to think really about, okay, we're doing a daily scrum today. What are we now inspecting? Really? And how will we adapt? So if you get that into it, it becomes it gives way more value and the mechanical gets out of it. It's the same with all the events. In fact, it helps people to come to what is really important. That's one part to get the mechanicals out. The other thing is about the values of Scrum. If you are sitting in a in a scrum event, a nobody speaks up, something's probably wrong with the value of respect, openness, commitment, probably focus. And as a scrum master, you can try to facilitate that, to grow the trust so that people can be open in the different events, that they start respecting each other, that there is focus in them in the events to come to, to the to the goal to the objective of the event, to get those mechanics out, in fact. So for me, it's a combination between empiricism and the scrum values and events to get the the mechanical part out of it and really get into what really matters.

Eric Naiburg: 58:06

Right, thank you, Steven. And I want to be conscious of of your time and the time of the audience and to try to keep to our time box of one hour. There are questions we did not get to Steven will have those and he'll try to respond the best he can via email to folks. I'll have those that information for those who provided it and get those answers. Again, thank you. As we talked about their learning paths for the different accountabilities on the website, check them out, keep growing that learning, keep checking out those different pathways and, and join other webinars and feel free to reach out to Steven you can always find his profile on the scrub.org website and contact him directly or take one of his classes. And with that, they'll connect with the community, join our blog, reread those posts, and so on. And I'd like to just say thank you. Thank you, Steven. Thank you to our audience. And thank you all this recording will be available shortly. Thanks everybody.

Steven Deneir: 59:10

Bye bye.

Unknown: 59:11

Bye bye.