 Thank you. So I'm just going to get this going and let's play. Okay. So now this, this is the freaky situation where I'm just basically talking to my laptop screen, which even though we're a year into this, I still find really weird. And so I can't see any of you now. I would normally have two monitors going but my Mac has just completely died this week, which is absolutely shot to my productivity. If you see me sipping first of all, this is alcohol free. So I'm remaining professional for you. But yeah, so I'm here to talk about agile coaching isn't about coaching agile. This was going to be a co-presentation with Ashton Green, awesome coach from Ireland, luckily, unfortunately, she's not well. So she's had to drop out. Maybe we'll, maybe we'll get her back to another session later on in the year. Thoroughly recommend checking out Ashley's work. So you asked me to do some talk you said you've had a few talks about professional coaching recently, but not really about agile coaching. And so I wanted to talk about the slight differences. So as as you mentioned, I do some work on professional coaching as well, the coaches case book, if you read that, we'll mention agile once it won't mention scrum once. So that's a big part of my work. And I spent a lot of time trying to encourage the agile world, bodies like the scrum alliance and so on to embrace the world of professional coaching. And there is now a significant amount of overlap and understanding in that world, not all down to me, I hasten to add, but I'm pleased to see that it is there. But there is still a difference. And I recently did a talk for for the NHS on on a similar kind of topic. And it wasn't so much that they have agile coaches. It's that they're looking to increase in agile culture and want to understand the role of coaching in an agile environment for people engaging with their teams, be they managers, be they stakeholders, be they sort of in their matrix or different roles. So similar kind of theme to that, if you like, and I will reference some of the content that I went through there, because I haven't got as much time to go through as much as I would like to with you guys today. So there's a couple of links in here for further details if you want it. So the plan here is just to briefly go through what an agile coach is won't take long because most of you will be aware of that, but I just want to highlight a couple of points that there are different options for coaching an agile team just introduce you to a couple of different types of models that you may or may not be aware of when it comes to coaching. And then if you are if you do find yourself in the position where you want to provide some coaching for an agile team or you are in the role of an agile coach, some challenges that you may have already encountered or you may you may yet encounter potentially some techniques that you might be able to use to help you if you come across any of those challenges. And as you and said, we've got some Q&A at the end. So save those questions because I just as well as I can't see your beautiful faces, I can't see your chat either while I'm doing this. So I'm completely blind. When it comes to to your your reactions and things you could all be throwing things at the screen for all I know. So I'm going to start off by giving you a few scenarios that you might come across as an agile coach. And I want you to bear in mind that although some people may believe there is a right way to act. I'm going to go on record here as saying certainly here in this scenario, this setting of this meetup group, there is no right way for you to act. It's purely hypothetical. But every action that you take when you're interacting with a team will have an impact will have consequences on that team, not just in the here and now, but in terms of their growth over the medium to long term. I don't want you to overthink it. All right, we're just here to give us some content to base the talk around. But I want to I want you to personalize this to your context so that you can apply it a little bit more rather than just be very abstract. After we've gone through the scenarios, we're going to reflect on the options, defaults, preferences, and so on. And then how they apply to you in your role as best I can over this this strange medium that we're in. So there are three scenarios here. And I just want you to pick one of them what perhaps one that you think, yeah, I can relate to that more than the other two or, you know, I had that recently, or I can definitely see that coming up with with one of the teams that I'm working with. And I want you to think, well, what could I do in that situation? So not what would I do? Definitely. But what could I do and write down five or six different ways? So scenario one, the team has failed to deliver on a number of recent commitments, like I said, purely hypothetical. And the customer, whoever that customer is, is starting to lose faith with the team, with scrum, with whatever. So the team's not met a few commitments, customers losing faith. If you can identify with that, just write down, type out whatever five or six different ways that you could approach that scenario in your role. Scenario two, a newly formed team is struggling to gel. And there's some conflict simmering. Again, purely hypothetical. If that one resonates more with you, pick that one. Scenario three, a well-established team, they think they've got it made. They think they're pretty good. They don't need to improve anymore. They're doing well enough. Maybe we don't need retrospectives. They're just happy, happy, going as they are. So pick one of those scenarios. I'm only going to give you two minutes to write down five or six things that you could do. Interventions, things that you could say. Exercises you could run. Questions you could ask. Anything that you think you might do and just list them out. Five or six things gives me chance to have a little bit of a sip. And this isn't what I suppose it is. I suppose it is a little bit of a plug. But my latest book isn't Team Mastery. It's Pun Mastery. So with Paul and Nigel, we've just released a book of agile jokes just to lighten the mood during the pandemic. If anybody needs a little bit of lightening up, a bit of rib-teckling fun, poked at a number of different roles, frameworks. You know the meaning. Cool. So teams fanning to the liver. Customer losing faith. The weird thing is what you can't see is behind my camera are my neighbours. And they can see me talking. But they can't see what I'm talking to or talking out. They probably just think I'm standing in my shed talking to myself. An absolute nutter. They're making their dinner completely enthralled about what's going on in my shed. And there we go. Right. That'll do. That'll do for now. So five or six ways that you could approach it. Now if we were in a room, I'd probably ask if anybody wants to share it. But it's a little bit awkward, a little bit weird when we're online. So I'm not going to ask you to put yourself out there on video, especially as being recorded. But the reason I asked, there is a reason I asked you to write them down and list them out. Because I need to have a look at them. And I want to think what you to think whether any of these approaches were ones that you considered. Did you think that there was an opportunity to teach this team? Perhaps they were missing some information. Perhaps they were missing some information about team dynamics. Perhaps they were missing some information about scrum or agile or the organizational culture or processes. Perhaps they were missing some data that you had that they didn't, that would have made life a little bit easier for them. Perhaps you could give them that information, teach them that knowledge that would help them with this situation. That's one option that maybe, maybe could have come up in your list of things. Perhaps they needed telling. Yeah. Something that you knew they needed to do. And it would actually solve the problem or it would actually help move the problem forward. They weren't aware of it. You were. This isn't necessarily knowledge in terms of data or facts, but more experience or things that you know you need to do. Maybe not instructing, maybe just suggesting. Maybe that was an option that you thought about throwing something out there. Again, from your experience, something you read perhaps, or maybe just from picking up some signals you've identified something that they might try that could help them. Maybe you thought about asking them what they think they should do. Maybe that was one of your options. Maybe you thought about facilitation of some kind to help them reflect on things, perhaps a little bit of systems thinking what's going on, what's causing this situation, what's influencing this situation. What did they have control of? What did they not have control of? A bit of facilitation. And as well as thinking about whether and those aren't an exclusive list by any means, there are lots of other ways that you could handle this. And like I said, there is no right way. But one thing I'm interested in, and again, I'm not going to put you on the spot to share this, but just reflect on it. What order did you write those options down in? Which of those came to you first, which of them perhaps took a little bit longer for you to think of when I pushed you for five or six. And again, don't judge it, don't overthink it, but just notice it. Just reflect on it. Did teaching come first and facilitation come last? Did asking the team come first and instructing the team come last? It's not good. It's not bad. It's just interesting. Because everything that you do will impact the team. Everything that you don't do will impact the team. And in certain circumstances, some of those will turn out to be more effective, more appropriate, more well received than others. And exactly the same situation with a different team or a different time, a different approach would work. So it's not about finding the right one. But there is an element here about working out what do I think first? Where are my defaults? Where are my preferences? And how does that impact my ability to interact with the team? So I said there could be a couple of models. I'm not going to go through these in a lot of detail, but just thinking because all models are wrong, right? But some are useful. So we do, Paul and I, Paul was on the call, not sure whether he's got bored already and left. But we talk about speed coaching in some of our training and coaching. This idea of just thinking of different ways that you could interact with a team. From suggesting things to helping them gather some data, just try something and gather some proof with enabling the team or changing the environment or tapping into the drivers. You know, what do you want? What are you scared of those kinds of things? If you're interested in more detail and there's a video or go into more detail on that in your own time. The other model that I wanted to come in into, which I'd love to spend more time on, but I just haven't got the time of yours to go into it. So again, there's another video if you want to learn a little bit more about that. But player lead coaching is something that I came across in my work outside of professional coaching and agile coaching while I was being trained to be a child cricket coach. This idea is, well, rather than you as the coach decide what the players, what the kids want to improve on and design a training session to improve their skill in some certain area that you think they need improving, ask the kids what they want to get better at, they define the agenda for the training, they define the agenda for their improvement. And not only that, but they figure out how to get better. So your job as a coach isn't to decide what they should get better at or even how they should get better at, but to create the conditions where they can do that, not just safely, but also in a way where they want to come back next week. And I just thought that was a fascinating abstraction analogy for an agile team. So I'm going to link this back to the title how agile coaching isn't necessarily about coaching agile, because in this player led coaching thing, imagine me in a classroom with other volunteer parents and also people who are there to get their badges to actually train professional cricket teams. And the first question they were asked was, I was asked, was what's the number one objective of a training session and someone who's been to training sessions and someone who drops their kids off at training sessions and pays for kids to be trained. My initial response was, well, I send them to training so that they can get better. So as long as they get better in some small way, then training has been a success. That should be your number one priority. And effectively, they said, I can see what you're saying, Jeff, but you're wrong. Or we want you to be wrong. And so they said what they wanted my number one objective of a training session to be as a coach is not that the kids get better, but the kids want to come back next week, which I thought was interesting. And because I'm naturally curious and some may say pedantic or argumentative kind of person, I raised the hypothetical scenario of, well, that could mean that they get worse. And you consider a training session to be successful. It could become less adept at playing cricket. And you think that training has been successful because they want to come back next week. And their argument was, yeah, yeah, because they then have the opportunity to get better again. If they want to. But if they get better and don't want to come back, you've lost them. I thought it was an interesting way of looking at it. It's all based on the premise that generally speaking, kids want to get better and they're more likely to get better if they're having fun while they're doing it. So what does that mean? Well, could we actually, as agile coaches, let our teams get worse and agile and be successful? I'll leave that with you for a minute. So in your role, when coaching a team, those different ways that you could interact with them, sometimes telling them, sometimes advising them, sometimes suggesting sometimes asking them, sometimes facilitating them, whatever you're going to be doing, however you're interacting with them, there will be some challenges but this idea of helping a team to drive their own improvement, to own their own improvement, own their own growth, you can get some challenges. So the first of all is your confidence. Now there's three aspects to your confidence here. First of all is in yourself and the team, your team first. So do you actually believe, and this was something that I had to ask myself, do I believe that 10 and 11 year olds are capable of working out what they want to get better at and then capable of deciding how to get better at it? Do I believe that? Because if I don't, then even if I'm going ticking the boxes and going through the motions of this, this coaching approach and got my badges and stuff, then I'm not really going to be allowing them. My words will not be matching my actions. There were mixed messages and confusion. So do I really believe that this team is capable of doing that? And do I believe that I'm capable of being that person? Can I create the conditions for them to do that? To believe in themselves, to take that ownership? And then come back to that in yourself, because there's a couple of nuances to that. But the third element of confidence is the process. So when you talk about, if you've any of you have been on a professional coaching course, there's a lot of talk about trust the process. Because there's an element of letting go of your idea of the solution when you're when you're a professional coach, you're trying to listen, you're trying to reflect, you're trying to stay neutral, you're trying to take yourself out of the situation, if you like, in terms of your interpretation and trusting the process, trusting that that person has the capability and the desire to want to take their situation forward. And if you don't trust the process, it's going to be much harder for you to let go of your idea and let the team own their own situation, even get worse at agile in order that they can get better as a team. Your preferred approach is going to play a part. So if you lean towards always asking the team a question, then when there is a right answer, when there is some data that they're missing and they just don't know it, how will they get better? Maybe through failing? Maybe, but maybe not. So being aware of what your defaults are so that you can apply the more appropriate response, the more appropriate engagement, take the more appropriate stance based on the context, based on your understanding. A lot of this for people who are working in an agile coaching environment, there's a big anxiety around how does an agile coach add value? Equally, how does an agile leader add value? If we're looking at creating autonomous self managing cross functional teams, then where do I add value? It's all very well saying, I'm helping that team grow and become great by not getting in their way. But if culturally, society organizationally, maybe even in your family, there is a perception that you add value by being in charge, by making decisions that strength comes from brave decision making and leading from the front. Then taking any other kind of interaction with that team is going to be very difficult. It's not about right or wrong. For me, it's more about greater awareness and more mindfulness of how you're acting and when you're acting that way. Equally, if you believe that you add value by never providing your advice, never providing your opinion to the team, then you might be missing out on something as well. And the team might be missing out on something. Typo in the slides, your view of people's expectations of you, which is exacerbated if you have a role of agile coach, because then aren't you there to coach the team to become more agile? Aren't you there to coach them in the processes, the ways, the practices, the principles of agile? So could you could you run the risk of letting the team get worse, less agile in order to get better? If other people are looking at you and judging you on the agility, whatever that means of the team, then do you have the confidence to be able to let that team grow how they need to grow right now? That's a challenge that you might encounter. You might not. Also, we do like to be right as human beings. It's kind of taught into us from exams. There's a right answer at the back of the book. Someone else is going to mark our paper, judge our submission, critique our essays. And if we are seen as an agile coach, and we're not doing something that is seen to be agile, not only are we worried about their perception and expectation of us, but our own internal expectation, our own internal judgment, our spidey sense might be tingling. So if we have a real desire to be right, that could pose us a challenge when coaching a team. And the last one is, well, it's not the last one, but it's the last one on my slide. There are many more challenges you may encounter. I don't want to scare you. But sometimes what people ask for isn't what they need. And also, we have a tendency to believe that people need something that they're not asking for. So we have a tendency to believe that when it's not there, but also it is a reality. So can we really differentiate? Can we help the team differentiate the difference between what they want and what they need? In an ideal world, they would want what they needed. But some situations, that's not the case. So if you were to face any of those challenges, when coaching a team in whatever role you have, what could you do? What can I offer you? Thinking back to your scenarios, perhaps, of how you might have engaged with that team. The first one is practice. So this is relating back to trusting the process and trusting yourself and to a degree trusting the team is give yourself the opportunity to gather some data. We fear things that are different. We fear uncertainty. We fear loss of control. There's lots of other things we fear as well. But the more we practice, the more data points we get about the justification of trusting the process. And by trusting the process and it being successful, we have greater trust in ourself as someone who can facilitate and hold that process. Talking about the coaching process there. So the first thing to do is just practice, just do it. Do more of it. Whatever it is, do more of it. But mindful practice. Don't just build your way in there, reflect on it, get feedback on it, get some supervision on it, whatever. Practice mindfully. The second one is wait. Now, I don't mean wait before you practice because I've just told you to go ahead and get some practice. But wait stands for why am I talking? And it's another way of phrasing my favorite, one of my favorite quotes, which is if I can't be certain, I can't be sure that what I'm about to say is more important than what they're about to think, then I'm going to stay quiet, which comes from Nancy Klein. So why am I talking? Sometimes having a little bit of a, you know, tattoo on your knuckles, W-A-I-T, perhaps not as sexy, not as cool, but, you know, bit of a reminder these days when you're coaching remotely, just having a little post-it now when you monitor, no one can see it, just a bit of a reminder. Wait, why am I talking? It doesn't scribble in the corner of your notebook. Wait, why am I talking? Let's just see what happens if I don't say anything. Maybe we could consciously, mindfully practice. Practice what? Practice listening. Most people, I would suggest perhaps not most, not the majority of this group, but the majority of people do more talking than they should and less listening than they should. We're more practiced at talking than we are at listening, yet we have two ears and we only have one mouth. And if we are to help a team own their own growth, own their own development, we kind of need to listen to them, but not just the words. We need to listen to what's not being said. We need to listen to how it's being said and also listen to your intuition, your spidey sense. Get comfortable with that, just observing, picking things up. Testing it, getting some feedback on it. I'm sensing this. Am I right? Am I off track, trusting the process that you might be wrong? So practice that listening is a skill that you can develop, especially now. Go somewhere, a park, sit there and just tune in to different things and then tune into something else. You can, you'll be surprised at how much you can hear from far away if you focus on that thing. Practice that. Be mindful about the words that you use. Paul and I recently did an episode of the Agile Pubcast with an Agile coach from New Zealand called Sandy Marmalie, who's awesome in many, many different things. But one of the things that she's awesome at, she's multi-lingual and also has lived in many, many different countries and she's practiced agile in many different countries as well. One of the things that we got talking about in a recent episode was how the same words can mean very, very different things in different countries. Everything that you say and the way that you say it will have an impact. So being very mindful about the words that you use, I'm not talking about upsetting or disrespecting or offending people, although be mindful of that as well. I'm talking about keeping your language clean to try and take any kind of inferred judgment out of it. Be curious without being suspicious. These kinds of things. So practice that mindful language, think it through. Wait, why am I talking? Give yourself time to think through what do you actually want to say? What do you actually want to ask? You're here because this is an agile group. So asking and getting feedback won't come as a big shot for you. But asking and getting feedback on some of the things that I'm talking about here might be. So getting feedback on your intuition, for example, getting feedback on how well you actually heard somebody, getting feedback on the type of intervention that you took. I chose to offer you my advice here. How did that impact things for you? I chose to withhold some advice from you here. How did that impact you? How would you want me to respond here? What kind of coach do you want me to be? What stance do you want me to take? Get some feedback on those kinds of things and build up what I call your unconscious heuristics. Everything that you do has an impact and it's a data point only if you reflect on it and internalize it. You're building up lots and lots of data points that heuristically unconsciously you can come back to. And like I said, sometimes getting less agile is still progress. Perhaps it's the only progress. Perhaps it's necessary progress. Sometimes we need to take a step backwards before we can take a step forwards. Reminding ourselves of that. Perhaps drawing some analogies from other parts of our career or the parts of our life and think, are there other times when actually we've taken a step away from where we wanted to work towards and that's being a helpful thing. Make it a little bit easier for us. I'm not encouraging you to go back to micro management and command and control at all. All right. But just think is actually being agile the most helpful thing for us and the team right now? Maybe the answer is yes. And that's where I'm going to call time on the talking side of things. I've got no idea whether any of you are still there. I've got no idea whether any there are any questions out there, but I am going to open the floor. You and are there any questions? We are. We are still here. I'm a native of us still still here. Nobody has asked a question. I love the fact that you all stayed silent for a good 10 seconds. That's fresh. Freak the hell out of me. Yeah, there have been any questions asked in the Q&A panel during the top. I don't know if people are not used to that feature. So I think let's just throw the floor open. So does anyone have any questions for Jeff? Really, really interesting stuff to ensure there's lots of things that are butting around people's mind. Anyone have any questions to lead off? I might jump in with a quick question. Jeff, I wonder if you could give us an example of where you within confidentiality, of course, where you've let a team get worse in order to get better. Well, it's a good question. I don't think of a specific example. I'll be honest, my mind is coming up blank right now, but that's not unusual. So. I'll pick something is actually meant to say this when I was when I was going through my slides. Because one of the first things that I wrote that got any kind of traction was that a scrum master should do themselves out of a job. And that was driven by the idea that a good friend of mine, Mike James said, you know, a good scrum master will focus or good scrum master can cope with about three teams with a great scrum master focuses on one. And that's that's something that I took to heart. And it's something that I pushed for, you know, be great, focus on one team, help that team become self managing, do yourself out of a job. But sometimes maybe we need to actually increase the dependencies within the team. Maybe we need to spread ourselves a little bit thinner because actually helping one team is better than letting that one team go to the dogs while another team succeeds. Maybe having one person in two teams rather than everyone focus on one team is the right thing to do for now, even though it's taking us further away from what we want to be. Increasing our work in progress might not be what we want to do, but actually helps us learn quicker. So kind of like if you're trying to get a team to focus on reducing their work in progress, maybe suggest they increase it and just see how much carnage is used, that kind of thing, sort of teach the opposite, using opposites almost carnage. I like that. So I like it not necessarily because of the word, but because it's made me remember something from this week. So I was asked the question, maybe this is relevant to some of you guys. I don't know. I asked the question. This there's a team that's really, really struggling or the scrum master of the team is really, really struggling to get them to turn their video cameras on during planning meetings, days from things like that. And she said, I don't understand it. I don't I don't I don't know what to do. I can't force them to do it. I've told them why it's a good thing, why I think it's a good thing, but they don't want to do it. How can I? And so what do you want to do? So I want to get them to do it. I want to work out how to get them to turn their cameras on because I know it's going to make the meeting better if we can see each other. So we could pick that part a little bit and say, well, you're assuming that it's going to be better based on your and all that kind of stuff. But so why not do the opposite? Why not say no one's allowed to use their video? Maybe for the next week, we're banning video calls. All right, we're just going to go back to plain old audio and see what happens. And so that gives the people that love audio and hate video the chance to put there, get gather some proof, gather some data for the arguments, but also gives people a chance to experience the other side of things. And it's an experiment. And that it's not quite reverse psychology, but it's well, that's really, really go the other way of my assumption and reduce bandwidth, even though I think increased bandwidth is a good thing. I think that's an interesting one. Yeah. Absolutely. So we've got questions coming in on the Q&A panel now. So I'm going to act as a CMC a little bit here. So first up is from Allison Welsh. So you've been quiet and patience. Then you've tried to suggest, but the team still won't engage and offer ways forward. Do you start to just tell them what to do? I wouldn't just start and tell them what to do, but I would probably ask them what they want from me. So I probably have a conversation about expectations. What a professional coach will call contracting, if you like. So a professional coach can can flex between coach, mentor or different types of roles. But there's a lot more of an explicit expectation to have that conversation at the start of the engagement and regularly as you're going. Whereas an agile coach rarely has that in my experience rarely has that kind of conversation about these are the these are the kinds of ways that I could be of service to you. All right. In an ideal world, we'd be able to mindfully look at what we want when we want it, but emotions and situations and all these things play a different part. So we might get it wrong sometimes. So in that in that really very small example that Alison has given me, my response would be to play back what I've done, why I've done it. And and say that was my instinct. That obviously wasn't what you were looking for. I want to help you. What help can I give you? Now, if they ask for something that I'm not comfortable giving, whatever that might be in the context, I would play that back and explain why. But that's part of that negotiation, expectation, contracting. If Alison is still there, does that help? Yeah, it actually came from a mentee of mine. And she's completely new to the role. She's actually a grad and having issues getting and it's one of those things I know in my situation where I've got. I've been doing this for a little while and I know how I would manage those relationships, whereas she very new, fresh out of uni. And like she's my first ever mentee, bless her for all her. And I was trying to think, OK, how can I know how I would do it? But how would I do it in her position? And that play back way I was very, very useful. Thank you. Cool. Cool. Next up is from Graham Dempsey, who's asking if your own confidence is low in something. Would you share that with the team? So answering purely as me, I would say yes. Because I'm confident in my lack of confidence, which might sound paradoxical. But I've spent so long not being confident and I've got enough data points that generally things work out. That I find it better to share my lack of confidence than pretend I am confident. That's but that's just enough scars, if you like, of doing that. And I don't really have too many too much to lose most of the time. So if I'm wrong and actually sharing my lack of confidence was the wrong thing to do, the negative consequences are rarely high. So it's safer for me to do that than perhaps other people. So I can absolutely understand why you might not want to do that. But I would what I would say is share that with someone. It might not be the team. It might not be anyone at work. But share it with someone. Because once you've voiced that, sometimes you find a reason to have a little bit more confidence than you did beforehand. Getting it sometimes even just writing it down without telling anybody can help. And and something that I've brought up in quite a few of my talks over the last couple of years is is a technique that I stole from stole. Borrowed and enhanced, inspected and adapted from a guy called Tim Ferriss, fear setting. So just listing out all the things that I'm worried about might go wrong. And then what could I do for each of those things to reduce the chances of it happening? And for each of those things, if it did happen, what's my backup plan? What's my recovery plan? How can I repair the situation? And then for each of those things, each of those fears, what could I how can I look at that differently? How can I reframe that? Is there an opportunity with this quite cliche? Is there an opportunity to this threat? Is it statistically highly unlikely? Different ways of assessing the situation. But the first thing is to get it out of my head, whether it's with another human being or a dog or a cat or just on paper and then analyze it. Claire has another question on the subject of letting letting things go wrong. Where do you draw the line that letting it go wrong and stopping it and stop it turning into a social experiment? That's hard to say a generic answer to. I would take each it to each situation on its merits. But I'm a big fan of safe to fail experiments. So I want I want people to want to come back next week. Yeah. And I would as much as possible, want that experiment to be very, very open. I wouldn't want to be engineering a situation where I'm pretty sure they're going to fail, but they're going to be very surprised if they fail. Because I think that's fair. So creating a situation where it is an experiment. Working at all the reasons why they might be worried about running that experiment, perhaps running a fear setting exercise with them. How could we make this experiment rich in learning and safe in failure? For them. But also thinking about the impacts outside of them on the rest of the system, but predominantly for them. And sometimes in my role as a coach, it will be to shield some of that flak to allow them to be safe. But again, that comes with my confidence of knowing that actually. I'm safer. So how clear? Yeah, thanks. Excellent. So David Legg asks, is there a ratio you aim for of staying quiet and letting them learn against making a suggestion and an interview now? No, because it depends on who I'm with. So there are people who are looking for something different from me in their engagement. And we've been working together so long that we can consciously flex our style so they can either explicitly say, look, Jeff, I'm looking for your opinion here, or have you got any experience in this area? And I can confidently share that experience without feeling that I'm overly influencing what they are or are not going to do. There are some people where I wouldn't share my experience, because I think actually what they want is the right answer is Jeff sees it. Either they have too much faith in my knowledge and too much faith in my experience. Or they want to be able to say, well, Jeff said this. So if it if it's wrong, then burn all of Jeff's books, whatever. So having that depending on who it is with what kind of agreement that we've got, where they are right now would determine the ratio. But in general, I am more of a listener than a talker. These kind of sessions, you wouldn't you wouldn't think that. That's because you've asked me to come along and talk, not come along and listen, right? I'm probably something related question. Gareth Jones asked, do you believe you're a better coach in an environment where you're not an expert and can remain neutral? Perhaps he's gone into listening mode, as I promised earlier. We've run out of tokens for speaking. OK. Let's let's wait a second and see if Jeff rejoins us. I can am I here? You are here. You're back. Well, come back. I could hear you, Jeff. It's true. If you can hear us, you've been very staccato. Yeah. So it's any matter. A little bit. Yeah, you come back again. I'd say I think what happened is my son's come home from school and he's hogging the bandwidth again. But. Yeah, apologies. Did you cast that question? It was, do you believe you're a better coach in an environment when you're not an expert and can remain neutral? So I believe I am. But I also know a lot of people would say the exact opposite. My experience of me and I'm the best person I've got experience of is that when I when I think I've got knowledge in an area, I find it harder to withhold it. But I'm aware that because I've been married for so long, I'm aware that I. Yeah, we lost you again. Yes. And during a key marriage insight as well. Indeed. This was it two types of people, those that can extrapolate and. Well, do you know what? At the risk of those with videos on, if you would possibly mind turning them off, giving him some bandwidth? Yeah, I think it's probably that trick often works for the person who's having. Does this qualify as irony? Yeah. We did talk about trying out nobody, right? Yeah. Let's see if that. Oh, no, he's left the meeting. So, Jeff, Jeff has left the meeting. Yeah, I hope that Jeff will be back in a second so that we can at least thank him for all his great insights and the great talk and Q&A. There are still a few questions that are on the that have been asked on the panel, but we might not get to them. I hope that's OK. But in the meantime, let's at least let you know what's coming up next month for Agile Bath and Bristol. Next month, we're we're going to be having a workshop from our very own Gemma, who's going to be running a session called What Agile Got to Doodle with It, which is based around visualization, sketch noting, all these kind of visualizations are very popular recently in Agile Circles and so we're going to be digging into that in more detail next month. And that is on the 13th of April. So we'll be announcing that meetup soon. In the meantime, if you kind of have any suggestions for for talks, if you've got a talk in yourself that you'd love to share with the community or if you have any suggestions or feedback, then then please reach out to us and let us know on meetup, contact the leadership, the leadership group. It is after all, it's your community and we're just here to help facilitate the conversation. And so let us know. I'm just going to check, has has Jeff managed to rejoin us? Looks like maybe he hasn't. So the change up for this evening is for us to have a short break now. Feel free to to to stay on the call. But the official start of our final open space, half hour is seven o'clock. So for everyone who's not able to join us for this for that last session, then thank you very much for joining us for for the talk and the Q&A and I hope you find it find it valuable. When I managed to get back in touch with with Jeff, I will pass on everybody's thanks to that. But if you like to stay around and have a little bit of social discussion, maybe some discussion of sort of the points that are made in the talk or anything else, then then then stay around and we'll either stay on the main call or we might set up some breakout groups. But in the meantime, in the absence of our speaker, let's all say thank you very much again to Jeff Watts. Shall we even try a Mexican wave? They carry something. What was this?