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. Oh morning. Good afternoon. Good evening. Thank you for joining us today. Welcome to Ask a Professional Scrum Trainer. I am Lindsay Velecina with Scrum.org and today I have the pleasure of having Sander Dur with me from the Netherlands. He's one of our professional scrum trainers. And he is here to answer any scrum questions that you have. So let's get through some very quick housekeeping items here. So your microphones will be muted throughout this session is being recorded. And it will be made available as a podcast after the session within 24 hours. So please keep an eye out for that. We don't really have any slides. For this session. It's really going to be strictly q&a. So please start populating your questions into the q&a box at the bottom of your screen. You can utilize the chat feature for any technical questions that you have. So very quickly, who's scrum.org we are the home of Scrum. We were founded by Ken Schwimmer in 2009. And our mission is to help people and team solve complex problems. We offer training and certification and professional Scrum. And as I mentioned earlier, Sanders, one of our professional scrum trainers, and we hope that this session plays a part in your continuous learning journey. And we have a lot of free resources on our website, feel free to check those out. Other webinars and things to help you with your growth. And I hope this webinar helps with that, too. So with that, I will hand it over to sander to introduce himself.

Sander Dur: 2:11

Well, thank you, Lindsay. Oh, this happy guy in the picture that would be me. Working at Xebia company in the Netherlands now expanding globally. I'm my my official title is a lead, agile consulted and obviously your professional scrum trainer, or scrum dork, which basically means as much that I talked the entire day, I live in the Netherlands, as Lindsay Lindsay mentioned together with my wife, three kids, two cats, and we recently welcomed a puppy into our home. So on the absolute bottom of the food chain, food chain, so I'm happy to be here to share some of my stuff. And hopefully people will listen, I teach these classes concurrently. Next to this, I have a podcast called Mastering agility. And there is a discord community linked to that I put the link to the discord community in the chat in a minute that you can join. I'm an avid writer on both medium and the scrum that org profile where I share my blogs as well. And you can find me on LinkedIn on there my name Sunday, and they're

Lindsay Velecina: 3:14

fantastic. Thank you, sander. And let's jump into our questions. So I'm going to stop sharing. Okay. And we actually have some questions that came in already before this session. So please, please continue to populate your questions. I'm going to pull some questions that came in yesterday actually in advance of the session. So there's some questions that came in from Scott about the definition of Done. And this first one is just the desk. Does the definition of Done always include everything required to push new functionality to production, regardless of whether you believe all of it can be accomplished within the sprint? Or should it be realistic only including everything that can be completed within the sprint with the goal of continually improving? In this scenario, admittedly, there would be more to do to push to production that would occur after the sprint completes.

Unknown: 4:22

So this sander,

Sander Dur: 4:25

yeah, I think is a very awesome layered question. Technically looking from a professional scrum perspective. Looking at the scrum guide, what the scrum guide says is that the definition of Done means that the increments technically should be able to go into production that should no more work be left remaining in order to go to production. Having said that, I appreciate the fact that that there is a big difference between

Unknown: 4:50

professional

Sander Dur: 4:52

picture perfect Scrum and how the actual world operates. So I was recently in the same situation Somewhere we were one of my teams that I was working with, could not go to production because they had some sign off when it comes to QA, for instance, somewhere down the line in the organization, because It's company policy. This has a lot to do with the self managing ability, what you want to do in that sense, is aim to create the shortest possible feedback loop and try to get the autonomy as much as possible. And maybe base your release schedule on that. So if you have one of these signers, for instance, and same as the situation with Scott, if there's one of those things, hampering you, maybe you want to really base your release schedule on that. So put as much as you can, out there and try to get this work with this as a dependency.

Unknown: 5:47

That's great advice.

Sander Dur: 5:49

Great advice, making it very hard. And I, I would do what advice to try to get as much of that into the actual hands of the team itself. How much can we actually reasonably do? And how much as a from a scrum master perspective? How much do we need to spend on the organizational advice to move that more towards it even though that decision making,

Unknown: 6:13

right? Hey, hope that helps Scott?

Lindsay Velecina: 6:17

Yes. Hope that helps. So this next question from Rhema. I am a software engineer and I newly was assigned the souls as the sole scrum master for my current sprint. I don't know what to do or how to help. So what advice would you give to Rhema?

Sander Dur: 6:36

Okay, so if I understand the question correctly, and feel free to correct me if I'm wrong, you're a newly appointed as a sole Scrum Master, you're there, sort of out of the blue without the experience. At least that's what I get from this question. If you have different perspective, Lindsay, feel free to give me more of that.

Lindsay Velecina: 6:53

That's what it seems like from reading this. Yeah.

Sander Dur: 6:57

So where to start? Ah, wow, this is if you're not trained in this, for instance, or don't know where to start, I would advise starting with observing, don't go into action mode right away. Look at the eight choices of Scrum Master has been going north, hold Scrum, train, mentor, facilitate a coach, actively do nothing my personal favorite, and uphold Scrum. And just start observing. From that point, see what you can do see where you might have some specific observations that you want to run by the rest of your scrum team. But don't go into the action mode right away, because you'll feel like the scrum police. While you're you might not understand the underlying implications or reasoning behind it. So start with observing write some stuff down and create a little bit of an action plan based on that. Bring it back to the team, relating back to self management and transparency and so on. And then start sharing your observations and what you and your team might need.

Unknown: 7:58

Hope that helps.

Lindsay Velecina: 8:00

That's really great advice. It's good to observe what's going on in order to know how to engage. So this next question, this person would like to ramp up their retrospectives. What do you suggest to keep everyone engaged and not falling asleep?

Sander Dur: 8:19

First and foremost, coming in there with curiosity, what is happening now? That is causing people to be disengaged and to fall asleep? I think that's one of the predominant, predominant curiosities that I would have. Do they understand what the retrospective is for, do you know what kinds of things are being discussed and then use go from that point on, maybe reteach again, the purpose of the sprint retrospective, the time logs being three hours for a full month of Sprint usually the little less for shorter Sprint's and let you discuss individuals interactions, processes, tools. And the definition of done now, especially the latter one is something that I rarely see being discussed in the retrospective. Having said that, you can use techniques like teaching from the back of the room, having developers facilitate liberating structures and so on to make this more engaging and more spicy. Hopefully, that gives you something to start off with.

Lindsay Velecina: 9:20

Great, thank you, sander. So this next question, so there's a lot open to interpretation here. But I think you might have some tips for this. Could you please explain some ways to improve the health of a product backlog?

Sander Dur: 9:33

Some ways to improve the health of a product backlog? Where to start? First and foremost, check whether a proper product goal is in place. So that's a commitment to the artifact of the product backlog. Do we know what we're heading what we're advancing towards? Something that we discussed in our conference talk her intense there's always a next sprint. is that you create marshmallow backlogs if you don't know what the direction is and the goal that you're trying to achieve, and therefore, maybe a lot of things can be put in product backlog that do not contribute to the achievement of product or sprint goals, and therefore, stuff is being randomly put on there. While we do not know what kind of value it adds, always refer to this. And that gives you something to plan against, with emergent work as well. So maybe a stakeholder comes in during the sprint and says this is super important, we need to have done right away, you can map this against the product goal or sprint goal, and say, Alright, this does not contribute. So we're not going to do this or it does it does contribute but not right now. So it's going to be on the lower end in the backlog. And the more that you work, the more that the the work is related to the current state or the near future, the more details you want to put in. So the more time you want to invest in backlog refinement. That is something that has been useful to me in the past. So hopefully this gives you something to work with.

Lindsay Velecina: 11:02

Great, thank you so much. This next question here from Jim is about estimation. So what might be the consequences of choosing an hourly time base size estimation rather than Fibonacci or T shirt sizing? How might this affect team behavior and morale?

Sander Dur: 11:23

realm? Not sure. Because that's super dependent on the situation, the thing was an hourly time based estimation, is that you go into the trap of exact estimation. So you say this product backlog item, we're gonna finish that in three and a half hours, just calling a random number up. The probability of this exactly being done in three and a half hours is super low. That's why it's called an estimation, if I would, if I would go to Google Maps, and say, How are Jack how long it takes to drive from my home to Rome, it says 16 hours and 40 minutes, very exact number, timely estimation as well. But the probability and the chances of me exactly arriving there in 16 hours of 40 minutes is minimal to none may have some bio breaks in between maybe an accident happened, I have to charge my car, maybe I want to stop and do some scenic checks. You know, there are so many dependencies and factors and variables that might influence the exact number. So whether that's my drive to grow, or the work that you're trying to predict in this case, and how fast you can do this. The likelihood of you not achieving that in that time, is really high. relating this to Fibonacci sequence or to any other size, time would be one of them, you have time, for instance, but complexity, unknown factors, and predict work. Maybe it's really easy to pull off, but it just takes a lot of time. Or maybe the other way around, maybe you have dependencies on technology people they're not present, and so on. So this makes it an estimation and exact our estimation, tries to normalize that stuff, and does not take into account all these other variables. And that makes it really big pitfall too, not work with estimation and the emergent, emergent nature of product backlog refinement as such.

Unknown: 13:29

That's great advice.

Lindsay Velecina: 13:30

There are a few questions here that kind of tie to this in a way. This question from James, what is the best way to handle rollover items, if not completed at the end of a sprint? If the story is partially completed? Should we estimate? Should the estimate be updated for the remaining work?

Sander Dur: 13:50

No, because it's not done. So there are a couple of things in here. But let's let's address the first and then the latter one, should it be written? Should you have someone go into the next sprint? The work is not done. So therefore if you pull in the negative story into the next sprint, the work or the estimate does not go for instance, your velocity or in that reporting, if you will, you just re estimate. Let's see how to move from that point on there is I appreciate the fact that there has been work done so maybe half of the work has been done doesn't mean that half of those story points go into your into your report because there is no real value in that report. Velocity for instance, in this case, is more of a tool to support your forecast for the coming sprint. Don't focus on getting those details looking back too much because there's nothing that you can change looking back there's more value in looking forward. Alright, maybe we had some spill over into the next sprint. What do we need? What do we need to do with it? Is it still valuable? What happened that it that is there that we're not Having spilled over, do we need to do anything with it? Do we maybe need to put it back into product backlog and reorder it? Maybe we can take it out because we have new emergent insights. But don't blindly spill over things if I'm not mistaking the worst and other aspects to the question. Could you repeat those for me?

Unknown: 15:16

Yes. So

Lindsay Velecina: 15:22

if the story is partially completed, should the estimate be updated? For the remaining work? You already answered that? And what is the best way to handle those rollout over items? Yeah, so that

Sander Dur: 15:34

something that backup you do every estimate of the end of the sprint based on the remaining work, don't put that work that has been performed in the last philosophy because the story or the product backlog item itself has not been is not done, then recheck this this item still hold any value? And where do we need to order it, but don't blindly take it into the next sprint?

Lindsay Velecina: 15:58

And then a follow on question that dovetails into this is what is the best practice for pulling sprint backlog items into the sprint after the sprint has started? Is this acceptable if necessary?

Sander Dur: 16:11

On question, there are no best practices in agile and emergent work, right? Why? Because your situation might be vastly different from mine. And therefore there is no best there are good practices. But there's never best because the best would more infer that there is a methodology that we need to follow. There's more than semantics. If new work emerges, check whether it for instance, if it's what happened today, in our situation, there was a production interrupting issue that was going on. That's obviously something that we immediately need to jump on. So that we can take that we can continue production most important thing is that is not that that situation, see if that work is needed to achieve the sprint goal. And then check if you can do with the current state of the sprint backlog. So if we take this into we have still have this? Do we feel confident that we can still pull off the sprint goal? Or do we need to take something out, if not just not doesn't not contribute to our sprint goal just ordered somewhere in the product backlog. But definitely this is acceptable. The sprint goal is something that we commit to you. It's a sprint backlogs and the scope itself is not fixed. It's not written in stone. And that's why you want to have that flexibility and agility to work with in order to deliver more value.

Unknown: 17:40

Okay, great.

Lindsay Velecina: 17:44

This next question, we'll do one more kind of estimation question, then we'll go into some done stuff. So can you help with a real life example of story point assignment or relative estimate? Someone's looking for, like an example?

Sander Dur: 18:01

Was this good question without going into confidentiality. You know, what I what I usually do with a real life scenario, in this case, it's my training is a, it's a nice way to practice this. So I would, if you can do this on a mural board, or Meelo, or an actual physical board, and I would write some stuff down, like for instance, it got a flood bearish, a pizza, remote control, and some other items. And my goal that I convey to them is I want you guys to throw these objects, one meter, hypothetically, I don't care if they land after a meter, whether that's a meter 50 As long as they crossed that meter mark. Other than that, I'm good. And then do some estimation based on the Fibonacci sequence. So 12358, and so on, you will see that they will rapidly start slapping on numbers without considering Do we understand what the objects are? Do we understand how much complexity is how much time it would take? What kind of dependencies do we have? And putting in isn't such a perspective takes out the perspective of their work because their bias towards the work but that gives some a whole different perspective, identify the easiest object to throw a meter, and then start relating everything to that one. You can use the numbers multiple times from a for instance, with a cat, I write them with capitals on purpose, because I do not mean a cat like a living animal. I mean, a caterpillar machine, like one of those heavy duty machine, but they'll immediately start saying, well, the cat's gonna scratch me. Well, why? What kind of assumptions do you have? Well, it's a living animal now and that's not what I'm at. Because you're basically because you go into so many assumptions right away because that's the way that we think they'll be opened in there. They have eye openers, and thinking maybe this is something that we need to do with our work as well go through it properly. This discuss what this means what we think it means and whether we are on the same page. This is something that I have experienced helps a lot in making this more transparent and how to use this kind of estimation, not necessarily work items related, but it's a creative way and has a bit of a funny gimmick to it. And that helped me personally.

Unknown: 20:21

It helps you to

Lindsay Velecina: 20:22

Great, thank you. Just a little announcement for attendees here. So it looks like some of you dropped some questions into the chat, she could please move them to the q&a panel, that would be really helpful because then we can capture them. And then any questions that we do not get to, we can share with Sander after this. So please make sure you move your questions from the chat into the q&a. Okay, so this question. So from Jamie. So speaking of definition of Done, do you have any suggestions for a process that the team can follow to make sure every story meets the definition of done?

Sander Dur: 21:02

Great question. Good to see here, Jamie. Jamie has an awesome podcast as well, Scrum Masters of the university, check out your podcast as well. Um, you process that the team can follow to make sure every story meets the definition of done now there's a little nuance that not necessarily every story has to meet the definition of done, but the increment itself that has been created would be the definition of Done. So maybe has very code heavy product backlog items, let's say some Java, if there's something related to UX work in your definition of done, you don't have to specifically get that stuff in related to Java. So you want to make sure that the increment itself and here's the definition of them, there's no specific processes just start small. Think about how with the current state of skills that we have the current team composition, what kind of activities do we need to perform in order to make sure that we delivered proper quality, and you can do check out the definition of Done eco cycle I actually own SHA is based on liberating structures. And it's an it's a nice way to start to have you think about how to improve your definition of Done. But by all means, do not go into individual story level product, minimal product backlog item task level definition of done, because that's going to create a big leeway for you to really get stuff done. But think about the increment. And as long as the increment is, is adhering to the definition of done, then you're good.

Lindsay Velecina: 22:43

Great, thanks. And this question is about sprint review. should only the done items be shared during this meeting? What are the cons of showing those that are almost done?

Sander Dur: 22:58

There is no value in items are almost done. So just show what has been done. So I've seen teams go through individual items, just show the increment show make transparency, the current state of the product, how the new increment is working together with all previous increments, but don't go into individual items, don't I? Personally, I don't think there's a lot of value in going through of this, these items we have done through this sprint. But the product, a new part of the product in the hands of the customer is of the stakeholders as much as you can. And that's where the value is. That's where you want to get your feedback from. Maybe if there are some things that you have learned in the past sprint that influence the way that you work with your stakeholders. Sure, that's something that you want to go through maybe on a specific story, minimal product backlog item level. But there is no value in showing stuff that's half done, because the stakeholders cannot use that. And then you're spending a whole lot of time in maybe questions like we have, why isn't? Why is this not done? You forecast this so it doesn't add any value? There's no point in discussing stuff that's not done.

Unknown: 24:13

Great, thanks.

Lindsay Velecina: 24:14

There are a few questions that are coming in around metrics. What metrics can be used for the scrum team velocity is not much of a help. Again, this question was what are the metrics we can use for scrum team just in general? Philosophy is not much. I just talk about metrics in general, because I think there's a few questions that had come in about different metrics.

Sander Dur: 24:40

Sure. The first thing I always point to when it comes about when it's about metrics is check out the evidence based management framework created as well by scrum Nador. And talks about four areas or key value areas being current value unrealized value, ability to innovating time to market. And there are numerous suggested metrics that you can use. It doesn't show exactly how to implement those. But it gives you a very easy way to start off with measuring stuff. And it says a lot more about the actual value. I was talking to this big retailer in the US. And a couple of weeks ago, when I asked them, What do you define the value, for instance, and they said, well, whether things have been delivered on time and within budget. This does not hold any value. But how do you make that valid and transparent? How do you measure value? How do you ensure that you know that you're actually doing the right stuff, and that you learn something that you can improve from? I've been working with large organizations in the past, where I've implemented evidence based management, and just started off with a couple of very easy things to measure, for instance, the employee satisfaction, and the stakeholder satisfaction based on scale from one to 10. That was the current value checksum and realized value. So what's the desired state if the out of out of one to 10 scale than being the best? Currently, the stakeholder satisfaction is a six, and they would be happy with an eight, you can have a discussion? Like what do we need to get from a six to an eight? What kind of activities what kind of features would you need for us to get to a to a state of an age for the product itself. And from that point, you can start measuring or checking, take some actions, putting in place other metrics. So if we were to get from six to eight, maybe we need to do something about our ability to innovate, maybe we need to speed up our ability to deliver, maybe we need to get to production faster. So create a bigger release cycle a faster release cycles, how fast are we able to learn? So we get some feedback from our stakeholders and from our users? How long does it take, so that we can actually implement these kinds of lessons. The evidence based management framework to me makes it very easy and transparent, to start measuring stuff in the very low key way without overwhelming the stakeholders right away. And I think it's super useful to put these metrics out in your sprint review as well, really relating this back to that to the previous question.

Unknown: 27:17

On undone work,

Sander Dur: 27:20

these metrics would be more useful to actually demonstrate and discuss during your sprint review together with the increment, and you create a very powerful dynamic in the sprint review is more of a relationship based thing than just for the stakeholders to sit back and soak up knowledge that you're trying to demo. So it's not becoming just a demo, it's actually becoming an a very interactive working session based on these metrics as well because it gives us something tangible and not gut feeling to work with. So hopefully, this gives you guys something as well to start working with to start measuring with and I can highly recommend it. There's a lot in the professional agile leadership evidence based management course as well on this, which I can recommend as well digging into,

Lindsay Velecina: 28:03

yes, this is great. I dropped a link for the audience as well to some resources that we have on our website about EBM including the EBM guide. So feel free to check those out and have a look at those metrics and guidelines. So a couple questions here around kind of geared toward the new scrum master. So I'm going to kind of list all three of these standards and you could probably have like a collective answer for these. So what would be your advice for a beginner scrum master? And then this next one is instead of a question on how to solve something I would like to know more about you. How would you approach the training of new people to become a scrum master? Do you follow a certain plan are tailored to the person's need?

Sander Dur: 28:59

Okay, let's start off with the first one like Victor, what would your advice be for beginning Scrum Master I. My advice is something that I've mentioned before in this in this webinar, start observing usually the first thing they do in the new assignment or advise beginning SCRUM masters to do is just sit back a bit and observe what's going on. And as well as things that are not going on What do you see is happening? What kind of things do you hear are being mentioned? And how does this relate to the body language that people are having. But this gives you more input on the levels of psychological safety for instance, or to go through the product backlog and see the current state of things just observe list your list your observations. Also go on walks with your, with your team, with your stakeholders and see how they feel about the current state of development about the current state of the product, but the current state of the team, but usually what I've experienced is that people When people aren't taken outside of their regular workspace, they're more inclined to talk in the in the more of a free mind because they might feel a little bit

Unknown: 30:11

limited

Sander Dur: 30:13

to to discuss any kinds of things that they might be able to do so outside. So observe and take walks with individual people. My advice for beginning Scrum Masters.

Unknown: 30:25

That's great. All right, next one.

Lindsay Velecina: 30:32

The next one was around training new people to become the Scrum Master. Yeah, do you follow a certain plan or tailor it to the person's need.

Sander Dur: 30:45

So do things. In the PSM course, I think that's one of the most fundamental things. And this sounds a little bit like selling our own stuff. But that's actually true. And that's the same because as a scrum master, you are a leader in certain leader leadership position in the organization. And whether and I don't mean leadership, as a manager and manager could be a leader, but a Scrum Masters and neither product owner is a leader, but you cannot lead if you don't know how to lead and what to lead in, you cannot leave something that you do not understand. So take a course understand what the framework is about. I've seen SCRUM masters that jumping out of the blue and have no clue how the scrum framework works. So take a minute, take a couple of days invest that time in taking this taking this journey on. Now other than that, there's a difference between what I see as teaching and in the professional environment as well as mentoring. Usually, mentoring is a combination of coaching from having the other person find out his or her own answers, as well as me conveying my experience. That's what I've done. Maybe this helps for you too. And do a little bit of teaching. Like what I would do in a professional scrum master course, is how the scrum framework works. So it's a combination of both. From that point, I would start seeing individual needs because there is no tailored approach. Maybe your ability to retain knowledge or retain and apply the lessons that I give you might be vastly different from what I would tell Lindsay no offense, Lindsey, but there might be a discrepancy in there. So based on that, I will tailor my approach to the individual needs of the person that I'm working with.

Lindsay Velecina: 32:29

That makes sense, everyone has different contexts. So this next question also dives into the scrum master stuff. What are the challenges faced by scrum master? And how can you resolve these challenges? So maybe let's like a few common things that come up that a scrum master has to work to resolve.

Sander Dur: 32:51

The biggest challenge usually is what do you do all day? What does the scrum master do? How can we make this transparent and make this measurable? Well, it's really hard to make measurable like you cannot tell the exact amount of code that are quality code that has been delivered, making measurable the effective scrum master or the success of Scrum Masters by measuring the growth and the success of the scrum, the wider scrum team and the successful delivery of the product. I think that's that's the biggest, biggest challenge, as well as another challenge that I see is that many SCRUM masters are just limited to work with the scrum team itself and not beyond beyond beyond those boundaries. Whereas the scrum master is accountable for working and coaching and guiding the entire organization, the wider organization in the adoption and working with the scrum framework. So be that managers are still in position that are struggling to wrap their heads around. What is my current role in relation to the new scrum team? stakeholders who wants to know how to engage with with Scrum team? Should we stay out? Should we just approach them? How do we work with this, but also defining what we see as self management. You know, many organizations I've worked with sort of juggling the bucket when it comes to autonomy. They'd say, well, you're now a scrum team, and you're autonomous. So good luck for that. And it's the same with when I teach my kids to ride a bike, I can I give them a bicycle without proper training wheels and say good luck, see your grandma, because you're gonna it's gonna be a horrible show, and they will never want to ride their bike again. And that's the same with autonomy. If the autonomy has not been discussed in that, what do we mean and guide them into a state of self management, they will fall they will fail and they will point fingers at Scrum. So scrum doesn't work. You know, if you're not going to get the proper foundation, know that you're going to build a house on quicksand, it's not going to work. So those are common, few common challenges that I see as a scrum. Most.

Lindsay Velecina: 35:02

Yes, definitely. And there's another question here that came in around the whole self management self organization topic. Can you elaborate a little bit on how you balance between self organization and supporting a team, depending on the maturity level of the team, we recommend?

Unknown: 35:25

Do I recommend all right, cool. Um,

Sander Dur: 35:29

a couple of things here. This is where the work of a scrum master becomes really tricky, and requires you to have your interpersonal antennas, if you will, you got to be very responsive to what's being said, what's not being said, and how they how the scrum team works, and how to convey messages and how to coach and guide them. There's a very nice exercise in the professional scrum master. And the product owner deck as well. And of course, is to define what you see as a really good operate, and really, the characteristics of a really good team. So if you do this with your team, what do we define and self management? But do we define as being a really good team, how we like our Inter team culture to be? And you have something of a goal to measure yourself against? How far are we off from that desired state? How far are we off from our definition of being a very good team? And then you can start working on that? Don't, as my colleague, Tom always, nicely puts it, don't try to boil the ocean. Start small, start defining small steps. And again, how do you get from six to an eight and from an eight to attend and so on? How do we create our a team, without without instantly trying to transform from today over tomorrow, start small, make that snowball effect. And ultimately, that's going to generate so much more power and skin in the game, if you will, than just throwing this overboard, since from now on. You're self managing. Enjoy.

Unknown: 37:12

That's great.

Lindsay Velecina: 37:12

Thank you. So we're gonna shift gears a little bit gonna talk about goals. So how do you help your product owner determine a sprinkle when your sprint backlog is a long list of unrelated work items? This is an infrastructure team that focuses on website reliability.

Unknown: 37:32

Interesting. So

Sander Dur: 37:36

I bet there is a correlation that you can find what do we define as reliability? What do we? How do we want that to look like what do we have? Maybe you have any service level agreements, for instance, that are being put into place? And how far are we off from those, bring your customers into that conversation and what and start working with what's the most important thing that we need to work on, I don't know, loading, speed optimization, lowering the amount of heavy picture that has been used, and so on, and then start working from that point on, then it's more effectively, that gives you more leverage to start working with, I'll give you a different example. I used to work with a very large sports equipment, retailer, and let's keep it at that. And they had, they were building really awesome dashboards that were used by many physical stores as well as the online store. And one of their hearts was the reliability and such and the loading speed of the dashboard. And they were struggling with this as well, like the backlog was a little bit in cohesive, if you will, and the product owner came in. And he discussed the objective that he would like to have received by the end of the sprint, he said, I would like the loading speed to be 80% faster by the end of the sprint. Obviously, 80% is very ambitious. And then developers started asking questions and starting to relate this back to them to the product backlog of what they think is achievable within the sprint. And ultimately, they pulled in some work. And they said, Well, dear product owner, we don't think we can do 80%, we think we can do 10 And the product owner was challenging back a little bit, we need to get more 10% is not I think we can do more based on what I've seen you guys do in previous sprints. So ultimately, they created the sprint goal that was to elevate or to raise the loading speed or lower the races, whatever, make it more efficient by 20%. And that's how they started working with this is the goal that we have the product backlog is to have the product goal was to have a proper, smooth experience a seamless experience for the stakeholders for the users of the dashboard to gather all the information that they would require for them to do their business. The first thing that was hampering them the most was the loading speed of the dashboard. So they defined this as a product goal that we have the is what we're trying to achieve overall. And this was what is going to help us get there. Fastest. I think that's the closest I've ever been to this situation described in this question. And I hope this helps a bit.

Lindsay Velecina: 40:14

Great, thank you. Someone asked a pretty, pretty broad general question. But I'm sure others are wondering too. Do you want to share some of your experiences working with product owners? I'm assuming this is from the scrum master perspective. But if it is not, please clarify this Victor.

Sander Dur: 40:38

Some experience of me working with product owners, or there are so many really depends on the person on the way that they have been empowered by the organization, I think, I think I hold the product owners that I've ever worked with, there was only one it was completely empowered has been described in the growth as a product owner, as in the pspo material. So he would be accountable and responsible and empowered to make decisions on everything back from from beginning to end, and complete budget decisions. And he would not be you would not need to have physical signups or any budget requests or whatever. He was the only one who could do whatever you wanted with the product. And he was had a good relationship with a team that took him years to build. Other than that, I've seen product owners struggle, even though they were they had the best characters characters in the world. I've seen other other product owners who were sort of new to the game, and were more of a project manager. And were struggling to wrap their heads around how do we create such an empirical approach to things now do inspect and adapt based on emergent insights. So it really depends on the person, the culture set by the company in the way that companies Empower product owners. What I often see is that even though we have now chosen to do Scrum, organizations do not necessarily understand the complete implications for the for the for the organization itself. So they don't think about what do we need to change in our organization, for instance, in decision making power for product owners, and what do we need to change for that? So it really depends.

Unknown: 42:20

Okay, thank you.

Lindsay Velecina: 42:24

Do you have any ideas for getting people more engaged in a virtual setting? No. No, it's even in this very fully virtual world for a while now. But I think that's still something that

Sander Dur: 42:42

teams struggle with. Yeah, and I think the key word here is teams and how they want to work. I've seen so many organizations say, Well, you have to come into the office two days a week, and you have to work virtual two days a week, this is something that you want to put to the teams, how do we want to work together? Because maybe my team enjoys working physically, while your team over run, the dork might benefit a lot more from doing virtual stuff. And maybe they are more comfortable talking to each other, just with their, with their cameras turned off. Personally, that's not for me, I like you to see people's faces, because that gives me feedback as well how people feel, how engaged they are, and so on. But again, that really depends. I've worked with this organization, that really large organization over here in the Netherlands to make semi conductor conductor fabrication machines, that and those were very introverted people, like a lot of them. And then when the pandemic hit, they were super happy that they just could work from home and they would not be able to, they wouldn't have to talk to people. And they've thrived on that the quality of their work just skyrocketed. So it really depends, but bring this to your team. How do we want to work together? How do you think we should work on this situation?

Unknown: 44:00

That has a lot to do with self management as well.

Lindsay Velecina: 44:03

Yeah, definitely. Definitely something people still struggle with. So this question, kind of an organization type of questions. What suggestions do you have for working in a large organization that has waterfall initiatives and timelines, but an Agile team, the initiative, or the initial, I'm assuming you met, expectations are for the agile team to complete dev work early, but they don't plan on providing test data and testing for a couple of months.

Sander Dur: 44:42

Yeah, so this feels always like a little bit of a facade way of doing Agile. A team is expected to do Agile, but the environment doesn't change and therefore you create a massive dependency and float. So the team if they would be empowered And the origin, the organization around them, environment around them will actually change with them, the output could be so much better than when trying to fight the waterfall approach. I mean, when it comes to deadlines, deadlines will always exist, right? There will always be something some point that we want to aim towards. And deadline, by the way, is a funny term anyway, because he was going to die when you don't make that deadline.

Unknown: 45:24

Having said that, no. It

Sander Dur: 45:29

challenged the organization back on what do you expect of us as as a as an Agile team as a scrum team with the environment does not work with us, you're creating more impediments for us to work against them, that you're allowing us to actually deliver something that's a value. And what do you expect is going to be the output? Are we now a glorified feature factory? Because we cannot do the actual testing? Or do you really want to get some something out of this? I think that's, that's, that would be my main thing to start off with. And I've written to appreciate that is a very tricky fact. But you know, you're setting yourself up as an organization for failure, if you expect just a scrum team or an Agile team to be agile, while the rest is still agile, like Iraq.

Lindsay Velecina: 46:20

Right? What are some things that this person who asked this question could do to try to convince

Unknown: 46:29

their organization that this is not the best way to work?

Sander Dur: 46:35

convinced the organization that the Agile is not the best way to work,

Lindsay Velecina: 46:39

know that the waterfall kind of facade of Agile way? Yeah, is that the best way to work? What are some ways that people can kind of convince or prove that Agile is the way that this should be working?

Sander Dur: 46:58

I would like I always like to list all the dependencies that are in place, or the the variables, if you will, that we need to take into account and how predictable that they are. And the less predictable that they are, the more of a flexible approach that we need. So if you have more of a waterfall approach is more rigid. That just renders us unable to actually effectively work, create work that is valuable. And therefore we are creating more of a more fluff and organizational wastes than when we wouldn't have the ability to pivot based on the emergent insights. And that has a lot to do with that. But also think about what is the issue that we're trying to fix? What's the problem that we have as an organization? And what's the best approach that we can try to tackle this? Because I see many organizations implement Scrum, or agile or whatever framework that you want to use, because it's been mentioned on LinkedIn or because my neighbor says they're doing Scrum or whatsoever, but not thinking about what what kind of issue are we really trying to solve here? And what options do we have that might help us remove that? So and if we think Scrum is is going to be one of those frameworks that's going to help us remove or get to a better state? What kind of changes do we need to make? Are we going to create a waterfall situation or a hybrid situation with waterfall and Scrum? How are we going to do this as optimal as possible? And what kind of changes do we need to make in the organization whether that's structure hierarchy, ways of working culture and so on? But I think that's the that's the predominant question that you should be asking yourself as an organization, what changes do we need to make? And how do we effectively set us up for success?

Unknown: 48:49

That's great. Thank you.

Lindsay Velecina: 48:52

This question here? It starts with true or false. But should management be excluded from the retrospectives so that the team has open and honest discussions and a safe environment is created for this discussion? Are there circumstances I'm adding on with my own question here? Are there circumstances where you would want the management to be a part of a retrospective? What's your take on this question?

Unknown: 49:22

So true or false? Um,

Sander Dur: 49:26

depends. There's a little bit in between. So there's a little gray area. Scrum guide says the retrospective is for the scrum team itself to inspect itself. And I think there was a little bit of a nice, we had a nice discussion on this with a couple of BSTs a couple of weeks ago as well. Should we eat or could we get management on board? Personally and the scrum doesn't say anything about this, but this is my personal perspective. If the relationship with management or leadership will improve and therefore the they're in the middle It's easy for the scrum team to deliver value with improved, you could invite them. Maybe for a little bit little part of that Sprint Retrospective. Again, the time box for the Sprint Retrospective is three hours. So you have a lot of time to discuss stuff inside them for a specific part, whether that's leadership or any other person or group of people that you're working with, in order to improve your ways of affectivity, as well as your ability to deliver quality stuff. And then maybe dismantle again, and go back in your scrum team itself. But it has a lot to deal with levels of psychological safety as well. If you do not feel confident that you can speak up when other people are present, or when management is present, then how transparent can you be? In other words, how can you act effectively inspect and adapt if you are not able to be transparent about anything and everything in order to improve the situation? So coming back to the question, could we invite could management be part of it? Yes. Based on invitation, not if they say, Well, I have some really important observations, and I think it's gonna make you more effective. So I'm going I'm joining your sprint retrospective No, just based on invitation, because that supports self management, if

Unknown: 51:18

that makes sense.

Sander Dur: 51:20

I'm glad that makes sense. I'm

Lindsay Velecina: 51:22

glad to. So this question from Sue. We only have time for maybe a couple more questions. Maybe one or two. What is the best way to effectively manage multiple Scrum teams at the same time? And how can a scrum master manage their commitments for these teams?

Sander Dur: 51:41

Um, well, you don't because as a scrum master, you do not manage Scrum teams Elish would be a project manager or ID Manager. Now, having said that, you can see a scrum master as a management position in the sense that you manage the scrum framework. So try to get go. But you can as a scrum master, you can oversee the whole and how to optimize the way that Scrum teams are working together. If this is a scaled effort, so you're working on the same product with all those teams together, ensure that there's going to be only one product owner ensure that there's going to be one product backlog where all these teams pick from ensure that they discuss things together. So that's transparency on the whole effort of delivery. But you do not manage the scrum team. This is for the this is for all the Scrum teams, and the altogether to inspect themselves to inspect the ways that they work together the that how they deliver their product, and therefore there's only one definition of Done. But have them figure out their own solutions and support that discovery and that ability to self manage because else, there'll be just, they'll just be executing your solutions, instead of growing by the nature of their own discoveries.

Unknown: 52:59

I hope this helps a bit.

Lindsay Velecina: 53:03

Thank you. We have time for one more question here. So this question from Olaf that just came in? Is the scrum master supposed to work with stakeholders? It's does the scrum master totally leave that up to the product owner?

Sander Dur: 53:19

It depends. Because as a scrum master, you are accountable for guiding and working with your product owner as well. And if you have let's say you are a an experienced Scrum Master, you have an inexperienced product owner for instance, you can help them get up to speed on how they should effectively collaborate. How do we do the stakeholders engaged with the product owner or vice versa in order to get a healthy product backlog state or to drive the emergent insights or how the voice of the stakeholders is very important. So the other day I was teaching an APS class in London and there was a question as well, like we are so disconnected from disconnected from our stakeholders. What do we do and I found out that this was a team that sort of had a product owner but not very explicitly, but it definitely did not have a scrum master. And this is where a scrum master would come in overlooking the whole perspective of okay, we are doing Scrum. We have the scrum framework in place, please, we made a decision or we're not engaging with our stakeholders, you the product owner are accountable for maximizing the value of the product. How can you do that without actually engaging with our stakeholders? So let's figure out a way a strategy how to get this more up to speed and into place. So that is how you could as a stakeholder or as a scrum master work with stakeholders as well.

Lindsay Velecina: 54:45

Okay, great. So I don't think we have any more time for questions we as case you didn't notice, we tried to move through as many as we could as quickly as

Sander Dur: 54:56

we could not recover 20 Do not cover 20

Lindsay Velecina: 55:00

too. So we do have 53 open questions, I'm going to share these with sander to figure out a way. And we'll figure out a way to address these in another way after this session, and a heads up that, again, that the recording of this will be made available within 24 hours. And I'm going to just share my screen again really quick.

Sander Dur: 55:26

If I can interrupt a little bit quickly, maybe if you have more questions, and you want to challenge the community on this feel free, I'm going to drop the link again, do the mashing agility discord community link drops in the chat? It's a growing community. It's a group of pretty cool people. Hundreds in there currently, but feel free to use that and to ask any questions in there, too.

Lindsay Velecina: 55:50

Yes, that is a great place to ask your questions. Something that I did want to mention here quick is that we do have a bunch of learning paths on the scrum.org website. So please feel free to check those out. We have them geared toward product owners, developers, Scrum Masters and leaders a bunch of self learning resources to help you on your learning journey. So please go ahead and check those out. And please stay connected with the scrum.org community and we have a forum of her own as well. So feel free to post any questions in there. That's a great way to connect with other scrum practitioners. Please stay connected with us on our social media channels. And we also have our blog with some great insights from our professional scrum trainers like sander. He has quite a few blogs on there that are quite interesting. And we also have our scrum polls webcasts that we run on a bi monthly basis. So please feel free to check those out at scrub that org slash webcast. So thank you everyone for joining and thank you especially to you sander for sitting in the hot seat and answering questions from the audience. And I hope this was a great use of everybody's time. And thank you all and Scrum on.

Sander Dur: 57:16

love being here. Thank you very much for having me, Lindsay and thank you guys for the awesome questions. Loved it.

Lindsay Velecina: 57:22

Take care everyone