AA99 - How to be a More Respected Agile Coach

Welcome to the Arguing Agile podcast, where we uncover the strategies and mindset. Top tier Agile coaches and scrum masters. Join us as we talk to industry experts and successful practitioners to help you take your coaching skills to the next level. This podcast is for anyone looking to excel in the world of agile. Let's get started. Me, me, me. This is why I don't do intros. Yeah, because like, it's awkward. This episode we're talking about being a top tier agile coach, but also scrum master, but also agile practitioner what does it take to be a better Agile Coach? What do the top tier agile coaches, the people who are sought out for their ability, what do they look like? How are they different? I think vision is the one I would start with. So the, i, the idea that the best agile coaches, , I'm talking the enterprise advocate, like the, the people who can wrangle a, a company segment in the hundreds or above a hundred, basically many teams they have a vision. And also the like, now that I, now that I just brought this up now that I allow me to project for a second there's not a big difference between. An agile coach projecting a vision and, and quite literally anyone in leadership projecting a vision. I think the most successful agile coaches here have a vision. They're, they're not just p punch in the agile clock. Well, was Can you even punch a clock? Yeah. So this is one of the reasons why Enterprise Agile coaches, when they first come in, they follow the, the mantra of, just observe, right? Don't change anything. When they're observing, what they're doing is really establishing not only the brief recent history, but also where are the teams at, where's leadership at? Like, what's the status quo? And once they have., which may take a little bit of time. Yeah. Depending on the size of the the portfolio or, or the business that they're trying to influence, then they need to have a vision because just simply looking at the teams and saying my vision is to make sure that everybody follows these scrum events and ceremonies and whatever else. Yeah., that's not enough. That might be part and parcel of getting the teams to practice good agile practices, but that's just a very small part of it, right? You, you need to figure out, as an agile coach, where you're trying to take the organization mm-hmm., and wherever there is you need, you need now a path to get there. So that's really what I mean by, by vision. Now that's a different vision than perhaps something. Somebody within the company, the organization has, whether they are a manager or leader C level person mm-hmm., their vision is slightly different because their interests are different. As an coach, your interests are to get to the point where, The teams are performing and day in, day out and they're continuously improving. Yeah. So that's the, the motivation for an agile coach to have a vision. Without that, you're just muddling through. I'm trying to think of places that I've been before where there's been a strong vision. For the process because that, that's the segment that I would put in, uh in the agile coach's responsibility, realm of responsibility. Area of responsibility. I don't know, I don't know why I'm even talking like this. This is not a way that I talk normally. This is so weird. but, uh hey, what is the vision for how we all work together? You could say the culture as well, but culture is not necessarily just process. It's part of it. Absolutely. You know? Yeah. Yeah. And I think you I think as far as agile coaches needing to have a vision product, coaches need to have a vision. Sure. Your, your coaching product folks, right. You need to have a vision of where you're trying to get to. What would a vision look like when you say, oh okay, I'm a podcast listener, and I'm saying, okay, I makes sense. What you guys are saying makes sense to me. What is, what's an example of what a vision would be that would be. Jumped. It's a great question. So I think that's probably when everybody sits around the table holds hands and Oh no. Has a seance. Oh. Um, one of the, one of the things you have to talk to dead people. Yeah. Talk to dead people. I see dead people. Um, and one of the things you gotta figure out is who are your allies when you know, in trying to help you with attaining this vision you have, so lemme just roll back a little bit. You have a. What do you do with it? Right? Is it just in your head? And so that's, that's probably a good place for us to kind of initiate this conversation further. You have a vision, you've gotta share it with leadership that hired you. Mm-hmm., get them on board and then say, in order for me to deliver on this vision, here are things that I need. And be, do that very, very quickly as soon as you have a vision established. because without having, means resources. You're not gonna be able to be successful Yeah. In meeting your vision. So be upfront and say, this is the vision. Do you agree? This is why I have this vision. Mm. And then you go in and say, okay, here's what I need in order to do this. Mm-hmm., whatever those things look like, whether it's team members, whether it's tooling, whatever it is that they need, training or whatever it is. and don't be afraid to level at. Leadership there, the C level leadership, the need to coach them. Mm-hmm.. Right. I need commitment from you. Yeah. Mr. C level or miss C level. Right. And, and that looks like this every week we'll meet every two weeks, whatever it is. That's part and parcel of your vision. Yeah. That you will transform also the leadership, not just the teams. Yeah. Well it's, you're transforming the process by which. People work with one another That So your pro, if I'm gonna take this, like you brought up product coach, I, I almost was not gonna bring up product coaching in the, in the conversation here today, but I'm glad you brought it up because it got me thinking that the process that is developed by the Agile coach slash ScrumMaster, whatever you wanna call it, The process that's developed is like a product., it is like a product, meaning it has like, there are things you can measure there are things you can measure. There are things you can try.. , but both of those like you just rolled us to our next category, whether you know it or not. Like the next category is courage. Uh, in the position. Like I think of, and the reason I this segue so well is because the product people have courage when they're saying, Hey, why don't we try this? The product people are assuming some level of risk when they're saying, Hey, we should try this other path, or we should try to experiment with this, or we should try to put some money into whatever to see where it works out. The process people, meaning the scrum master here is going on the same road except I, I kind of would argue their product of the internal process. Like the company, unlike a product where you're trying, where like you need external people outside the organization to buy it and to buy onto it and whatever. You need to find that problem to seek it out. like the process, it change, it costs you nothing to change the process. I mean, it costs you cuz if you go down the wrong road or whatever costs you productivity of your time or whatever, sure there's that, but I'm talking like you don't need to spend actual dollars where , again, if you're running with the cost-based financial model, all this stuff is invisible anyway. It truly is zero, but uh, it's funny. Money . Yeah, it's, yeah. But, having the courage to say, Hey, let's try a change to the process. And then when you're saying a change to the process, you're saying a change, not just to one specific team or whatever, cuz you know, the, you can't make an improvement to one little part of the ecosystem. You know, you ba you basically, like you, you have to improve the bottlenecks. Like it's a whole throughput type of thing. You have to improve the bottlenecks in order to make an actual difference in the whole system, right? So you have to, you have, you have to have a systems thinking of the whole process across the whole organization, like down at the team level where maybe you are parked as a scrum master, but again, all the way up to the business intake level or the, the highest levels of the business, if that's the C level, whatever whatever your business segment. In order to lobby for and pitch those improvements or even attempts at improvements or even getting everyone together to agree that there are problems. Absolutely. Um, that's, that's the, that's courage. here. That's a, that's a value principle. Value. It's . I don't remember. It's a value. now look with courage, right? Any change you wanna make requires courage. The hardest thing in the world is to go into an organization, whe whether you're at the team level or at the higher level, doesn't matter. And go in and say, see all this stuff that you've been doing? Yeah. It's not working for you. Right? Yeah. and here's my suggestion of how you work, that takes courage. That, because you have to convince people that they have a problem to your point, right? And then you have to convince people that you have an alternate that might be more viable, right? So if you come in and say well your practices are wrong. Here's a set of practices you need to follow day one. Like, just go in and say, Even, even if you believe those are the practices they need to follow, the chances of success are fairly slim. because it's too much too soon. So you need to figure out what is their appetite for change, right? What is the, what is the burning need? And then tackle that in an order, right? Mm-hmm.. So it's not necessarily even where you get the maximum return on those changes that you don't just. We're gonna do A, B, C, because A gives you the maximum impact, right. It's perceived impact. Right? Right. Even if it's small. But if it's perceived as, as you being the change leader, you're coming in and recommending practices that other people notice. that's worth it. That's even though you're not getting the maximum benefit out of that specific change, maybe it's another change later on. Yeah. But that paves the way the initial work. Mm-hmm. paves the way for future changes. So you gotta figure all this stuff out. Mm-hmm. right. And, and then go in and say, here's the vision, but in order to get there, we're gonna try this first. Right, right. And, and the focus really should not be do it. Go in and dictate that. Yeah. So you have a credibility issue right away. People are gonna say, I've worked here for eight years or 30 years or whatever. Mm-hmm. And you come in and you, you tell me you know better. and, and it doesn't matter whether you have a resume that's need a mile long, right. Of where you've worked. The thing to do is. Get them to own the change. It's not your change, it's their change. So get them to own it. Mm-hmm. and get them to own it for the right reason. Show them that there is a pain. Show them that uh, you have just one alternate way of working, not the only way. If they have another way, your own ears listen to them. And if they come up with a better solution. Then go ahead and say, let's do that. Yeah. But I mentioned the word earlier, try, right? So frame everything as an experiment. Just say, if we do this, here's what should happen. Mm-hmm. and, and let's just do this for a couple of weeks or a month or whatever, and we'll regroup and evaluate. And if we're seeing things moved in the right direction, we'll continue that. Or if we're not, I'm happy to just stop at that. And maybe we will come up with a, a better way collectively. Mm-hmm.. Right? So courage is central to all of this. You have to have the courage to talk to the C- level folks and ask for what you need. You have to have the courage to talk to the teams and convince them they have a problem, and then they should try something that you're suggesting as an improvement technique. Um, but all along be be open and say what do you think we should do? Mm-hmm., right? Have you tried this? They say, no, we haven't. Can we try that and see how it works for us? Right. Yeah. Yeah. Like the more that I'm listening the more that I'm thinking that You like the product mindset is at play here in the Azure Coach slash ScrumMaster saying, Hey, how, like when you're saying, Hey, have we tried this? Hey, have, have we tried that? I mean, really what you're doing is you're employing a business analysis method of mapping out. The, the border of the problem. Yes. Sh Tell me what you've tried to solve the problem with, or tell, tell me with what methods you've tried to solve the problem before. So you're kind of mapping the the edges, you're trying to find the edges of the puzzle so that you can kind of construct the solution. I mean, you, you're not the only one. You're not, you're not trying to do it by yourself. No. Because solving organizational problems is not a one person. It's gonna require everyone, you know what I mean? The teams are the only people that are gonna be able to solve their own problems. Right. Given however you, you're the one prompting them to put that puzzle together. That's correct. Yeah. And, and don't don't think you have the solution necessarily, or, or potential solution. Sometimes the best solutions come from the teams, so just ask them, pose the problem and say, how do you think we should solve it? Right. If they come up, , a few suggestions that either you don't believe will work, or they've tried and didn't work or whatever, or they don't come up with any, then feel free to suggest something, but ask permission. This is that one of those things that you, you'll see coaches do, they'll say, do you mind if I make a suggestion, right? Mm-hmm.. Um, why do you do that? I mean, you've already been hired as an agile coach. Why don't you just go in with arms flailing and say, do this right now. You don't do that. It's building, it's building trust. Right? You're trusting them to own the solution. When you say, what do you think we should do? What have you tried, right? Can we try this? May I suggest something? Right? And if they say yes, it means they're open to your. input. If they're open to your input, they're gonna value what you have to say. Otherwise they're gonna say, well, here, here comes a so-called expert. Mm-hmm. last three didn't last. Right. Uh, why should this one be any different? So, p yeah. Be upfront, ask permission, and then go in with something small. Treat it as an experiment and monitor that. Yeah. In constantly The thing in this category of courage that that can't be underestimated is asking for things from your leadership. Like, very rarely, like there's a pe People will occasionally say like, you need to you are gonna be managed by your manager, but you also need to manage up. Manage up is not something I have heard in the Agile community very often. The idea that like you. To keep your manager on track and I haven't heard that very often. Like I, I put that into this category as well. This, this courage category, it does take courage. I mean, you see some agile coaches, the just say, We can't really manage them. Right? Yeah. They, you, they're the ones that hired us. Yeah. Precisely. Why you need to manage them because they have different notions of what success is. Mm-hmm., right? Mm-hmm. and they're bringing you in to validate their notions and feel free to knock them down, but do it in a way that you know is palatable. Right. It makes sense. that's an interesting one too, because I've seen quite a few scrum master that are unwilling to question the people that own the budgets. To the people that hired the, like contract scrum master there. They're not willing to question the people that hired them. Basically, or maintain their contract if they're contractors, that kind of stuff. Uh, and that's a, a failing of courage. Like these people brought you on because you're the expert. They believe that they believe or believed Ed, past tense that you or the person that could improve their program or that you could make a breakthrough were all the rest of the people in that spot didn't. And, and you may very well find either like they are the problem or leadership is a problem, or somebody someone. Team level, not not, not who, someone who is not your peer basically in the organization is the issue. You're absolutely right. I see all too often, lots of Scrum ambassadors just checking the boxes. Hey I'm. Facilitating this daily standup and do it and facilitating the review or mm-hmm. or the retro. And that's it. That's all I do. this segues into a couple different categories. In a different podcast. I, I brought up a concept that like, I just barely touched on it, and then we move. We didn't really talk about it very long, where I was like, as the process person and the person that is charged by the teams with stakeholder communication, like radiating the message out from the teams and helping the teams better help the organization understand what they're working on, what the priorities are, what's next, that kind of stuff. I was like, you need to communicate like a doctor. Like if you ever go to a doctor's visit and doctor's like, oh, you hurt your arm home. I'm gonna touch your arm now. Is that okay? Okay. How does that, does it hurt when I go like this? Does it hurt? Like I go like this. What about whatever? And like every they're basically narrating their actions every step along the way. This is what I'm talking about, only the scrum master or agile coach, equivalent thereof, everybody they go to. That's a great analogy. I love that analogy because you're right. I mean that, that's exactly what happens, right? Um, the, the., the other party in this example, it's the patient it isn't simply told things. Mm-hmm. because they're not gonna receive things very well. Right. So the doctor makes sure that they communicate well including the reasons why. You know, I'm going to raise your arm above your head to see if that makes the pain worse. Mm-hmm.. That's why they're doing that, not just doing that for the heck of it. Right. So it's the same thing. Yeah, I agree. I think that's, that's a critical skillset with Scrum Masters and Agile coaches. Yeah. The, the funny thing about a doctor is like, you don't really realize that they all do this until you get one that doesn't do this well. And then you get your doctor with a bad bedside manner , which is funny cuz like the, the whole profession has attributed these, this set of communication skills, which that, that you or I might know is like, it takes real work to get your communication skills to the point where like everyone in your career field has kind of looked at the same we're ba basically we're like a I guess what I'm saying is it takes a lot of. To get to the point where just outside observers look at your positioning and they don't see anything different from the last person. Cuz everyone's communication skills are up to the same. They're all race at the same bar. I think of the Scrum Masters and Agile coaches being the ones that have deep connections with people throughout the organizations because they're deploying the, the, the tactic of one-on-ones. They're having a regular one-on-ones. With all of the key players and whatever team members and stuff like that. But they're figuring out who to have one-on-ones in the organization and they're building influence along the way and that kind of stuff is invisible to everyone else. Right. Which is funny because it is, it's just as invisible as the topic I'm talking about now of, oh, the doctor has good communication. Yeah, yeah. Completely agree. So when we do come across that odd doctor who doesn't have good bedside manner, that's equivalent to the scrum master, simply checking the boxes, right? If that doctor's gonna come in, do a cursory examination. You know I mean, obviously other than something that's really acute if you're falling over with a heart attack, that's a different thing. But and then they're just gonna take your word for what you say and say, here, here it is. Go. You know, here's a, here's a script. Take two in the morning, call me in the morning, take two. Now if it hurts more, take two more. That's it. Uh, I mean, so yeah, people are different, but to your point, in that profession, medical profession pretty much most doctors have the, those skills refined. Mm-hmm., that's why they call that practicing medicine. They practice it and it's not just book knowledge or technical skills. It's all of these things too. Yeah. Yeah. They actually get graded on that. I was gonna say, it's, it's, it's also years of scrutiny as they go through their training and, and all that kind of stuff. Yeah, through the process. Very true. Oh boy. Like we did, we just hit on a, a did we just hit on an internet landmine of scrum Masters having to go through some kind of professional residency type of ? Oh, no. I'm not ready to be making statements like that. although I will say the whole concept of the Scrum masters or as coaches or, or whomever., I don't think that's a correct way to use that. Uh, the whole concept of them having one-on-ones and building influence in the organization uh, I have never seen that built into a metric. like hey Om, it's the end of the year. We're judging you based on our corporate metrics that you don't pay attention to. And then in the last in, in December when you know that your yearly review is coming up, you start scrambling to hit your, check your boxes or whatever, like that, that kind of, you know what I mean? That kind of like yearly performance review kind of stuff. I, I don't think I've ever heard of anyone saying you've had x number of one-on-one., you know what I mean? The , that's primarily I, I, first of all, I agree with that, but primarily I think that's because these kinds of techniques aren't really. Known all that well. Mm-hmm. in management. Yeah. Leadership, hopefully get it. Management don't they're not known and they're not valued necessarily. You know, why do you have to meet every week? Yeah. Right. You know, let the person develop code. That's what we pay 'em for. Um, so yeah, I, I think an astute agile coach or a scrum master knows what to do. Mm-hmm. and doesn't necess. Advertise they're doing that. Oh boy. You could even say like, your, your segment of leadership in your organization might even understand why it's important to have these, but because you're taking developers away from. Coding when you're having your one on one taking your developers away from being productive. Even your leadership might be undermined by corporate level. Yeah, yeah. Metrics and goals and like the, the manager director development might, might be like, oh stop having so many one, Hey, instead of having one-on-ones with my people every other week whatever, once a, once a sprint or whatever can you do that? Once a quarter, because I mean, that's a lot of time if you look at it, but it's one hour every sprint with everyone of my people, and they have six people on your team. So that's six hours, that's three hours a week, and then that averages out to this many a year and we're losing this much productivity. That's the way they were painting. They're losing they's exactly what they do. You're right. They extrapolate the heck out of it and they go, oh, you're wasting a sprint every month, or whatever it is. Right? Yeah. Right, right. They could be developing code during that.. Um, but yeah, I find that's mostly management rather than leadership that does that. That's a metric in search of a problem, right There is what it is. The, the other thing with this is like if you have achieved some level of expertise in communication like this, like you probably are the person driving out into the organization talking about when, when deadlines are about to be missed or when commitments are not gonna be hit, or when the team is going off track or. You are probably gonna be the person driving ahead of your team to soften that blow throughout the organization. It again, assuming you're in an organization where a blow needs to be softened., right? If you're in an organization where you talk directly to customers and you only go a couple days and say like, maybe this is not your problem. Right? So for those two people, thanks for listening to the podcast for everybody else in the whole world, thi this is somewhere where a Scrum master or Agile coach can help a lot. Yeah. For most people out there, this is a problem that needs to be right addressed. And this requires courage. Um, absolutely it does because nobody wants to, nobody wants to relay bad. right? There's only one thing worse than relaying bad news, and that's relaying bad news later in the process. Are you right? Yeah. Yeah. So just be upfront. And you say this is, but also, here's the other thing., if you're going in with a message that says, oh, we are gonna miss our deadline, don't stop there. Right. Going in with some underpinning rationale and we're missing our deadline because we had to pull two developers off to work for this feature that needed to be demoed at a trade show. Mm-hmm., because our CFO. wanted to do that. Mm-hmm., whatever it is. Whatever. Oh, we had five people off for MLK Day. Mm-hmm. or People's of Sick, whatever it is. Going with some rationale. Yeah. Um, and then the other thing, the last thing on this topic is if that's a problem, which it almost uncertain certainly it is going with one or two alternate solutions. How do you make sure this doesn't happen again? Because you know you're gonna get asked that question. Yeah. You missed the. What happens next? Yeah. And you could say we're gonna make it up in the next print. Okay. But if that happens again and again, that's not good. Yeah. So the, the this question will come at you. How do you make sure this won't happen again? So go in prepared with an answer to those things. maybe like if, if I'm gonna take the arguing Agile approach on this one, I'm just gonna jump straight into the next category. Mm-hmm., because the next category is about projecting confidence, not just having confidence, right? It's about projecting confidence. If, if you know that you're gonna get asked Hey, I'm gonna, I'm gonna go meet with our whatever executive stakeholder, I'm gonna tell them that, um we can't have a demo. I got, we have to push the demo back. Maybe we can't have a demo. This sprint for example, we gotta push a demo to next sprint push demo for a couple days, doesn't matter what it's, and it's not a matter of people are out vacation, sick. It's not a matter of that. It's a matter of we found something. Or we've evolved our understanding of the way things work, or we ran into some kind of technical blocker or something like that. the projecting competence part of that is first of all, don't try to BS them., right? J just tell them the flat out truth of, Hey, we ran into this technical blocker. It ended up being more complex than we thought it was. The typical time that something like this will happen is when either we're working, it's funny, it's a one, it's an extreme or another. Either we're working on legacy code. and changing one piece of the legacy code sends you down a rabbit hole. Mm-hmm. of cascading problems that you have to either be very careful to fix or you have to just fix 'em all, or you have to go change the way you're gonna do things in the first place. And the other side of it is, Working in some brand new technology that nobody knows, you know what I mean? And we're developing it for the first time. Or maybe we're proof of concepting something out with a new technology that we've never worked with before. Like it's one of those, like a very, very olsa, very, very new stuff. Sure. Is usually where you have , that kind of problem of, Hey, we said we were gonna do this, and then when we got in there, we realized it was, it was a lot more complicated. We need to take, we need to slow down, take a little more time to figure out how we're gonna do it. because of that, we need to push the whatever whatever the deadline deliverable, whatever it is. That's a pretty good situation to be in. If you have if you have rationale like that, because that's gonna be badly received., you, there's a reason why you've missed it. Mm-hmm., and you haven't really missed it. You're just simply delaying it. And that's because you've learned something. Right. And that learning means what? Right. That learning means you pause and you've pivot or whatever it is. Those things are quite well received most of the time. Right. because what's the alternative? Just like be a a blinkered horse and just drive through and know it's gonna fail now. Yeah. So, again, don't wait until a certain time, which is often misinterpreted in. Agile is the last responsible moment, right? If you've learned something like this, wave the flag early. Just say, we're going down this path. Here's what we've learned. We're gonna pause. That means no demo this sprint. Mm-hmm. and if you do that, I don't think you can go wrong. I think most of the time leadership's gonna say, okay, we understand why. Yeah. Right? Yeah. Uh, that you may get questions if you're not clear about your messaging. If you say we've learned something new, caused us to pivot. What have you learned? Right? What's, what's next? How big is the pivot? Mm-hmm. you'll get questions like that so you can get ahead of that. Yeah. Well also, you shouldn't be the only one as a coach, scrum master, like you can go a long way towards helping move those conversations along in a productive.. However, the two examples I just gave are pretty much product centric examples, so you shouldn't be the only one in that conversation. Sure. And again, it's, it goes a long way of projecting confidence when when you partner with somebody else, cuz now it's two on one and that, that should help you with your confidence a little bit, yeah, yeah. Agreed. Absolutely. Strength in numbers, there is, I mean, so, so there's some general stuff to, to help here. Let's say that you're developing the. process, right? Let's say it's not something product specific. Let's say you're developing like a, like for example I'm a leadership and I'm saying, Hey how come this new team that I, I created a new team for this new whatever. I split a couple team people from team a couple people from team B, and I created a new team C, but team C seems to. Um, not advancing very quickly. You know, maybe it's taken them three months and they're still not really producing they can't get stuff finished, sprint to sprint, that kind of thing. Pretty typical problems. If something is, process related., you, I think you still can project confidence, like you can still project confidence, but projecting confidence in this, in this arena requires you to have evidence behind you. You need to have data behind you, is what I'm saying. So if you're an agile coach or scrum master like having that experiment log that we talked about way at the beginning that really helps you just say, These are the things that we tried. These are the things a typical team needs to do, yeah, I agree. I think evidence is key here, right? Otherwise you, it's just your opinion. Yeah. Right. And everybody has those multiple opinions usually., so going with evidence but also don't forget to. go in with some knowledge that you have that, that others may not have. Like for example, in that you cited team C , pulled together. Yeah. With bits and pieces from A and b. Go ahead and show that. Teams need to go through a certain process mm-hmm., right. The, the, the tuckman's model. But, so if you explain it like that and there's rationale, people can underst. If, if you just say, well, they need time, and then next time it's the same thing. Yeah. They need time. That's not gonna fare well. Right, right. Yeah. I tell people this all the time. I was like, you're, you're either gonna run outta money for whatever you're funding the team from is gonna run outta money, or you're gonna run out of LE leadership patience. And then like those are very real. You can call it political capital, whatever you wanna call it, but like it's, you're gonna run out. If you don't show some kind of progress confidence aside you can do a lot when those people are asking questions., by having confidence in understanding that where you're leading. is the right way to lead, but at some point you're gonna need to show evidence. Absolutely. I, I think the earlier you show evidence, the better. Right. Otherwise, it'll be misconstrued as you kind of just Right. You know? Right. Either flying by the seat of your pants or trying to wing it. Yeah. And that's never a good thing. Well, hopefully you won't have to do that. If you have a vision that if you have a vision for every team and how every team kind of weaves together in service to the larger organization, then you won't have to wing it. because like winging it is like that's a surefire away where projecting confidence starts to breaking down because you're not sure anymore. Correct. You know? Correct. And then your assertion, one of your assertions will be completely out and left for you and without you even realizing that. Because it's not evidence based. Yeah. So, so just in that last example, team C, if you can, if you can see on a, a table or a graph that team C is actually improving sprint. On sprint, they're just not there. Where teams A and B are, right. Cuz A and B are more mature teams. That's a good story. Mm-hmm., right? They're improving. And then you could use the power of projection and say in five sprints we're gonna be at the same level. Right. Or, or whatever. Right. Right., that shows. Got evidence to back up the fact that they are still forming or whatever stage they're at. Mm-hmm.. So, yes. That, that's a, that's a good point. Have the confidence to. Basically use the numbers to underpin your story. We haven't even touched on any of the stereotypical advice that you would get about projecting confidence, which is all true and applicable to what we're talking about now. In order to project confidence, which you, the pseudonym for projecting confidence would be to be a better leader in order to be a better leader., everything we talked about with communicating more clearly. Everything we talked about, about having courage when interacting with people. And then, and then starting kind of with the vision of where you wanna go to the future. All that stuff is all these are leadership traits. Boy, this is the leadership in disguise without saying leadership podcast. Like this is the don't say leadership podcast. Uh, in order to project confidence, you have to have all that stuff, but also it has, the presentation has to fit all the rest of the categories. This is where I'm gonna get, I ex if I'm gonna get dinged for anything I'm saying, I'm gonna get dinged for this category because I have an intern. Like I, I think it, like earlier in my career, I had an internal bias cuz you had like, there are those. Like, if you think about your stereotypical car salesman, salesperson, like they're, they're like, Hey buddy, hey guy. And then they smile a lot and they, you know what I mean? They, they're always positive and upbeat and that kind of stuff. Like sure. Some of that is an act like they're, they're, they're acting like that. Uh, however some of that is genuine traits that you need your leaders to embody. You need them, generally speaking, to be positive. You need them to be the ones with the most, I think the same thing. I think of like your product people. You want your product people to be, to be the most energetic people. When it comes to you talking about the vision and future of your product. Hey, absolutely. Enthusiasm is infectious. Right? Right. If you don't have it, people are gonna certainly notice very clearly the lack of it. Right? Right. And that also is infectious. So, , you, you really gotta rally your, your team around your way of projecting confidence in this example. Right? Right. And having that, and I don't think it needs to be necessarily like practiced or, or fake or anything. I mean, if you're a product person, you're a product person for a reason, you know that that's the path you've chosen. Same thing with an agile coach. You are there because you genuinely care about. Teams and improving the process, right? So just don't hold back. Don't hold back and say, well, how is this gonna be interpreted? Maybe I'm I'm the only one Right. Saying all these things and nobody really cares. Right. Uh, you need to be evangelist right here. Right, this is why I wanna do a whole podcast on Carol Dweck's mindset book. Cuz the idea is there's some people who say, well, I just can't like like the, the, the people who complain a lot or gossip, you know what I mean? Back biting is another, like the little bad, little tiny, little bad behaviors that leadership will see and then kind of identify and be like, well, I don't know about this person. That kind of stuff. people will say, well I can't change. Like, that's just who I am. I, you know what I mean? It's I'm in people who are negative people. Like that's just who I am. Well like if you read that book, you'll start to realize like, yes, you might have been raised that way, or you might have these traits in your personality or whatever. but that doesn't mean that that that doesn't mean those behaviors, no matter how , deeply ingrained they are, are not changeable. And that that book is what it's about. It's about that book is what all that kind of thinking is about. Um, you have behaviors you consciously are aware of them. I guess that's step one and become consciously aware. Yeah. And then you have those behaviors, you can change them. Even thinking that you can't change 'em is a mindset. and you need to overcome that. So maybe you're like, I, I, I've been with a, um quite a few project managers across my career that are like, they think negatively, you know what I mean? They always expect dates to be missed and stuff like that. Like there, there, there is there are ways that you can overcome these things. This is the only reason I'm bringing this up cause it's like only tangentially related to what we're talking about. Is if you find yourself with these negative traits, you can't overcome them. You just need to put in some work to overcome them. Yeah. I think we're squarely now in the in the domain of emotional intelligence, being self-aware. Yeah. So if you are not self-aware, you are really just going. Like a molecule in brownian motion just that random, right? Mm-hmm.. so the first step to your point, yes. Self-awareness, right? And then realizing what you are, where your limitations are, and where you want to improve. I agree fully that the, the traits that you have are plastic, they can be molded, right? Yeah. You just need the motivation to do it, right? And I, I want to close this podcast with the, the last item that I had written down, which is do it with questions. Communicate with questions , in the realm of being a good angelist scrum master as a coach, whatever the idea., that you, you, you probably do have the knowledge, especially when you, when you get a couple years in, you probably do have the knowledge to tell people, well, you should do this, you should change your processes and do this. However that's, that's, that is almost never going to work, . Right? Right. The, so it's for several reasons. It's almost, it's, which is super frustrating to me because I'm like, well, I, I I if you, it's super frustrating to me. I, I think I could be wrong on this one. That is also super annoying to like business leaders who would just prefer to just snap their fingers and solve the problem, like, wow, I'm gonna pay you as a consultant. Uh I'm gonna pay Brian and Om's software development company to. And fix things for me. Why do I have to go through three months of my team forming and storming before you start figuring problems out? Well, because like your team has to go through these processes. They gotta learn to work together. I could tell them, Hey, you need a working agreement and you all need a definition of done before you put stuff out. And you know, this is how you should go through the phases to, to decide. Like, I could tell 'em that, but like the first time they run into any kind of hurdle or obstacle, they're gonna say, oh, this doesn't work for us. And they're gonna abandon it and they'll never try it again probably. Right, right. Yeah, yeah. I agree. And they'll blame, they need to own it and they'll blame you, you cuz you're the Agile coach who said that to do this, right? Absolutely. So I, I think what's underlying all this is they need to own the solution, right? That's step two. Step one was they need to recognize they have a problem, right? You can help them with that. But step two is they need to own the., right? So leading with questions is an excellent way to do that. Mm-hmm.. So instead of telling them oh, you should have working agreements, just say, what if we had a set of rules that we all agree on how we're gonna work together? Maybe like a social contract, right? And they may ask you questions, oh, well, what would be on that? Right? And you could potentially suggest one or two things. Well, how about we start with meeting etiquette, right? We can put that on there. Um, like for example, no meetings after 4:00 PM Eastern or something like that. Mm-hmm. something that you know, that it's not gonna be earth shattering to them to implement that. Yeah. And then empower them by giving them a, a, a a blank canvas and say, I ideate away. What would you like as your own team? Internal team agreements. Now they own the solution. Yeah. Now, whenever they come up with those,, have them talk through those instead of knocking something down, right? Mm-hmm., because somebody's gonna come up with something wacky occasionally. That's okay. It's coming from the team. Let the team decide what to do with it. so yeah, starting with questions is a great way to go., even if it's a suggestion from you, right? It shouldn't come across as a mandate or an order. It would be along the lines of there's this one way of working that I've. In the past. Do you think that might work here? Yeah. Right. Yeah., there's always questions ask questions. Yeah. I want to ask you a question. ask me a question about asking questions like I am, so do do it with questions like your communication style. Try to shift it into a more asking questions that fits completely in line with projecting confide. Because you certainly can project confidence, but like I would say annoyingly project confidence by asking questions., people are like, just gimme a solution. Like, well, what would it solve if I just give you you can be really annoying with, with, with this, but projecting confidence. better communication skills, communicating like dr. All that courage. However, the one that kind of grinds in my brain is challenging through questions. versus projecting a vision because at some point you are the leadership representative of our process, but now you're trying to get the teams to align a certain agile concepts. I'll say, well, I'll call 'em concepts, values, principles, whatever., so you kind of know which direction they should be moving, and you're projecting a vision. for the future. So how do you, like a vision is like telling, unless you're getting everyone together to work through a vision together, which even in that case you'll still kind of be Yeah. Suggesting like so how do you consolidate asking questions with your projecting of a vision? Great question. So first of all, let's just make the difference clear. The, the difference between projecting a vision from a process perspective. Yeah. as opposed to coming out with a product vision, that's a different thing, right? Mm-hmm., because that needs to be ideated among various people., as far as the process vision, if you have that in your mind, you need to be very clear about showing people what that is. You're not, this is not up for debate at that point, necessarily. What you can do is this. You can say, we're. We want to be here, right? So it tells people where you want to try and get to. Now you put in some stepping stones along the way, and you say, in order to get there, we need to get to this first. S you know, marker, if you will. Mm-hmm., how do you think we can get there? That's a different question than what's our vision? Right? They already know the vision. Yeah. They already know that. And you've already put some dots in, uh that say we need to do this, this, this, do this. Right. In order to get there mm-hmm., but you're not now dictating to them how they should do that. By asking the question, what do we need to do in order for us to get from where we are today to this first. you know, mile marker if you will. Right? Yeah. What are some of the things we can do to get there that's questioning the team about coming up with brainstorming ideas, et cetera. That's not necessarily dictating, but that's telling them what the vision is upfront though. Mm-hmm.. So they're trying to come up with suggestions and solutions that fulfill that vision. So yeah, I, I'd say be very clear about projecting confidence on the vision. You own that. Mm-hmm., you need them to own it first. You've gotta communicate it. Give them the why,. And never forget the WIIFMs. Right? What's in it for me? Mm-hmm.. Tell, tell the teams why by doing things a certain way, we'll avoid , weekend deployments. Yeah. Wouldn't that be better for you? Yeah. Right. Yeah. Yeah. It, it's always about fulfilling the, the WIFFMs I don't really see a difference between projecting a product vision and projecting a process vision. Like this is a lot of the steps actually are very similar to me. That's similar. I guess with the product vision, I was thinking you might actually get some feedback in from maybe even customers I process. I think the same thing with process. If your process vision has you transitioning from sending out random release notes to random people or whatever, now you're gonna find someone from your customer base that is representative of that persona. Yeah. To present the work to, every time a segment of work is done, whatever that segment, that feature story doesn't really matter. The point is, the point is the, the where that wraps back up, rolls back up. Rolls back up. What? I'm like terrible analogies all day long. You need a terrible analogy. I got a terrible analogy for you. That's my vision. Not terrible analogies all in the podcast. When, whenever that connects to an upstream item Yeah. That we've developed. I'm gonna bring in a customer and, and connect it. No doubt. No doubt. So there are more similarities than difference is what we're saying here. Mm-hmm.. And I agree with that. I think. I just think that with a product vision, somebody doesn't walk into a room and say, this is how our product looks. They might, they might , but then they're blocking out all these sources. Not at my companies. They don't Yeah, because I'd be like, get outta my room, . Exactly. Exactly. So sometimes the best ideas come from people. Speak very little on the teams. Right? Right. Yeah. Um, so you just need to make sure they have the opportunity to do that and, and seek that out. for a podcast that I didn't really think we were gonna get much out of we ended up going really, really deep. The idea is, if you wanna be a better agile coach or scrum master let's develop a vision of where you, what the future looks like for you. Right? So you are living in the moment, but then everything in the, and everything in the future you're projecting towards. Yeah. You have the courage to deal with all the problems that you're dealing with. You are communicating, having the courage to communicate, and you're communicating your. You're projecting confidence in the last three categories, and I mean project confidence in your vision, confidence in your communication method, and in in your ability to engage on topics. And then , your communication style in, in all the above is a more collaborative one. Oh, yep. I used the word collaborative, a more collaborative one. Where you are asking questions to bring people in to your thinking? Yeah. That's a great summary. I think, I mean, the only thing I'll say is the, your communication. Is not just one style. Right. It, it's basically gonna be different based on not only who you're communicating with, right. Who the target audience is. Right. But the circumstances. All right. Well, let us know what you think and don't forget to comment down below and like, and subscribe.