
Scrum.org Community Podcast
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.
Scrum.org Community Podcast
Ask a PST - Scrum Master Edition with Bart Versteegen
How do you prove your value as a Scrum Master? What steps can you take as Scrum Master to coach your Product Owner? What are some ways to make Scrum Events more engaging? There is a lot to navigate within the Scrum Master Accountability. PST Bart Versteegen recently answered some burning listener questions about the Scrum Master Accountability. Tune in for great insights!
Announcer, 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 a professional scrum trainer series where a live audience asks questions of professional scrum trainers. We hope you enjoy this episode. Good morning, good afternoon, good evening, wherever you're located today. Welcome to today's Ask a professional scrum trainer. I'm Lindsay valestina here with scrum.org I'm going to be moderating our session today, and we are super lucky to have one of our professional scrum trainers here, Bart Verstegen, out of the Netherlands, and he's going to be asked answering your scrum master questions. So get those ready, and I'll tell you in a moment here how you can start submitting those. So welcome. So very quick guidelines here. You'll notice that your microphones are muted. We do want you to ask questions, though, so please utilize the Q and A box at the bottom of your screen to enter all of your questions. If you have any technical questions, you can utilize the chat, which I will open up in a moment. So with that, I'll just very quickly introduce scrum.org. In the event that you aren't familiar, we are the home of Scrum. We were founded by Ken Schwaber back in 2009 one of the CO creators of Scrum, and our mission is to help people and teams solve complex problems, and we do so through our training, certification and ongoing learning. So we hope that today's session plays an important part in that ongoing learning. There are a lot of free ways to learn about Scrum on our website, so please check those out. There are a lot of learning series that you could go through and other webinars, podcasts, etc. So please be sure to take advantage of those, and it looks like you already are, since you're here today. So with that, I will pass it over to BART to introduce himself.
Bart Versteegen:Thank you so much. Lindsay. Welcome everyone. I'm I'm not seeing any faces. That's a bit unregular for me. So if you're looking at me and you're seeing a nervous trainer, coach and consultant, it's because I can't see you, and I'm so used to it. Let's start at the beginning. My name is Bart, and indeed, I live in the Netherlands. I have been working in product management for around 10 years already. I'm a father of two, two small daughters, two years and now almost three months. So if I'm looking a bit tired, it's not you. It's most likely the lack of sleep. Unfortunately, next to my home life, I also have a business life. Of course. I'm employed by pro awareness, one of the biggest consultancy firms within Western Europe. We focus on that segment of the market. And AT Pro awareness, I'm a full time product consultant, which means my main focus is product management, and by focusing on product management, I help leadership and Scrum Masters to enable enable them and to gain knowledge on the topic of product next to my work at pro awareness, I am a podcast host, together with another PSD, Stas pufflov, I Have the Agile BS podcast for now, that's in Dutch, but we will be going into English in the near future. I am an author to be my book, a toolkit for product owners and product managers, will be published in November of this year. We will also be translating that to English, and also be publishing it in an e book format. So also for our international visitors, yes, you can buy it somewhere at the end of the year. And for the last 10 years, working at pro awareness, I've been a scrum master myself. I've been working as an Agile coach, which is for me, nothing else then and Scrum Master, without a scrum team, I've been working as a product owner, a product manager, and everything in between. So my experience is broad in very different segments of working field. So to say so, that's me in a in a short notice. And then, of course, I also have a private life. Next to having a beautiful life and two daughters. I have multiple hobbies, and my current biggest ones are woodworking and craft beer, but be aware, they can be combined just small, small one for today, pro tip. So the pro tip, yeah, I don't think it should be a pro tip. I think it should be just a tip. But I think that would be it for that, for now. So just some information about me, and then, of course, we have 55 minutes left to answer every question around the scrum master accountability and Scrum itself. So looking
Lindsay Velecina:for Yeah, I'm gonna stop sharing here. So why don't you set the stage for us? So you chose to so that to help our guide our audience in their question asking here, so what? What made you choose to focus this session on the scrum master?
Bart Versteegen:Well, my choice was made around scrum master accountability. Because at least in the Netherlands, in a big part of Western Europe, I see a lot of Scrum Masters, uh, limiting themselves in only focusing on team productivity, Team efficiency, and maybe better ways to do refinement in such a such form, so to say. And I think at least in my market segment, that means that you're limiting yourself in in growth opportunities, in making organizations more effective, right, and also in in the personal development of the people around you, especially people within the product responsibility. So I thought most of the courses that I teach are pspo, bhpo, advanced the professional Scrum Product Backlog management skills training, ppdv, it's all product based. I do little work with Scrum Master, so why not take the podium to address them directly, and no better podium than a scrum.org webinar. So I think that's the reason, reasoning behind
Lindsay Velecina:it. Awesome. Thank you. That makes a lot of sense. So it's great that we have open forum here with Bart so please submit your questions. So we have a few that have come in. So what are some of the typical errors you see new Scrum Masters make, and what can we learn from them? That's
Bart Versteegen:a beautiful question. Um, I think a typical, typical error, if you could find one of beginning Scrum Masters is focusing on how Scrum is described within the scrum guide, and following that to the letter. There, of course, is a lot of value in the scrum guide, because it helps you to navigate complex environments, complex product development, but it should only be treated as such, as a guide to help you find ways to improve and be more effective in that complex environment. And if you only focus on what's in the scrum guide itself, then you're limiting yourself on discovering new practices and discovering new ways of working, and think that's what Scrum is all about, knowing what you don't know or not knowing what you don't know, actually, and encountering a lot of problems and challenges and then finding ways to solve those complex problems. So focusing on Scrum, I think that's one next to that. I see a lot of beginner Scrum Masters, if you could call them that, focusing on Team efficiency. I still see a lot of clients and organizations focusing on what metrics should we introduce, for instance, or what metrics should we implement to have a better understanding of how teams are performing, and we still have some of the myths around philosophy going through the professional scrum community. And I think there are a lot of professional scrum trainers who say, a lot of relevant stuff. Let's use the word stuff. Why not? Let's say a lot of relevant stuff based on the topic of philosophy, and it's nothing more than a vanity metric. So only focusing on what I like to call output doesn't say anything about value. So I think that would be the second beginner or the rookie mistake. Maybe, maybe rookie is an even nicer word to use. And beginner or rookie mistake number three, let's call it like that. I think would be passing along the microphone during the daily scrum, right? We all know the three questions that are regularly used in daily scrums, what have I done yesterday? What am I going to be doing today? Do I have any impediments? Yes or no, and what you do, or what you try to introduce with that way of working is some sort of zombie Scrum, only following the processes that are in that data Scrum, but saying nothing about the value that is actually being created, saying nothing about customer. Are saying nothing about goals. There's a reason why you have introduced protocols within the scrum guide of 2020, and the data scrum has only one goal, in my opinion, and that is having the conversation, are we moving into reaching our sprint goal? Yes or no. And those three questions could be valuable, but in most cases, they're not that valuable, to be honest. So skip them and have the conversation about, are we reaching our scrum goal? Yes or no.
Lindsay Velecina:Okay, hope that helps. A lot of sense, yeah. Did you have something else to add there? Are you good? That was a pretty comprehensive answer. I'm
Bart Versteegen:good. Let's go. Let's go to the second one.
Lindsay Velecina:Nice. Okay, so as a current technical developer in an Agile team, how does one transition into a scrum master role? I have my PSM, but I am struggling to transition due to no actual experience,
Bart Versteegen:right? That's a good question. And let me start by congra congratulating the person that wants to transfer to that scrum master accountability, because I think it's a wonderful way to start your journey into the more agile, focused roles. Yes, I think my number one tip would be to start shadowing the scrum master that's already in the team, or working with the team and having conversations about, okay, I currently am. I'm a developer. That's my main that's my main role. That's my main function. But it would love to trend, transform or transfer to that scrum master accountability. What are some of the first steps that I can take? And I think a good stepping stone would be to start facilitating more and more sessions. Because I think facilitating is a skill that every product owner, product manager, Agile coach, manager, leader leader or scrum master should have, and I think it's very undervalued and underrated how important good facilitation really is. So I would urge this person, whoever you are, have the conversation with Scrum Master that's already on your team and think about ways. Okay, how can I start facilitating some of the events, maybe some of work, some of the workshops that are being done, and start by that and maybe focus on what the developers within the scrum team need. Try to solve some impediments, try to have some conversations with management or leadership around the team, and try to unblock the team and help them move them along.
Lindsay Velecina:Awesome. Thank you. I hope that helps. Good luck and also congratulations. That's exciting to embark on a new career move there. So awesome. Next question here, I have a team that I believe, that believes that it is the job scope of Scrum Master to always host retrospective sessions. However, I have a different view from my perspective, the scrum master is someone that established the agile practices, especially scrum into the team when this practice is well established, like writing product backlog items, hosting the retrospective can be delegated to other scrum team members when there's no major impediment happening, because the scrum master still needs to serve the organization. What is your opinion on this?
Bart Versteegen:I totally agree. Next question, sure, small joke, you're totally right. As a Scrum Master, you're not responsible for facilitating every event or workshop. You're responsible for making sure that an event is facilitated in an effective manner, and that can be done by delegating the facilitation itself, or it can be done by facilitating it yourself. So I would say the same thing to product owners than I would to Scrum Masters. Your responsibility is indeed also on the topic of organizational development for me, which I tried to introduce at the beginning of this webinar, there's no difference between an Agile coach and Scrum Master and a product manager and a product owner, except a product owner and a scrum master are working in a scrum team, and a Agile coach and a product manager don't by definition. So as a scrum master, you should still and always focus on how is the organization going along in the Agile journey, wherever you are in your agile journey, so making sure that you are not at every daily scrum, making sure that you don't facilitate every refinement, making sure that you uh. My transfer the facilitation of sprint events to different different members of the scrum team is a way to grow your mandate and to share accountability. So I, I would only applaud you for trying, for trying to go that way.
Lindsay Velecina:Thank you. Right. Next question, our sprint this is kind of similar, in a way, ish, our sprint plannings are facilitated by product owners, and the scrum master is just there to oversee that the team follows the guidelines. What would you suggest to the scrum master to be alert of in that situation,
Bart Versteegen:to be alert of in the situation that a product owner facilitating the sprint planning?
Lindsay Velecina:I think so that's just the best way I'm interpreting the question. But what? What would you recommend to the scrum master to deal with that situation,
Bart Versteegen:I would first ask the question to myself, Am I still needed in this meeting? Yes or no, and if I find myself to be zooming out, doing other stuff, checking my email, maybe playing a game on my phone, which isn't the most effective use of my time in that meeting. Then I should, I think you could leave it to the team to be honest. And when, when I take a look at the sprint planning event, for me, it consists of three parts, and you start by creating a spring goal for the current sprint that you're starting. After that, you're selecting product backlog items from your product backlog which you believe are helping you in reaching your sprint goal. And after that, you have the time to do some refinement if that's needed, and that's the sprint planning in itself. So for me, in the time that I I was a scrum master with multiple clients, I forced, forced, in some way, my developers and the product owner to take accountability around the sprint planning event so they, they themselves, could come up with a sprint goal that was a stepping stone into reaching the product goal, and they themselves could select product backlog items out of the product backlog without me telling them, okay, now we're going to do a 124, all liberating structure to come up with ways on reach the spring goal. Yada yada, Yadi, at a certain moment in time. They can do that themselves. So if I, as a scrum master, would be in this event, and I have a product owner that is capable on facilitating groups like a scrum team, and I see the product owner is not forcing the developers on taking around more scope that they can chew. And at the same time, I also see developers pushing back a product owner because he or she is forcing items into the sprint. That's all for me, healthy behavior. So that means that I have done my job. I've done my job properly, and now can I can take a more of a back seat and maybe don't be in the sprint planning event for the entire time box. That would be my that's what I would do. Your situation makes a lot, and I hope that helps, yeah, so hard questions to for me to answer without all of the context, but that's what I would do.
Lindsay Velecina:Okay, thank you. I hope that helps. And if you have anything follow up from that, feel free to drop that in the Q and A. So this next one here, let's just move right along. We have lots of questions coming in. So what would you suggest to look out for when the role of the scrum master and project manager are combined?
Bart Versteegen:Woof. I That answer opens up a Pandora's box because I have multiple questions. Maybe back to to the person submitting that question, combining a project manager and a scrum master role, well, for me, that would be the same as combining a scrum master with a product owner accountability. You can't be both at the same time. You can't make sure that Scrum is effective when you're also responsible for making sure that value is being maximized. And yes, in theory, you could combine both both accountabilities, but in practice, it would be very hard to do so.
Lindsay Velecina:But there are cases where the project manager does serve as a scrum master, right?
Bart Versteegen:Yeah, there could be there could there could be cases where a project manager is serving as a scrum master.
Lindsay Velecina:So if that's happening in the organization, yeah. And you know, the person in that role has, like, no real control over that. What would you suggest they look out for being in that situation? Just helping to try to guide the question a little bit, try to dig into the listener's head a little bit. And if I'm going the wrong way, feel free to chat me to the person who asked this question?
Bart Versteegen:Yeah, don't be sitting on the chair of the product owner. I think that would be my go to answer, because if I've been in the same situation, I've been a
Lindsay Velecina:It's not product owner, though. It's project manager and Scrum Master.
Bart Versteegen:Yeah, I know. But if we have a product owner and a project manager working on the same project or product, then, then we might have some overlapping accounts, right? So, and that would likely lead to a project manager steering the product development in a certain way and a product owner most likely, without the accountability that he or she needs, also trying to steer the product in a certain way. So then again, it's a hard question to answer without all of the context, but I think I would advise you to try to be very clear to the persons that you're working with, okay, I'm now being a scrum master, and I'm now being a project manager, and my accountabilities as project manager are A, B and C, and my accountabilities as scrum master are one, two and three, and I'm only focusing on being a scrum master at this moment in time for this team. I think that would be my best answer. Okay,
Lindsay Velecina:yeah. So if you have any follow up questions and want to provide more context, feel free to drop that into the Q and A, and we will raise this again and try to get to the bottom of your challenge there. Thank you. Bart,
Bart Versteegen:also, let me add something to that. Lindsay, also, after this webinar, of course, if you're if you have the feeling that then an answer needs some more reflection, and drop in my LinkedIn inbox, ask your question there. Maybe when we can co create a blog and publish it on the scrum.org community, which would be a nice addition, maybe after this webinar.
Lindsay Velecina:Just, yeah, absolutely. Okay, cool. Thank you. All right, so this next question, to what extent should a scrum master intervene in team decision making without undermining the team self management? I uh, could
Bart Versteegen:you repeat the question one more time?
Lindsay Velecina:So to what extent should a scrum master intervene in team decision making without undermining the team's self management? So if the team is struggling with making a decision, but the scrum master wants them to be self managing. What's the balance there for the scrum master to kind of push a decision along? Yeah,
Bart Versteegen:you can't. You can't force people to self manage, right? That's that's a bit hard. So when you don't give them, when they're not mature in in their job, and they lack focus that's being given them, that's being given to them by by leadership. What ways so that could mean product ownership, that could be management, and then would that will most likely lead to chaos. So I've written a I've done a small talk about that in in Dutch, and writing an article on it, and it's an article based on the concept of learning money. And learning money is something that a facilitator can can spend within the game, and just like placing a bet in a casino and learning money is money that you can invest and that you're okay with in not getting a return on it. So it all depends on the situation and how far along the team is, and how much learning money you would like to invest in this certain situation. So I would always try to prevent that you make something that's irreversible. But I would, at the same time also would like to push the team in some way to make mistakes and to create some failures, because failures create learning, and learning creates new opportunities to take ownership. So it entirely depends on the context that you're in and how much learning money you will you will be willing to spend if, if this scenario is around releasing a certain version of your product, then the learning money that you would like to invest might be lower than if it's only about. About a team member facilitating a retrospective, for instance, and in that last case, if that's the case, and maybe following up from one of the previous questions, if we have a team member within the scrum team that is willing to pick up the scrum master accountability, and you as a scrum master are eager to invest your learning money into him or her, then I would be okay with having a retrospective that is not as effective as it could be, because we create a learning moment for that scrum master to be, and we create a learning moment for the Team to also help a team member with picking up some new accountabilities. So it all depends on the context, and it all depends on how much learning money you will be willing to invest in.
Lindsay Velecina:That makes a lot of sense. Thank you. All right, so this next question, so what leadership skills have you found work the best for you while working with agile teams and what leadership skills work the best for individuals outside of the agile team. So let's talk a little bit about leadership and agile leadership.
Bart Versteegen:Okay, so leadership within agile teams and leadership outside of agile teams. That's what we're saying, right, yes.
Lindsay Velecina:So maybe if you have a few examples from your experience that you can kind of share to kind of illustrate some examples, I think that would be helpful.
Bart Versteegen:Yeah. So I'm thinking around some scenarios I encountered. I think for me, leadership sums it down to being very leadership. Some, some, some, no, I would define leadership as having the ability to be concrete and concise on what you want to achieve and to be vulnerable in how you're going to be doing that. So when I was when I had my last scrum master assignment, one of the first things that I've done was answering in an honest way. So if, in most cases, what consultants do, at least, is they try to deflect, reflect the question. If, if someone comes up to me and ask, well, well, Bart I have this in this scenario, what do you think I should do? Then my consultant answered could be, well, if I had the same question as you, what would be your advice to me? And then, in most cases, the person asking the question we'll answer the question, but that's deflecting, and I have learned by falling on my face quite a few times that answering in meetings that you just don't know something and that you're trying to fix it or find it out into within a week or within a day, opens up entire groups of people, and it opens up a different conversation on being transparent and being vulnerable in a working setting. So leadership within the scrum team is, for me, is all about having the ability to be vulnerable, admitting that you don't know stuff. When you don't know stuff, don't make up an answer or try to deflect it in some way. And as a leader, which could be you could be a leader in a technical role. Being a software engineer, for instance, you could be a leader in when being a tester. Software tester, you could be a leader when you have the product or accountability. You could be the leader when you have scrum master accountability. For me, it all comes down to being concrete, concrete and concise. So as a feed, as a scrum master, if I give feedback, it's concrete and concise. I've seen you doing this and this, and that made me feel this and this way. So I'm having a conversation about something that I've experienced that means for a product owner, for instance, this is the product that we're working on. This is the product vision that I would love to achieve somewhere in the near future, which means two to five years, or a product vision and for the upcoming six months, and this is the product goal that we have. And every stakeholder that comes to me or that comes to you, their developers or scrum master with a request that doesn't add value to reaching our sprint, our product goal will most likely be a no to the question, are we going to put this on our product backlog, yes or no, so concrete, concise and be and being vulnerable. And I think the second part of the question was, okay, what kind of leadership have you seen happening outside of Scrum teams? For me that would be implementing the concept of learning money? Uh, and the best managers that I've worked with as a product owner or as Scrum Masters, I've always had some conversation about, okay, what is the the maximum amount of damage that I can do with my scrum team, which is still okay for you, which is manageable to your stakeholders, what's the biggest amount of learning money that I can invest actually, I think that was, that was the conversation that I had, and that leads to a conversation about safety, that leads to a conversation about learning, and that leads to a conversation about making sure that you focus on outcomes instead of output. And when you're working in an organization that's still focused on output instead of outcome, then what happens is, okay, we want realistic plans, and realistic plans, in our case, means we need to reach or meet every plan that we create. But if you're in a truly complex environment, you don't know what you don't know, and that will also lead to you not meeting the plans that you've created, because you encounter a lot of stuff that's just complex that you don't know. So leaders outside of agile teams, they make room for the teams to learn, and they have a clear answer on how much learning money the teams can spend, and they have a clear answer on what needs to be achieved. And last but not least, they are a vehicle to help the teams forward. So they are the ultimate impediment removers, where a scrum master, unfortunately doesn't have a lot of sway in organizations to to take a position in okay, we're going right, or we're going left. People in a leadership position in organizations, they do so when we're talking about doing an Agile transformation, doing you always need some sort of an sponsor in the management team that can help you remove roadblocks, that can help you remove impediments, so you're the ultimate impediment remover, I would say, with a big bag of money to invest some Some learning spending.
Lindsay Velecina:Awesome. Thank you. I hope that helps. So this next one here in organizations where scrum masses are expected to show tangible impact, what are the most meaningful ways to demonstrate value without falling back on vanity metrics like velocity?
Bart Versteegen:What's the Could you repeat the question? One more time? Sure,
Lindsay Velecina:I read that kind of fast in organizations where SCRUM masters are expected to show tangible impact, what are the most meaningful ways to demonstrate value without falling back on vanity metrics like velocity,
Bart Versteegen:I think that would come up. That would be, that's a good question, by the way, and it's a very good question, yeah, for me, that would combine come down to, are we releasing potential? Are we releasing potential, releasable product increments, every sprint? Yes or No, so are we able to release something of potential value to customers every sprint or on a more regular basis, and are we having an impact on value metrics, whatever value metrics you might have for your product, so it would be based on, Does, does the team has? Does the team have every capability to release portions of value to customers. Yes or No, it's not about planning. It's not about happy people within a team. Of course, that's a big part of your job, and it should be important, but it can't be measured. It's not about lines of code. No, it's about, are we able to release potential releasable product increments, every sprint and potential releasable, dear gentle people, also means that we have the ability to release something that adheres to our definition of done so releasing actual value is always of a high quality. We're not introducing MVPs, which are built in a bad way, and then we call them MVPs, and then it's okay within some organizations. For me, that's not professional software development. That's not pro. Personal product development. Everything that you do release is of high quality. So if you're able, as a scrum master to make sure that teams have that capability, and where you can see, okay, I've been working with this team for over four to six to nine to 12 months. They've in, they've in, they've improved their release frequency. They have maybe minimized their bugs that were being introduced into the software after releases. We have seen customer retention going up. We have seen customer happiness going up. Then I think you can call yourself successful as a scrum master, and maybe at the same time also taking a look at some of the accountabilities, of course, as scrum master, based on how many times you're still asked to facilitate a certain meeting. So if a team, if developers, can maybe facilitate refinements, if a product owner is able to facilitate a sprint review by him or herself, then I think you're moving into the direction of self management. And self management next to improving of customer metrics, next to improvement of release frequency, would for me be a key figure that tells me something about, okay, this team is going to be successful in the long
Lindsay Velecina:run. Awesome. Thank you. All right, welcome. So I hope that helps. Next question here. So, how can we come up with a sprint goal when every team member is working on different projects?
Bart Versteegen:That's a good question. My My first question would be, do you have a protocol? Yes or no. In most cases, when I encounter this question, we have a team, and the team all has different projects to work on, and maybe the team all has different accountabilities. So we have, of course, everyone within a scrum team working on a product is called a developer, but within organizations, those developers also have functions. And maybe someone is a back end engineer, maybe someone is a software tester, maybe someone is a front end engineer, maybe someone is a business analyst. They all are adding value to the sprint because they're being a developer within a sprint, but they are not likely to work together on a single product backlog item. So for me, that would come down to two things. First, think about, Okay, do we have a protocol? Yes or no, if you do awesome, if you don't create one, and make sure that that the product owner that you're working with creates one, maybe you, as a scrum master, should help your product owner in doing so, because if you have a product owner, then it's also way easier to come up with a sprint goal. Then you have the ability to create sprint goals that are not output focused, but are actually outcome focused. So that would be number one, and number two would be, I've thought of something genius, but it just slipped my mind. So, ah, that's that was something that I was planning on saying. Make sure that if you are within that scrum team that has lots of different kind of developers, lots of different tastes, right? So, as I mentioned, the business analyst, front end engineer, back end engineer, make sure that you spend some time on learning each other skills and learning each other's backgrounds and techniques, and I'm not using the proper English words for this, of course, but if you want to be a truly self organizing scrum team, if you want to have the ability to take over each other's work, then you also need to spend some time on better understanding, okay, what is the job of the person next to me? So that would mean that you reserve maybe 20% of the time of the sprint, or maybe 30% of the time to sprint that you're working in on developing your skill set that could lead to front end engineers also doing some business analysis. That could mean that back end engineers become full stack engineers. That could mean that business analysts also starts testing software. And yes, that's hard, and yes, that's not likely going to happen in every organization, and that is down to the fact that most organizations are still focused on delivering feature after feature after feature, or delivering output after output after output. So that means an investment in learning money. That means an investment in not maximizing the delivery of the team, but minimizing the truck factor within the team. Yeah. So that's what I would do, make sure that you have a protocol, make sure that you spend enough time on developing the skill set of all of the people within the scrum team.
Lindsay Velecina:That makes a lot of sense. Thank you. All right, this next one here. So what are some methods to promote engagement in sprint planning and backlog refinement? I The team I am working on is new to Scrum and hands off with planning. There's often issues added during the sprint. Would like to engage them in proactive planning.
Bart Versteegen:Good okay, I'm just thinking about what the problem could be that this person is encountering with the situation. It feels to me like
Lindsay Velecina:the team isn't, isn't really speaking up during Yeah, planning is what I'm getting from or refinement. And then there's things that pop up during the sprint that could have been covered in planning or refinement. That's what I'm getting from it. And if we're wrong, let us know.
Bart Versteegen:Please let us know. Yeah, so if it could be prevented, and it should have been prevented, of course, then that's the signal that you should improve your ways of working during refinement and sprint planning. If it wasn't preventable, then that's just a sign that you're in a complex environment, and that's okay. That's why we use Scrum to find ways that work within our complex environment that we work in. But if it's preventable, then I would focus as a scrum master, on, on not speaking so much and just sitting back just like this. Maybe even advice, crossing your arms and sit on your hands just like this, um, and let the team have the conversation. So make it just a bit uncomfortable, like a we're not speaking for around 20 to 30 seconds, and then, in most cases, someone will speak up, and then the conversation will start. Yeah? So maybe my go to suggestion would just be to shut your mouth for a
Lindsay Velecina:moment, if I don't that's that's definitely something to try. I like that idea.
Bart Versteegen:But then again, if it doesn't fulfill your needs, speak up in the chat. Find me on LinkedIn. We can chat often, absolutely.
Lindsay Velecina:All right, so what should i a scrum master do if they feel ineffective within the team, kind of like an open question, but I imagine this as someone who feels like they just can't make an impact.
Bart Versteegen:Yeah, find another job. I don't know. Yeah, hard, hard to question. Um, if that question would be directed to me, if I would be coaching a scrum master, that Scrum Master would have the feeling, okay, I'm not being effective, I would advise him or her to go back to the team and ask the same question to the team, right? So their their team. What do you think of my performance? Do you agree with this statement that I made. Am I not being effective? Yes or no. So what do you guys think? Yeah, that would be my first step. And then after find out if it's only a feeling or if it's actually the truth, it could be the truth, it could be. And that then that could open you to having more flexibility and freedom to help improve the organization, or maybe take on a second team next to the team that you're working with now, or maybe a third, or maybe even more, I wouldn't advise you to but could be a solution.
Lindsay Velecina:Okay, thank you. And then someone chimed in in the chat too, that said to ask for feedback.
Bart Versteegen:Yeah, yep, ask for feedback. Make it transparent.
Lindsay Velecina:And then somebody else, oh, this is just another question. So if you're dropping just a public service announcement for our audience here, if you're dropping questions into the chat, if you could please move them over to the Q amp a that would be really helpful. The chat is primarily for technical questions or just comments, but we want to make sure we capture all the questions in the Q amp a panel. So thank you for that. So what are the big, biggest challenges with team communication, mainly relationships with product owners. And how do you overcome high expectations? So they're asking what the biggest challenges are with team communication, but I'm going to flip that just a little bit like, how do you improve you. Uhm, these communication issues, particularly with product owners.
Bart Versteegen:Yeah, yeah. We are. We are a strange breed. I would advise you to do something outside the office. So in the Netherlands, it's quite it's quite normal to have a drink, to have a few drinks with colleagues. That would be my go to advice. Spend some time together outside of the office, because in most cases, many of the communications problems that you encounter are then magically solved because you're having conversations on another level. But I also think when when looking at the different accountabilities within a scrum team, a scrum master has a responsibility on making sure that a product owner isn't being seen as a manager or a true leader within a scrum team, so a product owner is not a manager. You're still part of the same scrum team, you just have a different set of accountabilities. And if a if a few of the developers, or if every developer and a scrum master is looking up to the product owner, because he or she decides what we're doing, then you will never have that effective self managing team. So for me, that would be two things, spend some time outside of the office and as a scrum master, make sure that you are aware of the behaviors and the way of communicating and the way how people are looking at the product owner, he or she is nothing more than a team member. He's not your boss, or she is not your boss. It's just a member of the team. What could also help, and that's an exercise that I do in many of my training or workshops, is to do something that I like to call the green and red zone behavior exercise. And that's based around the five scrum values, of course, and we know them by heart, focus, respect, openness, courage and commitment. And what I do in workshops is I put up five flip over papers, or I have five whiteboards spread around a room, and the topic of the topic on that whiteboard or flip over paper is one of the five scrum values, and we have a left side, and we have a right side, and the left side is red zone behavior, so behavior that we won't, that we don't like to see around that value, and the green zone is, of course, behavior that we would promote around the value of, for instance, Respect. And that could lead to some sort of a team agreement on how you guys work together. Yeah, so that's what I would like to advise you spend some time out of the outside of the office. Be aware of how does the team look at each other and and maybe do something like a red zone Green Zone behavior exercise.
Lindsay Velecina:A great suggestion. Thank you. All right, so this next one here. So before I dive into the next question, I want to revisit a question from earlier. A little more context was shared. I don't know if you'll have any additional commentary, but I wanted to share this. So the question originally was, what do you suggest to be careful with or be mindful of, when the role of the scrum master and project manager are combined? So we got a little more context here. I don't agree with this process at my organization. We, as Scrum Masters, handle the initial phase of the project, and once the stories are being written and refined, the product owner takes care of the project, the scrum master is just informed about the project, so they feel like the roles and the accountabilities are all mixed up. So that's kind of more context there for that initial question.
Bart Versteegen:Yeah, yeah, I would agree. It sounds to me like a scrum master is helping a team to start and being some sort of a business analyst, maybe a mini project manager, I think. And after doing so, a product owner takes over, and he or she then becomes accountable for for the project or the product development efforts, and I think, but that's an assumption. So if I'm wrong, I'm very sorry, but I think that's due to the fact because SCRUM masters are being seen as delivery managers within this certain organization. And yes, we could have a conversation about our Scrum Masters a delivery manager, but with a new title, I don't agree with that statement. I think you're a change agent and a coach and a facilitator and a teacher, and that should be your accountability. Your accountability as Scrum Master has nothing to do with a. Project, or how a project is being set up, or the elements or the substance of a prod of a project, that's the accountability of a product owner and the developers within scrum So, yeah, there's still some work to do on teaching the organization what scrum master accountability really is, I think,
Lindsay Velecina:thank you, all right, and thank you for providing more context there as well. Yes, this next one here. So I work in an organization where we don't have product goals, we we just start with a product vision, and now struggle to come up with relevant sprint goals, which I think is due to the lack of product goals, which is something that you referred to earlier as well. So how can I practically help or coach the product owner in finding relevant product goals? Or am I one of the rookie Scrum Masters who tries to follow scrum by the book, too much.
Bart Versteegen:It could be both, but, but then again, I would advise you to coach your product owner into having and creating those protocols. So I think that product owner should have a a conversation with his or her stakeholders about the vision and the strategy of the organization. Product goal is not created into is not created by a product owner in a meeting room and then thinking about, Okay, I have a product, and now I'm going to move this product into this direction because I'm the Product Owner and I'm the CEO of my product. Yes, you are the CEO of your product, but then at the same time you are still part of bigger organization with an organizational vision and a business strategy behind it. So a product owner should know, okay, this is the organizational vision and this is the business strategy. These are the ways that we make money, and my product is most likely going to add value to that strategy. So I would advise that scrum master to have the conversation with a product owner, their product owner, what is the organizational vision and what is the business strategy, and in what way do you think our product adds value to the strategy of our IT department, of our entire business, strategy of our department strategy of on what level you're currently operating, because there needs to be some sort of a connection to the product or the project that the Scrum teams are delivering, And to the bigger strategy. And there's something missing now, currently there. So have that conversation together with your Scrum, or together with the product owner at first, and then maybe have that conversation within a sprint review. You have your sprint review event, you have your stakeholders present over there. Most likely. They are the most important stakeholders that you have, and I hope they can answer the question, what is the current business strategy, and how does this product add value to the strategy that we have? Okay,
Lindsay Velecina:thank you. All right, so we have time here for maybe one or two more questions. There are quite a few open questions, so I will be sure to share these with Bart after the session, and we'll figure out a way to get them addressed. So if we don't get to your question, we will figure out a way to address it in some way, shape or form. So don't worry about that. So this one here, so I'm starting as a scrum master soon at a new big organization. Congrats. From your experience, what are the first things I should focus on in my first few weeks to set myself and the team up for success?
Bart Versteegen:Ooh, beautiful question. I I would focus on what's the amount of time that it takes for impediments to be resolved? And in most bigger organizations, impediments need to be resolved by other people than you. So what's what? What what is the time that it takes for impediments to be resolved? I would at first, if you have the ability to just observe the team and the organization for around two to four weeks, I should so you don't jump in, you jump in on on, putting out every fire, and you start facilitating right away, because you might miss some important information to do your job in a more effective way. So at first, lean back, observe and spend some time gathering information. After that, gather information around the topic of, okay, how much time does it take for impediments to be resolved? What is our release frequency? For instance, what is the connection between our product? Product and the bigger organizational structure and strategy, so does the product owner need to do some more work around that topic? How effective are our scrum events? And do we have everything in place that we need to create value? And for me, the essential elements are, do we have a protocol? Are we able to come up with sprint goals that are focused on outcome, and do we have a clear definition of done that we adhere to? That would be my main focus. So sit back, think about how much time it takes for impediments to be resolved, and then start working with your product owner on strategy and vision protocols, sprint goals and the definition of them together with the entire scrum team. Hope that helps. Thank you. Hope you have a good start. Good luck. Yeah, it's your new job.
Lindsay Velecina:Awesome. You're gonna rock it all right. So next question here, in case you have an unconventional team setup where you are a scrum master working together with an Agile team manager in the same team, how would you make sure that both roles can function complementary, instead of canceling each other out? I
Bart Versteegen:but I have no clue what an Agile team manager is. I don't do sorry, no, I I'm not sure how to answer that question. My assumption is that an Agile team manager would be responsible for everything around human resources, so maybe hiring and firing, maybe promoting people, making maybe the well being of the people, and all of those topics. So you're more, you're you're you're something like a people manager, and then you have the scrum master accountability. And if that would be the case, then I think those two accountabilities could be easily divided. I would, I would be a scrum master and focusing on the effective, effectiveness of the people within the team and the team and the team itself, and, of course, the entire organization, and for the well being of the people, for all of the serious, the more serious and heavy cases, I would work together with that agile team manager. So I've been in some sort of same context within a semi government organization that I've been a part of, where I've been a scrum master, and I had some sort of a people manager working on the team. And something that I did was having, not for every member on the team, but for some of the members of the team, had weekly one on one sessions just to have a conversation about, how are you feeling, are you doing? Okay, do you need some help? Is there something blocking you? And all other kinds of topics, and if I found that there was some topic that we needed some help with, then I would, together with the team member, have a conversation with our people manager about, okay, and we have had this conversation. I can't help this person any further than this now, please step in and help us create more value by removing this impediment. So yeah, that's what I would do. But I'm missing, I might be missing some more context. So if you could elaborate on your question in any way, I would be more than willing to answer it maybe even better.
Lindsay Velecina:Okay, all right. Thank you. Yeah, I was thinking of it along the same lines up. Somebody said you did indeed answer it just the right way, so we got it. Good job. Bart.
Bart Versteegen:Thank you so much. So
Lindsay Velecina:unfortunately, we are at our hour. Thank you so much to our listeners who sent in so many great questions. Usually in these sessions, I group questions together there. There were very few that were like similar to group together. They were very diverse group of questions. So thank you so much. It looks like there's still a few questions coming in into the chat. I'll give you like a moment here to just move them over to the Q and A, because that's the report that I export after this that I'm going to share with. Bart. So if you typed questions that have been unanswered, please add them to the Q and A now, and while we wrap up here, Bart, are there any parting advice or that you want to share with this group and also, the best way to connect with you, I believe, is on LinkedIn. Correct?
Bart Versteegen:Yeah, yeah, yeah. I'm very easy to find on LinkedIn. I have a very Dutch name, and even in the Netherlands, there are not a lot of people who are named barter station. So it's, it's quite easy. I'm quite easy to find. You can also take a look at my. Employers website, which is proerness.com, there you can find me. We are also publishing on YouTube. So if you search YouTube, the video platform, you search for agile BS, then you can find the channel that I've created together with fellow PST, Stas Pavlov. That's the easiest way. So please feel free to connect and to link with me in every any way possible. You can also send me an email. I think my emails out and about in the world, wide, world web. So please do so. And some some advice for for all of the participants, yeah, don't. Don't. Don't make everything too heavy. Have some fun in your work. I think we have an awesome job. We have an awesome community of agile experts all over the world, and it's a fun, fun community to be a part of. So have some fun in your job and do your job properly, but with a lot of fun, it makes getting up in the morning just a bit easier. So yeah, that would be my my last advice.
Lindsay Velecina:Awesome. Thank you so much for taking the time today, Bart, and thank you to our listeners for all the great questions, and we hope to see you at a session again soon. So thank you, everybody and Scrum on you.