Ask a Professional Scrum Trainer - The Power of Facilitation Skills to improve Scrum Events and other Scrum Team interactions

Scrum has been in existence for more than 25 years as a simple framework for effective team collaboration on complex products. While it is lightweight and simple to understand, it can be difficult to apply effectively. The Scrum.org Ask a Professional Scrum Trainer series features Professional Scrum Trainers (PSTs) in a live session, answering your most pressing questions regarding the challenges and situations your Scrum Teams are facing.

Great Scrum Teams are self-managing, cross-functional and have the ability and skills necessary to drive to successful outcomes. However, team interactions don’t always go as expected and can cause conflict or roadblocks. Effective facilitation can help the Scrum Team move forward toward their desired outcomes. Within the Scrum events and beyond there are a lot of opportunities where good facilitation can help teams work better together.

In this episode of Ask a Professional Scrum Trainer moderated by Patricia Kong, PSTs Simon Flossmann and David Spinks answer your burning questions about Scrum and the challenges you or your teams may be facing when using Scrum, particularly within the Scrum events and other scenarios when it may be difficult to reach a decision on things, that could be resolved with good facilitation techniques and skills.

 

Transcript

Patricia Kong: 0:05

Hello, everyone welcome to Ask a PST professional scrum trainer. My name is Patricia Kong. Today I have with me Simon Flossmann and David Spinks - Hello So, today we're gonna talk about the power of facilitation and how we can use that to improve the scrum events and, and other interactions that you might be facing in Scrum and Agile environments. And before we get started, just a couple of housekeeping rules quick guidelines. As usual, your microphones will be muted. Throughout this session is recorded, and the recording and slides will be available for everyone after the webinar within 24 hours. This is Ask a PST, So make sure you're submitting your questions through the q&a. That's how we'll be seeing them. I'll be moderating today for us. So just a quick reminder on who is swarm node orcs. from.org is us were a global community, thinking about training education in the Scrum and Agile space. So that handsome gentleman in the left that's Ken Schwaber, he is the CO-creator of Scrum and the founder of our company and an inspiration to me every day. So, David, why don't we go to you with a quick introduction of yourself?

David Spinks: 1:33

Sure. So my name is David Spinks, I'm based in the UK. My background is in software developments. I did that for about 10 years before I discovered Scrum and the Agile space. So I've worked over the last 12 years or so as a scrum master product owner Agile coach. I've been a scrum.org professional scrum trainer since 2019. I'm also an accredited trainer with Kanban University. So I trained the Kanban method. And I offer my services through my company with tangerine, which I co founded a few years ago. I'm also an author, author of the books adopting agile across borders, which is all about use of agile in different parts of the world in different cultures, and upcoming book, which is due out any any day now in different parts of the world, mastering collaboration and a product team, which is all about different collaboration techniques to build great products.

Patricia Kong: 2:29

So that's me. Congratulations. I'll expect a signed copy. All right, Simon.

Simon Flossmann: 2:37

Me too, please. Yeah, my name is Simon. When I started working, basically, I started as a product owner, I always was looking for ways on how to collaborate with stakeholders, and basically li let them do the work. That's the way I discovered facilitation. I started to collecting all the tools and techniques which are helpful to let other people do the work and just try to help them to come and outcome. And one day I was running and retrospective, I think it was pretty good. We used I don't know, like 10-15 techniques whatsoever. And after that, my mentor at that time asked me, oh, if you run so great retrospective. How is your tool team doing you? Are you delivering a lot of value to your customers and users. And I said, Hold on a minute, what you're talking about users customers value, we don't deliver it all. And that makes me realize, at the end of the day doesn't matter what techniques you use, what tools you have, and how many, it's about the outcome, what you achieve with those tools. And from that day on. I'm looking for the simplest version to get to an outcome. And hopefully I can share a couple of lessons and examples throughout the date. That's me.

Patricia Kong: 3:56

All right. Excellent. Thank you. So David, and Simon and I have collaborated together on a new course that discriminate org just launched and that that class was the class is the courses around facilitation skills, and we thought about it specifically in the realm of a scrum setting. So in that course, in that class, you'll find a lot of different scenarios that we've experienced, coaching, training, consulting, being in Scrum teams or in an organization. So we're happy to take some of those questions that that you have in terms of some of the typical things that you're facing that you want some advice from us. One of the things that David Spinks and I just did recently was a webinar on the notion of alignment and facilitating conversation. missions around alignment that we think there's alignment. But but, you know, at the end of the day, everybody kind of retracts. And we don't agree. And we've talked through why is that? And so we had a lot of questions. And one of them I'd like to carry forward was really around this notion of a goal. So for instance, when you're in sprint planning, and instead of asking David, I'm gonna ask Simon, because he likes he likes hard questions. How do you how do you think about facilitation? And the team? And what could what could be improved when you get into the situation where you're in sprint planning, and the team gets to the end, and they talk about all these things, and they just can't agree on a sprint goal. And the dynamics that you have in there obviously, are the different accountabilities, right, and the different values. So you think about commitment, people can agree to a goal. What does that mean? You think about product, the product owner? Should the product owner say, Hey, this is the goal, we're moving forward? I've certainly done that. So what do you what do you what is your suggestion? And how do you think about that in terms of facilitation?

Simon Flossmann: 6:09

That's an interesting one. I had this a couple of times. So it was exactly it's how it written in the scrum guide as the product owner proposes a sprint goal. And more or less the developer commit to it, which is not true. So the scrum guide, more mentioned, said the whole team committed to the goal. And that team, it was like that product owner proposes a goal, and the team or the rest of the team has to commit to it. And it never lasted long. And most of the time, the sprint planning took ages, and none of them really committed to the goal, because everybody saw Okay, that's not feasible, that's not doable. And one way I changed this was, it was a tough idea. I asked everybody at the beginning of the planning to come up with a sprint goal, not just the product owner. So we had 10 people in the team, then we had 10 different goals. And now we looked at so how can we converge those different goals? So where are the similarities? Where are the differences and why? So we spent a lot of time thinking about the goal. But on the long run, this helped the team actually to own the decision, which resulted more in a commitment towards it. A one structure you can use here, for instance, I guess everybody knows this one is this one to four, where you give everybody a minute and silence to think about a goal, then come up, pair up with other person, try to combine those goals or refine it even more and then enforce sums. So you can really click quickly generate two to three goals. And that's something you can start with.

Patricia Kong: 7:55

So starting with that, so you talked about liberating structure once and for all. And that's a great way they come in and, you know, let's, let's, let's, let's assume there's a safe environment. It's not about oh, we're coming up with this goal. Nobody really cares what I say anyways, let's remove some of that, that that environment needs to exist. That's a different conversation, maybe. And if there's more questions about it, we can answer that. What happens when you end up with those 234? Or five goals? Or three goals? Because we talked to the converging? How would How would you decide which one then is the sprint goal? Because the other thing that you can end up that we're familiar with? Is a list? Yes. David, do you want to take that?

David Spinks: 8:48

Yeah, that's certainly something I see a lot. And even going so far, where some Scrum teams might bring in seven product backlog items into a sprint, and then they're making each one of those sprint goals? Well, that's something I've seen a lot. Just a very simple question I would ask that group is, what's the most important? What's the most valuable one out of those goals? Because in Scrum, there's nothing that says we can't work on other things. We just need to create that focus on that one thing. So that'd be my question. Out of these goals that we've identified, as a group, with the product owner collaboratively, can we decide what to decide what is the most important what's the most valuable? That's our sprint goal, everything else is a bonus. So we can still bring that into the sprint planning. We want to create create that focus on that one thing. Why wouldn't want to see as this just mash up to and then combine this big long goal when we're having to write a paragraph to describe it. Because again, we're losing that focus.

Patricia Kong: 9:44

Well, David, that's that's that's nice that you mentioned that because one of the follow up questions that we're getting and we're asking a PST is how do you how do you form a sprint goal? What is the difference? I'm going to just change this a little bit from the guest. Question, how do you how do you what's the difference between a an okay sprinkle, and a great sprinkle or a bad sprinkle and a great standard. So you're just talking about a paragraph, not a great sprinkle. Because a lot of the, the that and how we how we plan and how we work towards things, that's going to dictate, that's going to dictate the daily scrums, that's going to dictate all these other things that we have to facilitate. So David, first maybe, and then Simon can give an example also

David Spinks: 10:32

think one of the important things, probably the big important thing, but one of the big important things that came out of the latest version of the scrum guide was the was the product goal. So having that clear vision from the product owner, this is what we're working towards. This is the vision for the product. So I think, asking that question, how does the sprint goal that we're crafting during sprint planning? How does that take us on a step towards that product goal? So keeping that product goal in mind, I think is important. And again, I think it's, again, having transparency of where he helps the current state of the increments, what's what's the next step? And again, I think, being close to not just thinking about what's on our product backlog, but what do our users experience. So again, it's not just what's happening in sprint planning, it's what the feedback we're getting from Sprint reviews as well. So I think all these things are fit together. So I think, again, bringing it back to stakeholder feedback, and what customers actually yeah, saying this should be helping to feed into those decisions.

Patricia Kong: 11:34

So do you have examples? Maybe? Just a sprinkle?

Simon Flossmann: 11:39

Yeah. So from a general perspective, I think Scrum is not about work. It's more about value. And this will also guide you. And there's four sprint, goal creation and every other goal. And what does value mean, it's, it's the easiest way to start that you solve something, a problem for a user, or a customer. So start with that in mind, it's a good indication for value. And I had a team, we had a lot of activity based goals. So what are we doing provide some features some test environment. And one thing that we did in order to get the value perspective a little bit more is instead of providing the user a logging functionality to our platform, the goal was, I don't know 10 users are locked in successfully on the platform. It looks like a small change. But it's a whole nother ballgame now, because you need to find users who are actually logging into the platform. And this is more value or outcome focused. And I think the the hint or the insight I would give, make it tangible. From a user perspective, what is different for the user, after the sprint? What can he or she do now? That would be a tip.

Patricia Kong: 13:02

Thank you. Thank you, both of you. I am I got a hinge from, from an attendee Steve traps, as of yesterday. So I put a blog post that is in the chat for everyone to read. And for me, as the person who breathes evidence based management, I echo what you're talking about in terms of outcomes, thinking about that, and why are we doing something I even like to state my PBIS that way, but there's a lot on scrum.org. And goal creating is hard. So that's something that's definitely important to have facilitated conversations about. So moving on a little bit, some something a little bit similar. And we can get back to to sprint planning. I want to take a look at some of these other questions. Is, Simon You and I talked about the process, the process of the sprint planning and the sprint merger best retrospective being kind of similar. So one of the questions that we have here is, what do you do when no one is participating or sharing their opinion in the sprint retrospective? What facilitation techniques might you use? And I'll take it further and say, what if that means that during the sprint, you're actually not trying to improve anything?

Simon Flossmann: 14:30

Okay, this one is a difficult one without any context. So there could be a million reasons why that's the case. So the first one is, maybe people are quiet. Maybe the people itself are a little bit more quiet. Maybe they need a little bit more time to think and so you rush them and not everybody likes to create sticky notes or something like that. Sometimes it's really about the conversation. You need to find the right style for the right people. This is hard could be one issue. And some other thing would you could try, I think as if people are having a hard time to speaking up, maybe you missed a little bit of psychological safety in that direction, maybe you tried with something very different. And there's the idea of a twist, or which we call create a disaster where you start with a, what could we do in order to make everything even more worse? at something, you could try to lose people a little bit because everybody knows, okay, this will not happen. So I can make something up, which opens up to people. So that could be the immediate least step what you can do. But also, you should look at the surroundings. So what happens outside of the team, which creates conditions like that in your sprint retrospective? That's also something we could investigate a little bit more,

Patricia Kong: 15:59

do you have some different techniques to that you'd like to use just maybe, maybe think about the value of participation in participatory environments?

David Spinks: 16:09

Yeah, I see this question a lot. And it gets asked in a lot of training classes quite a lot as well. For me, I think about what is the goal. And for me, the goal for me is not as a facilitator, it's not to have everybody contributing or speaking. For me, I want to make sure that the ideas are coming out. So if someone is introverted, they don't feel like they can add value or they don't feel like need to contribute, I think we should think about asking value of respecting that person to have that stance, that's fine. But what troubles me is if if there was a good idea lurking and that doesn't come out. So for me, like I say the goal isn't to get everybody speaking is to make sure that there's the right environment to allow ideas to surface. So again, Simon Says It depends very much on context, what's the environment like the few people feel psychologically safe, and might use techniques where people can just put their thoughts anonymously, maybe a suggestion box or something like that, that is available during the sprints that people can just put anonymous ideas in. And then we'll open that up during the sprints. And just go through as a group, we don't know where the idea come from, but it kind of kicks off that conversation, or even in the retrospective itself, have people just add ideas on post it notes and put them on a board and maybe do some sort of affinity map technique where give a few minutes for everybody to think about, you know, we can use classic retrospective techniques like what? What went well, what didn't go well capture your thoughts on post it notes anonymously, we just put them on a board, we don't care where the thoughts have come from, then we can arrange the look for where we've got duplicates, or where we can form groups around themes, etc. And then that's starting a conversation as a group together. Why do we as a collective where we got that sense of merging?

Simon Flossmann: 17:59

May I add something?

Patricia Kong: 18:01

Please, please, please do? And then please answer. The other part of my question is when you take a retrospective item into the sprint, and you don't see any, any movement on that, well, would you would that signal to the team, and maybe a person who's facilitating some

Simon Flossmann: 18:19

events. Before we continue, I think we should clarify the understanding of the word facilitation. If I'm not mistaken, it's French. And it means something, making it easy for the team, I would say means making it easy for the team. So I would see it as making it easy for the team to come to a specific outcome. So oftentimes, the outcome is given if you think of Scrum events, so the sprint planning, we want to have a sprint goal and so on. And now if you combine this idea with a general idea in sports, or general and software development, if something is hard, you need to do it more often. Okay, if it is have a hard time to release to production, you should do it more often. And the idea of the sprint retrospective does not It's not beneficial or not effective, maybe you need to do it more often. And one easy way, why not do a retrospective every day, just a very small one to get people used to it to share their observations about a day. Something like that. So they get it's like, kind of behavior change. Because oftentimes, what I see retrospective is such a big thing, three hours, the whole team different room and this makes a little bit Whoa, what people what shall I do here now. And if you make it a little bit more like a ritual, like every day, it's quite natural. It's also something you could change and do it everyday. At the end of the workday. Everybody provides a short feedback about the day and you have something Okay, now the other question what happens or what should we do? as facilitator if the team does not pick up the retrospective improvement item.

Patricia Kong: 20:07

Yeah. So, yeah.

Simon Flossmann: 20:11

So there are a couple of, maybe we need to clarify the context. So the first thing, what is very important to understand, even if you do sprints, the world does not magically slow down. So they can a lot of stuff happened in the next sprint, and maybe there's something more important. That's the improvement. Nobody knows. So for assume the production environment is down or something, maybe that is more important. So let's say this is not the case, and the team still does not pick it up. I think that could be a sign that not everybody sees value in it, or did contribute to it. So there's a term I think it's called strong outcome, which means that everybody contributes to it. And it's more likely that everybody really owns the change afterwards, and does everything to change it. So maybe we can dig a little bit deeper into that one.

Patricia Kong: 21:14

I think I think with the number of questions, we're going to just hold off on that just for a minute. But I do want to get us at least have that come across and around the notion of strong outcome and facilitation and weak outcomes. And I'm just gonna quickly there's some more questions that are interesting around the retro and then I'd like to move on to the review. One of the questions was around, you know, when you're when you're working remote, and we're in this virtual world, and we're doing retrospectives. What are some suggestions around tools or ways that we can create that environment? I think we've all used mural or Miro those kinds of online whiteboarding tools. Mural, at least for me has a place where when you're voting and doing things, you can go into an anonymous, I guess you can kind of go sit and then people can contribute that way. So, so that's something there, there's, there's something interesting and, David, you and I talked about this, around the notion of icebreakers and retrospectives. So one, the question is, do you have any suggestions on icebreakers in general, and to what should we watch in terms of icebreakers? And I'm thinking about the recent class that you just had.

David Spinks: 22:32

Yeah, it's, I think, I think it's always thinking about what's the purpose of the events, what we're trying to get out of it. I'm hoping that again, most people work together in a team, you know that they're enjoying working with each other. But I think one thing that we kind of just lead to be a little bit careful is that we don't try to force the fun too much. The example that you mentioned, it was a professional scrum for software development class I ran recently in that class where you want agile sprints and we're running three sprints over a period of three days a very short Sprint's very short time boxes, 10 minutes for the retrospective. And one of the teams still felt that they had to do a fun icebreaker. So they started off by telling each other jokes. And these were people that were, you know, they'd work with each other, they knew each other, they were comfortable with each other. So they almost felt like it was obligatory to do something fun to kick off the retrospective. And as the trainer was like, you've got 10 minutes. You're spending time telling each other jokes how is this adding to you understanding how your Sprint's could be improved. So I think those things are important, but it's we shouldn't lose context of the goal of what we're trying to get out from a particular event. Other extremes I've seen for that for for Sprint retrospectives. Another team I remember working with, they were quite new to Scrum and doing it for a few months. And I asked them what was the purpose of the sprint retrospective? And with a straight face, the answer was to moan. And it's again, that's that's missing the point. So you've kind of got those extremes. It's always thinking about what is the purpose of the events? How can we, how can we create a format or facilitate in such a way that we're getting towards the outcome that we want and we're not just getting what we definitely want to have fun while we're doing it want to bond as a group, but it's still thinking with the end goal in mind.

Patricia Kong: 24:30

Thank you. That being said, Do either of you have some icebreakers that you love? And I guess it would depend on context? Is this a new group or is this maybe just an icebreaker or yeah, maybe just for new team coming together? Or you're coming into a new group?

David Spinks: 24:48

One that I've used recently can different variations you can deal with this. One Truth to lies I quite like so if it's to help people get to know the game that one. Yeah. So each member of the team, give them a few moments to think about what's what's one thing that's true about myself to two things that are not true. Lay them down stickies and then present them to the rest of the group and the rest of the group have to guess which one is the truth. So again, that's like the last and most icebreaker to just gank help people get to know each other a little bit. Yeah,

Patricia Kong: 25:23

we've done that to Simon.

Simon Flossmann: 25:24

Yeah, I'm not a big fan of icebreakers, to be honest. But I learned a very interesting one from Boris, a colleague of ours. And we use it in free training together. And when you start the Zoom call, we change our name with first name, then we where we are located. And then for instance, it was what was our first job, or what was our first concert or movie or whatever, and we change it every half day. And people can add to it. So they see, okay, there's something different, I can change, my name is bad, or but they don't have to. So I think one very important element, even if you use icebreaker for everything else, you need to provide the people the possibility to not do it. Okay, if you don't feel comfortable with it, don't do it. So you need to establish some kind of working agreements, whatever. Nobody has to do these kinds of things. Otherwise, it's, for me, it's too much. Sometimes I'm not feeling making jokes, but everybody else does. And then I'm feeling very uncomfortable, and which puts me in a very bad situation or bad mood, which will not help for the upcoming event. Let's say,

Patricia Kong: 26:42

we don't want you in a bad mood.

Simon Flossmann: 26:45

And I feel I did not answer the last one. What happens if the team does not pick up the item, I want to give at least one action tip make it transparent, the improvement item should be part of the sprint backlog. And so this may be sparks a conversation in the daily scrum. So everything is moving to done. But this one not maybe they see it on their own. It's the easiest thing what you can do. I fought I missed this one.

Patricia Kong: 27:17

Thank you for that. So then I thought we would go to the review. But actually, maybe let's go to the daily scrum. So the daily scrum there's definitely several techniques. What techniques do Do you like to use? And maybe give some some pros and cons of that so that we know it shouldn't just be a status update? Meaning? What is what is something that you David like to use? And what are some pros and cons of those techniques?

David Spinks: 27:56

Didn't get one.

Patricia Kong: 27:58

Let's start with one.

David Spinks: 28:00

I like the walk the board technique where we're focused on the sprint backlog, and we're looking at how work is actually progress progressing? And rather than asking question of the workers, we're asking question of the work. So rather than saying to an individual, Patricia, what did you do yesterday? What are you going to do today? Have you got any impediments? We can ask those questions of the work itself. So how is this product backlog item? How is product backlog item x? How did that progress yesterday? How is it going to progress today? And are there any impediments? So we're focused on making progress with the work? I find that that leads to a much more sort of synchronized discussion? If we asking the traditional three questions, we might see what you're doing yesterday. What are you? What are you going to do today? Then we might go to Simon who's talking about another item that we might go to a 13th member who then talks about something that they paired with you on for example. And we're kind of jumping all over the context a little bit. So when we focus on the work week, for me, I think we get a lot clearer alignment of what's happening to the work. And I think the con with that is what if what if there's somebody who hasn't really spoken, because we're talking about what's happened to the work. So some might see that that was a poor technique as a way that some people can potentially maybe hide in terms of what they're what they're actually doing. But again, I'm hoping with visualization techniques like avatars on the work items that because I can kind of alleviate that a little bit. But yeah, that can be a bit of a danger with that technique.

Patricia Kong: 29:44

Simon, do you have a different technique for daily scrum?

Simon Flossmann: 29:48

Yes, and I would like not to focus so much on techniques. David did a great job on that. So I think the biggest mistake you can make as a scrum master is to come in and start changing and adding techniques. So I think if you start with a new team, take your time and observe at least two or three weeks. And maybe another step. So it's one of the most important facilitation techniques, I would say observing. And the next thing is assume good intent, there's a big likelihood that the people do not know how to make it better, because they don't know what the outcome of the daily scrum should actually be. So maybe start educating about the outcome of all the events, and then let them rate on a scale from one to five. How do you think how good are you achieving those outcomes for each of the events don't make it as specific as the daily scrum? And then if the one the daily scrum has a rating, a low rating, then maybe can I help you? And now you can start changing something because I see so many people who just adding techniques, and I don't think now it's facilitation, because they make it even harder for the team. Okay, you say, Okay, you make something wrong, you need to do it like that, and so on. And so on with this approach, I think you are more helpful, so you do a better facilitation chop, and then we can use what we already hear from David. But I think the first step is the important one. That are my two cents.

Patricia Kong: 31:30

Thank you. Great. Those are, that was really, that was really helpful. I found it very helpful. So we have a lot of questions to go through. And if we don't get through all your questions, maybe what that means is that we'll host another one of these sessions. And we'll we'll go through the rest of them, or maybe we'll answer them through blogs or something like that. But we definitely are seeing all the questions. So let's move on to the Sprint Review. David in a sprint review, this is a question that we get all the time, is what do you do when everybody's really quiet? The second level of that is what do you do when no one attends? So how do we improve collaboration? And especially how do we, how do we think about engaging stakeholders and getting their feedback? And, and, and, you know, we're looking at that as a team so that we can move forward into planning to work on a new fun goal. What do you think?

David Spinks: 32:34

In terms of getting people to attend, again, I was involved in a conversation very recently about that particular company who's suffering from that problem. The advice used to be bring cake, but it always used to work if there's if there's food, if there's cake, if there's biscuits, people are kind of drawn to that. The technique has kind of fallen by the wayside as we've been more more than I think, when we when we talk about the purpose of the sprint review, to get feedback from our stakeholders, we use this term stakeholder quite generally, I think a useful technique to do is stakeholder mapping, where it's identifying your different types of stakeholders, and how do they need to be kept informed? Because some of them, yes, they've got interest in your in your products. But maybe, for example, only from a financial point of view. They do they need to come to this point of view, maybe not maybe just sending them a regular report. So it's identifying the different types of stakeholders, maybe looking for different groups and coming up with a plan on how you can interact with with with which ones. So we're really interested in those stakeholders that are highly interested and can have a big impact on our products. Those are the ones that we need in, in the in the sprint review. And it comes back to transparency again. So I think it's useful to make maybe we can record the sprint review, maybe we can produce some meeting minutes, maybe we can produce a report on how the product backlog has been adapted as a result of the conversations and sprint review. And this This is this is what's happened in the sprint review. If you want to have skin in the game in terms of influencing the product backlog, then you need to be an attendee, that's what we're trying to communicate. If you're not there, if you're just kind of throwing requests over the sort of fence at the team, you're not really going to be treated as potentially a first class stakeholders, some of the other state by the product owner, and potentially some of those other stakeholders. So again, there's an education piece here, talking about what the purpose of the sprint review is. And again, ship educating in terms of is that formal opportunity for the stakeholders to have that touch point with the scrum team and if they want to influence the product backlog, this is the best way to do it.

Patricia Kong: 34:55

So there's there's some interesting thank you for that there's some interesting reading sources that listeners might find. Interesting. I think we did do, we did do a webinar on facilitation techniques for the sprint review. And this was a big topic about attendance and some different techniques to use there. And there's there's certainly, there's a V logs by Ravi Verma actually, David, that's called, Why won't anybody come to my parties? Maybe that's, that's a helpful, helpful thing. And we'll see where those are. Simon, did you have anything that you want to add?

Simon Flossmann: 35:32

Oh, yes. Um, so I assume you're a scrum master. We need to understand this facilitation has limitations. So facilitation, I would define it as having groups to get a shared understanding and come to a shared outcome. That's it. That's not the only thing what you can do as a scrum master, maybe you need to switch your approach, take a different stances, maybe you need to change parts of the organization to get people to these sprint review. And the thing is, if you make a party, or create a product, no one magically comes to you why you need to invite them. In even if you invite them, you need to tell them, what's in it for them. And most of the sprint reviews, I'm seeing which I also did myself badly. It's all about us as a team. Nobody cares about you as a team, from a stakeholder perspective, what's in it for me from a stakeholder? So gather those information. And if you present those information in the sprint review, it's more likely that people are coming.

Patricia Kong: 36:47

Thank you. I think I think it's to think about the also the the persona and the schedule of the people who you need that feedback from, they're usually, maybe usually not, but some of them are just like, I'm a very busy person, right? And so when they get there, they want to they want to understand the impact and the outcomes of what's going on and and what value is going into that. All right. So let's talk about during the sprint, and Simon, if I could stay with you. There's a question. And this leads us nicely into some other topics around conflict. But this question says in my team, we have a very few people who are, are very vocal, and their high performing. And then we have some people who don't share contribute at all. I don't know if that means that their their their high performing or not. What would you suggest, from a facilitation perspective? What could that person do to foster more participation? And kind of keep the balance of the team? And the reason I'm asking you, because you and I think a lot about scaling, when you add people onto a team, what happens to that, and just the balance of the the the notion of participation, and I think this might be a great place to talk about strong outcomes and weak outcomes.

Simon Flossmann: 38:10

Yeah. So what we typically have if people which are very vocal, are very fast in providing their ideas. And, of course, there are these brilliant, but maybe we miss out on some other ideas. And there is the downside that if sample, some person starts talking out loud, which we there's a phenomenon which called groupthink for everybody else, a typically jump onto the same thought, it's very hard to have a distinct thought if somebody says already something. And in order to maximize different ideas for diversity, we should somehow pay attention that everybody has a time to think and everybody can contribute their ideas at the beginning, there are a couple of techniques, what you can do, you could ask everyone, please write down your ideas on how to solve whatever problem on a sticky note, put it on the wall. And this happens, everything in silent, at least we get to know all the ideas, and then the next step we can start to discussing. And now you have people which are very vocal and talk a lot, maybe you need to introduce a couple of different techniques to give everybody the same amount of time to speak. So you can do it with round base timing. So you're the first person provide your opinion, you're the second person you get one minute to provide your opinion and so on. That's some things you can try. That would, what that would might take.

Patricia Kong: 39:47

David, if I can ask you to elaborate on this.

David Spinks: 39:52

Yeah, those a couple of techniques jumped into my head. So if we've got that very vocal person that's putting forward ideas, maybe We could use a technique like tweaker consulting, where that person's idea is put on the table. But with tweaker, okay, everybody acts as the consultants and that person whose ideas being discussed or whose problem is being discussed, because, again, how you ask the question, but that person basically turns around turns out back to the team and the rest of the team debate what the problem is, or the potential solution that has been put forward by this person, and tweaker, it's called I just saw in the chat window TR, O aka. So again, you're that person is practicing practicing active listening, while the rest of the group is discussing the idea that's been put forward. Another one that came into my mind was Edward de Bono's six thinking hats. And again, this is a technique where you metaphorically, you don't literally have to wear hats, but you metaphorically wear different hats and different colors represents different ways of looking at the problem, like, we're going to take the stance of being an optimist, let's just focus on the positives of this idea what's been put forward, or we're going to go with a more judgmental hat, we're going to try to critique it. So there's different ways. And again, you're, you're, you're you're you're getting people to think, in particular analytical ways. So again, if I'm someone that's very vocal, or pushing my ideas, again, I have to take part as a peer in terms of like, I'm going to criticize that same idea that came from me, for example. So again, for me, I'm less worried about people contributing and just making sure that the idea or the question is being properly, properly, sort of analyzed and creating shared understanding across the group.

Patricia Kong: 41:46

So this, this brings us nicely to a couple other questions around conflict. And I think you've given some great techniques around there. There was a question in here that's interesting about what do you do when you have a colleague or team member who's always just kind of looks like they're blaming, blaming you and I like to call out, they're always looking for faulty feedback. And that, that brings us really to conflict within a team. And also, I want to preface this because something that that, that I I, I'm writing an article about right now. But the the notion that when we are a group of creative people coming together diverse, and we're trying to work in a complex area, there's going to be conflict, there should be conflict, because we have different ideas. And so what we're trying to do is, is kind of get to a new and better idea together. But that can sometimes depending on the safety, and the environment leads to conflict lead to blaming lead to all these things. Simon, do you have any stories just from your personal scars? Or you know, maybe your work experience was going to be very specific. And then I remember we were being recorded about conflict, and just, you know, what have you done that's worked or not worked? Well, from a facilitation standpoint? Maybe in a team? people arguing almost?

Simon Flossmann: 43:11

Well, I think the first thing would we need to be very honest to ourself, are we able to navigate or resolve conflicts. So I don't think that's a typical scale of a scrum master. I think if everything is about the topic in hand, you can use facilitation, it's about finding the best ideas, combining ideas come to a shared outcome, totally fine. But if you go to a conflict or RIA conflict, where it's not about the topic, it's more about your right and you're wrong. And it's more about the people and the behaviors not accepted, then we should be very careful if you really want to do it. And if you're capable, because it's easy to make it even worse. And now, what I used in the past, there is a test to see where we are. So one thing you can hear is, is it really about the topic, it's the topic, a good idea or a bad idea or is about the person. Again, you provided such a bad idea. Hmm, that's something you need to look for. And then you could ask a question, please. Say me something good about the person? What do you like about him? And if the other person cannot provide anything what he likes about the other person, then you have a serious conflict. And then it's not more not about the topic in hand and it's about the people and then you need to decide, am I capable of navigating or facilitating this kind of conflict? And if not, put the people in different rooms and get some somebody who can help you. And I think that's the term of professional as a professional scrum master you need to be aware of What you can do, and what you cannot do and where we are in terms of the conflict from the levels. So that's the first thing. And if you don't have such a high conflict where it's about people and not about the topic in hand, and one thing when you always should try to do is every person should have the time to provide the ideas. And everyone should listen to the other ideas. And that's the crucial point. Okay, make sure that everybody listens to what the others are saying. And that's one thing to resolve a very light way conflict.

Patricia Kong: 45:40

Thank you. And then there's a lot of deep stuff. That's where there's a model called the ground zone that we talked about, that's based off of Sam Keeners, where ke N er, where sometimes it's bottled up conflict. So there's, there's those types of things. And when you're trying to make decisions, it's hard. David, would you like to add anything? Or would you like to take the next questions on refinement,

David Spinks: 46:07

I think I would just start as well. But I've seen conflicts where it's actually between different members of the team, but also the team member scrum master as well. I think it's important to remember when we're talking about facilitation, it's not just the Scrum Masters job. Ultimately, the scrum master is the team's coach. So Can Can the scrum master, teach the team or coach the team to facilitate for themselves? And I think if I can get into that into that sort of place, then we're in a very sort of healthy position. So can we get the developers facilitating their own daily scrums, for example. So it's not always about the Scrum Master, I think it's important to add.

Patricia Kong: 46:51

So you wanted these questions instead? So I'll let the audience know where I'm gonna go with this. We're going to talk about facilitation and who facilitates on the team and the notion of neutrality. I think we should talk about refinement, and then we'll come back to facilitation in general, there's still so many questions. So then David, can you talk about how how there's different people that can facilitate on a scrum team, we want that. Can you then talk about neutrality and how do you participate? So for instance, if I am the scrum master, and I am facilitating the retrospective, what do I do because now we have another issue of conflict and safety. You talked about the team against the Scrum Master.

David Spinks: 47:30

Yeah, absolutely. So, again, it's just recognizing that you do have this other hats to where you are. Again, if, if as a scrum team, we're agreeing this retrospective, the scrum master is the facilitator. But remember, the scrum master is part of the scrum team. So they're taking part as a peer. So yes, they should be taking part from the sense of they were involved in the sprints, hopefully. So again, I think it's again using the right sort of techniques. For example, if we look at a moment to talk about retrospective, but if I look at something like if we're sizing using planning poker, for example, the scrum master can facilitate that. But if the scrum master, but they're also a developer, they can take part in the planning poker. So again, they might be running the events, but they're they're asking questions as a developer, they're doing their sizing, as a developer as well. The point is that they're they're running the meeting without sort of jumping in and saying, right, let's do planning poker, I think it's the 13th. But let's see what everybody else thinks. It's still trying to remain neutral and running the event in such a way that they're keeping things flowing. But they're not sort of biasing or influencing the rest of the group, because they're seen as the facilitator, tricky to do, but I think it's just being aware of it, I think, is the first step. So in terms of the retrospective, again, if we're using a technique, like 124, all like Simon mentioned, or if we're using just capturing ideas and sticky notes and doing some sort of affinity mapping, again, the scrum master sort of just explaining this is a technique that we're going to do, I'm going to take apart as a as a team member, as well.

Patricia Kong: 49:15

Yeah, and making sure that that's clear, and that people agree to that I think is important. All right, Simon. So you've had enough time to think about refinement now. I have I have a specific question here. And then and then please share more of your experience and techniques. So we've gone through some of the different events, product backlog refinement, when we're going through the product backlog is not an event, but it's it's pretty important, leading up to planning. So this question is we work with a lot of various external suppliers. We invite them into our refinements to discuss new projects good for you. How do I make sure that we keep a certain structure in these kinds of sessions, where we're facilitating these external suppliers In refinement. And I think in general, how do we facilitate the structure of refinement?

Simon Flossmann: 50:07

Yeah, I think what we should start with every facilitation is what is actually the purpose, what is the goal? I don't know what the goal is in that specific refinement session, I think, the general goal for five minutes to understand the product better product backlog better. And here, it could be more specific. So what is the actual outcome? I think the first thing what you can help the team to make it easier is to get what is the specific outcome we are looking for? That's the first thing. Now if you have clarified this now, what could be possible steps to get there? So it could start, what is the timeframe? So do have a one hour, two hours, and so on? What, what things needs to be discussed? And so I would do it a little bit more dynamic? And so what are the topics you would like to discuss in order to get to that outcome? And maybe the next thing is, okay, how much time should we need for each of those topics? That would be a very lightweight approach. And then maybe we need to add on a little bit more, and try to involve everyone and so on. But I think the first thing is you need to create some kind of frame for the refinement. So where do we go? What's the time books? Who should be here? Who should not be here? And so on? How do we make decisions? This would be my first idea

Patricia Kong: 51:27

to get started, I think, an important concept that that I had shares that in terms of thinking about facilitation, it's not just what happens in that time box, when you're facilitating it's what you do before and what you do after to make sure that we're meeting the outcome. So and then having that agenda and structuring it definitely is important. So a little bit off of that, David, this one's an interesting question, is there a particular facilitation technique that can be used as discussed the viability of new products among different teams, Product Engineering, to have more ideas, more discussions? And I'm thinking of that, because of the work you you you do and design thinking and in all your, your your books?

David Spinks: 52:15

Yes, a tricky one. viability, it's quite a big word. And it could mean viability in terms of is it technically viable? is a viable in terms of is there a market for the product? So it's part of the nature of the type of work that we do, we're dealing with a lot of unknowns. So really, it's about what can we do to test the idea as as cheaply and as quickly as possible? Really. In Scrum, we talk about getting to a done increment every sprint so that we can put something into the customers hands to release that value, but also get feedback on it. And I think a lot of thinking, in the Agile space is sort of based on this. But does we can think about actually is that is that the cheapest, fastest thing we can do to check the viability of these things. It could actually be the most expensive we think we do is to actually build the product. Could we do something in a more lightweight way, such as build a prototype? And, you know, get some feedback on that from some key users? Could we carry out maybe just some, some surveys and ask users about potential ideas that we've got? So rather than build the product and put it out there and hope for the best, we're looking for more lightweight ways of testing ideas. So yeah, I think that's that's kind of going to that next level of how do we get even faster feedback on something to again, have more confidence on the journey that we're taking?

Patricia Kong: 53:48

Yeah, I agree. All right. So we have less than one, we have six minutes to be very specific about what we have left. There's some there's some great questions. And I think it would be remiss if we didn't talk about remote and the hybrid kind of stuff, and some different ideas there. There is a specific question that says my remote team is very large, with almost 20 people. And sometimes they're they're trying to split the team, but in general, so this is a large scrum team. Simon, how do you how do you when they're remote? How do you keep that engagement, especially during the scrum events? And what do you do? This stuff? I'm very sorry. They're reluctant to turn on their cameras. So what techniques can you use to get everyone engaged? And so I'm thinking even in a hybrid environment that's hard to you might have some people who are on online some people were not and that creates an unbalanced what are some what are some, I guess, ideas and observations that you have around this remote and hybrid way of working from a facilitation standpoint?

Simon Flossmann: 55:01

Okay, we have to have two forms here. So first and foremost, it's a technology question. So if you don't have the right technology, that's a difficult one. So, no matter how large the group is, in order to have full participation, you need to split up into smaller groups. That that's a given. And this depends in a virtual setting lot on the technology if you can do it or not. So that's one thing. And the other thing of what happens if people do not start the camera. And I think as a scrum master, you need to be a role model in terms of the scrum value and values, and maybe you need to be very open. And point that out, Hey, I'm seeing a bunch of you do not start your cameras. I think has this and this outcome, or this in this downside? What does the rest of you think? And this opens now, the opportunity for you to facilitate the discussion. Because if people now are replying to your answer, you can ask, okay, can everybody share their opinion and so on to get progress here. Because sometimes we think it's a problem, but it's actually not a problem for the team, it's just a problem for you. And that's, that's a very dangerous thing we need to be pay attention. So you need to somehow get better technology. If this is an issue, you need to figure out if it's really a problem for the group. And if it's so help the group to overcome it. And my understanding, you cannot force people, but you can always encourage people and show them the benefits, if they would contribute with camera on and so on. But to be honest, there's no silver bullet magic pill, which immediately works at least I don't know it. Maybe David knows the silver bullet.

Patricia Kong: 57:04

But I'm gonna give you a closing question is, so we've established this notion of facilitation, we've talked a little bit about neutrality, we've talked about that anybody can facilitate if the team agrees to it, someone outside that might work too. It's not a special role in Scrum. So inspection adaptation, how do you know if you're doing a good job facilitating? How do you know what skills you need to improve as a facilitator what your your weak spots are, and I will share first, on the scrum.org website, there is a page that will share that has a list of traits and facilitator skill that you can already start kind of looking at and saying, Hey, I'm good at this. I'm not good at this. I wasn't aware of this. But what have you used yourself?

David Spinks: 57:55

Good question. Yeah, I look back at myself years ago, and how I would facilitates events or other sessions and think, Oh, my God, what was I thinking? And I'll probably look at myself and another five years time and kind of think, the same way. So again, I I don't think it's like say, it's not just about the session itself, is not coming up to the session coming up and saying, Hey, we hit the time box. Hey, we've got through all of our agenda items.

Patricia Kong: 58:27

Everybody was talking, hey, smile them had fun.

David Spinks: 58:31

Exactly, exactly. Yeah. Well, the jokes that everybody was telling them, they were funny. I goes back to I go back to those facilitation principles that we've got the scrum values. We talk about this in the PSFS class about the facilitation principles. And I think they're great sort of guidance, good things to fall back on. So one thing that I think about is, did we make clear what the purpose was? Was there a clear purpose to the event and was that purpose fulfilled? And maybe I can want to monitor what happens after that session or events. So for example, we talked about sprint retrospectives. We know that the purpose of the sprint retrospective is for a scrum team to inspect and adapt itself come up with some improvement actions, right? Yes. If we're coming out with Sprint Retrospective with that, that's great. But is that being followed up on has that purpose been fulfilled in terms of not just coming up with that action, but being followed up on so purposefulness is one of those facilitation principles that I might test myself against? And I might be looking at the others. Just very quickly, you know, was it healthy to feel people feel psychologically safe? How is transparency? What about participation, a lot of stuff that we've been talking about today. So falling back to those first principles as a way that I've measured myself.

Patricia Kong: 59:57

Well, thank you very much, both of you. There was a lot of information. Thank you for everyone who's who's listening. Again, there's a lot of different resources that are out there there in the chat, and we will have them in the notes. A lot of your questions will see them. And we have a lot of resources there. We again did do a webinar. That's David Spinks and myself. Simon is doing one on facilitation in German. If that's if that's a language that you speak and understand. So you can get more questions there. But thank you very much for attending. And we'll see you again soon.