Measuring Your Success as an Agile, Product or Team Coach (With Michael Lloyd)

There is a relationship between this thing over here that someone is doing and this thing over here that someone else believes is impacting them right. A great example of this is if product owner never attends print planning. and the developers are saying we're unable to appropriately plan our work because we don't have the product up. We can do all the coaching framing stuff that we want, but that's a fairly direct link. And we should just make that clear. Now how we solve that problem, my first thing will be to go to the product manager and say, hey, the team's struggling with this. What's the problem that's prevented you from planning? And someone who's a much more coaching coach might even go in just with some open framing questions to help them see the problem right. You might take it in a much The better end product way. is a deep rooted belief that people and products evolving together can achieve mutual excellence. Welcome back, we are here for episode two of I Hope! It's going to be free, but let's see how we got you you you Get on for time. And with Michael Lloyd, Michael is someone that joined me for the previous episode, where we spoke a lot about. the state of training and certification in the Antraw world and how that compares or doesn't compare to what happens in the product. community. We do a lot of conclusions, maybe not conclusions. A lot of thoughts were shared and I feel more educated as a consequence. And I think a little bit lighter having got some of my chest. So if you want to know more about where we got to On this lovely meandering conversation we had around everything from safe and product. Scrum and Scrum Master roles and certifications in due to cut episode number one. because we are putting all of that behind us and we are going to be talking a little bit more about measuring success. as a product coach, agile coach, scrum master, whatever it might be. Now Michael, I'm not going to ask you to introduce yourself. Again, he did that on the last episode. So if you want to know more about Michael, check out the show notes. There's some links there to his LinkedIn profile and anything else we mentioned. or check out episode one to learn a little bit more about him. But let's not, Dilly Dally. Let's crack on with it, shall we Michael? But let's talk about measuring success. Nice. Yes. Where should we begin? So, yeah, I guess I'm just thinking about our last conversation and I think the bit we we wrapped up on is how do you give a bit more guidance? to scrimmast as an agile coach so that they know that they're successful in actually helping teams helping organizations to get better. And for me, I guess I've got a question for you which is. Do you actually feel as a coach when you've been in teams organizations that the organization understands your value, like generally as a rule, do you think that your value has been well understood? I always feel that it isn't until the day that I decide that I'm done. Yeah. It's at that point when people start saying, oh, we're going to do that. You've been brilliant. And I've always really struggled to understand my, I don't have any like preconceived maybe. I do. Maybe I have preconceived ideas about what the value is that I add and then I don't see that happening. Yeah. And so actually turns out the value I was adding was something very different. I just didn't realize at first time. I think it's because I'd set myself expectations that would probably make me unhappy because I was asking too much of myself. Yeah, yeah, I think that's a common one. However, yeah. Sorry, so yeah, so no. Am I valuable? Yes. And I finally brought in a way that historically I thought I was going to be no. And do I now measure that? Yes, I do through feedback and also working on short contracts where The client has every opportunity to not renew quite frequently. Pretty quickly. I don't think you're valuable. Yeah, and that's a good one actually. I think it's more. Yeah, so I certainly echo a lot of the sentiments, the interesting one that you mentioned that I think we all need to be better at is. How do we ensure that we're actually putting ourselves in a position where we can essentially be falsified, right, as in our hypothesis, our value statement? and could be shown to be not there or not in alignment with what the client wants, and that we can then adjust. Right, I think a lot of people get stuck into an organization like, I'm here, I'm being paid, my job now is to just not get fired. I think that's an understandable thing that everyone gets caught in. But yeah, the other interesting thing that you mentioned is that risk of burn out As as you you go after, there's like so many fires, there's so many things you can chase in an organization, so many directions you can be pulled in and it's really easy to just overdo it and try and solve everything. I think that for me is why I had a moment of realisation a few years into doing this thing, this coaching journey. Which is you, yes you need to measure the actual outcomes in terms of are the team delivering the right value? Are they doing it frequently? Are we adjusting our plan? There's those sorts of things i think everyone knows but the coaches don't necessarily want to take. We don't want to take credit for those sorts of wins either, so we're a bit antsy about tying ourselves too directly to those things. But it's this second thing that we often miss, and one of them you mentioned, I think is brilliant, is getting feedback, is actually making sure that the people that we're coaching tell us that they're getting benefit from it and I think a lot of people don't put enough stock in that. But then yeah, the third one for me that was I think the better the epiphany is can I actually demonstrate that the actions that I've taken had the intended consequence? Did my actions as a coach? in a team or an organization make the problem that I perceived go away and that's something that's really hard right because say firefighting jumping from at all these least if problems like how do you put boundaries around the work that you're going to do and simplify it and for me that's what, as a mutual asset, I'm not aware of that dysfunction mapping thing is it's all about how do you observe what's going on, how do you form patterns and then instead of just jumping straight to action, form a hypothesis. And so I think, for example, I can see a bunch of things. The team's highly conflicted. They argue with each other a lot, they're struggling to achieve their sprint goals. The daily scrum is 45 minutes long every day right and seeing all of these things. And I could go after any single one of those things. But instead, if I take a step back and I say, is there an underlying theme that connects those? Could it be that actually the team is not collaborating frequently enough, they're not talking to the product owner, we aren't defining our work well enough so we're starting work that's just not ready to be started. And so maybe the coaching action that I take is to shine a light on this problem, let the team know why these things exist and then maybe bring in some structures from Scrum or XP or SAFe or something else. So to put some stuff around it, and then I should see as a result this stuff that I observed, the overrun of scrum and the height and conflict, I should see that start to disappear, right? And it gives you a way of measuring your success without needing specific card metrics, but with an actual measurable, I did This the stuff happened. That's good. Or sometimes I did this stuff, didn't do what I thought or everything got worse. Cool. Now I've understood this relationship between these things a bit better. I can try again. I think that for me is the bit that we really need to get better as a practitioner and a community of sharing with each other. How do we build those hypotheses and Test them and see what impact will I get on from? I did something similar with systems modeling years ago and there's actually a... live stream on LinkedIn somewhere. I see if I can dig out and put it in the show notes where we work together. I say we. It was a product owner representatives from three teams maybe and I chose delivery manager as well. Work together to get a systems model based upon what they believed was happening in their particular part the of your organisation. And by doing that they created hypotheses. And from looking at the systems model by looking at the stocks that they had articulated within it, they decided which ones they would like to increase. and they and share why they would like them to increase and then they went off on a to a four nightly basis and ran experiments to try and increase the things that they fought. would increase by doing the things that hypothesized would increase them. And by enlarge it was a resounding success. Yeah, they really enjoyed it. And it was effective. So we had, if somebody wish we could tell a story with. And the interesting thing was that, out of the three things that they... wanted to improve two of them they smashed out the park which was customer engagement and team engagement. They were measured them, everyone was happy. The one thing they really wanted, above maybe the other ones, was for the leadership team to... to like them and engage of them more. And there's the one thing they could never create a hypothesis which actually resulted the in effect they wanted. Which was for me they really proved yeah, it was really proved yeah, proven interesting point of assistance is more. modelling which is sometimes it's great and any kind of mapping which is not for you to see hypotheses of course in effect what you want to increase helps through case actually understanding. and creates a lot of motivation for then what people will be doing but at the same time it's never been there. It never gives you the ability to predict the future. It is always just a hypothesis as you said. Right. Yeah, and it's so interestingly one of the things that we talked about, I think last time we had a chat was Kinevin, right? I'm a big fan of that as well. a way of understanding where in the world we are in terms of what complexity in chaos. And the thing that's interesting for me is a systems modeling is a cool It's a cool way of understanding the system if the system is within a certain boundary of complexity. I'm not an expert in this, so please break me from wrong. But the challenge can be the more complex of the more chaotic really the assistant becomes. The harder it is to actually even understand what the connections are. And so the thing that I found as a coach and I often talk about this in the destruction mapping content is that we developed this kind of spider sense, right, as coaching spider sense that We can see this pattern. We get the sense that these things are connected, but it's really hard to demonstrate that connection through some objectives. identification of the system because it's just so complex and there's just so much potentially even chaos. And it's for me it's about having the two things right it's the ability to form that hypothesis. and say, hey, I think these things are connected. And without needing to then just say, hey, trust me, I'm an expert, I know these things are connected or having to try and find out what it proves at these is things. connected, you can just say, hey, this is the pattern we're seeing, and if we do some of this cool stuff over here, we expect to see some outcome. It's your expected, you're not asking for as much buy -in, right? It's not trusting me, I'm going to save the world. It's hey, let's just see if we're right about this thing. Let's just see if we can make a change and go in the direction we think it's going to take us. And I think that over in my experience has been a lot. more helpful in getting buy -in for change from people because I think Agile Cook just sometimes are perceived a little bit like shaman's We're just going to come in and wave our magic stick and stuff is going to change but we can't explain why. So giving people a little bit more of, oh hey look, my intuition tells me this, I'm going to test it now and here's what we should expect to see. It's just a lot easier to trust someone making it, making that approach. Yeah, and it's interesting because I think any approach which helps you to create. a hypothesis and rigorously think through how you would like to approach something. With the assumption that you have And I had a good idea of where you're going, would give any type of coach something to measure themselves against. And if you look back, As I mentioned about professional team coaching for it as an example, there would be a very clear goal that you're trying to achieve a team would have articulated that you would have helped with team articulate that you engage with them. on a chapter, a periodic basis, so yeah, as chapters, effectively like periods, and you wouldn't be there all the time. And your measurement of successes are the team attaining the things that they wanted to attain or are they evolving there? ideas and hypotheses about where they want to go and that is how you know being successful and if you're not successful they won't pay for another intervention. Anything which helps us understand and bring it together gives us something that we can hook on to. I think the problem with agile is that it's so broad and things that we look It's at it. a big area, it can seem very complex. I don't think there's ever an objective model of a complex environment. It's always going to be subjective and I think there's there's more that can be done around for tools and things we can use to help the understanding that. of that. When you look at the product world, there's definitely stuff there which you should just be doing either at some level and whether it's taking 10 seconds. or 10 days, there's certain things you should be doing along the way to make sure that the bet that you're looking to make, the feature you're trying to put out there, the investment you're making and creating some something features. that you've got the confidence it's going to pay off. And I think as a product, with a productivity type coach, actually it's somebody who should have experience in delivering products and working at JL environment. And it's almost easier working on the product side because you can give us some stuff which is going to happen regardless of the context. I think when you're looking at a big organisation, if you're an agile coach, you're supporting to work across many teams at a much higher level than just at the team level. level. I think it can be overwhelming and very hard to measure success because that system is going to take a long time to change the way it's behaving. and the long times the any type of measurable effect is that idea of the boiled frog. It's actually that the effects of what we are doing will take a long time to be felt. And if you're a frog and you put the frog in cold water and you gradually raise the temperature over time, if a frog won't survive because we'll get too hot. But how do you know if you've killed the frog sometimes it's very hard in the big organization? Yeah, it's interesting as well because to me there's a a link there with the way that we as practitioners actually try and figure that out. What I mean by that is... We love to talk about making ourselves redundant. I'm full of you seeing this, so I like coaches and scrum masters. We love to talk about this idea of making ourselves redundant. But I don't know many people that I don't think I know anyone has ever really done it right as in got to the point where they can be a scrumass or an agile coach and then fully say I have achieved. what I need to achieve, this team is now self -managing and I can completely step away and they will never need this help again. Maybe that's because that's a bit of a silly thing expect to it. maybe that's not realistic but I think the challenge is that we often don't put our money where our mouth is and we don't actually like you say put those measurements in place so that we can actually show that we either have achieved some specific outcome and then even if we're not going to reach some utopia where everything's perfect. We can at least say we've achieved a particular goal that we were looking for on that time horizon and now it's a new discussion as to whether there's a new goal for the next time horizon. because I think a lot of practitioners, unfortunately, and again, this is not to criticize the individual practitioners, but they're in a scenario where they're not going to be treated favorably by the higher ups in the organization if if they're things not treated favorably by the higher ups in the don't go in the way they should go. And oftentimes the impediments to things going where they should go is in fact the same leadership team that will blame and coaches and leaders elsewhere for those problems. And so it is a very difficult, sticky, capture -edged situation. But ultimately, I think the only way we as practitioners kind of raised the bar on that is by getting those measurements in place and making it absolutely clear that we wanted to do this thing and either did or did not have this outcome and particularly that we can demonstrate where we think the impediments are if we don't achieve it right and a great example of that is If I go to a CEO and I say, hey, you've appeared in my plan, right? People are saying that the way you act in these meetings or the way you don't attend these meetings is something or other. is a problem that we need to solve. Then if that CEO decides to do nothing about that and just hand waves that away, okay we have to make that visible, right? Like we have to as practitioners, be willing to risk our own perception in the organizational high ups and say, no, that's... If you're not going to take the action with me, if you're not going to help me come to a solution to that problem, then that problem's not going to go away. And you can't place blame for that problem. And yeah, I think that's a very hard thing to do in organizations that are very power oriented. But yeah, we just we have to find ways of making those conversations easier so that it's not confronting so that it's not conflict and so that it's not. going to risk your job if you have to let a person know that the way that they're behaving in an organization is causing problems, which let's be fair is true of all That's of us. like every single one of us is doing something in our day job that's probably causing problems somewhere else. We just should be honest and open and make that visible. But that's maybe that's part of the problem. Is it many times that people don't feel comfortable measuring their success in a kind of agile skirmass sort of product coaching type role because they feel that they have to solve the problems that they see rather than the problems as that other they see rather than the problems that they see. people see and no professional coach would ever say, here I see what you're doing, here is your problem. the how you want to fix it. Like, it is the most close you're going to get to that is some level of co -creation of a series of of intervention and saying, let's look at what it is, here's what I have observed, what I've observed and actually that triangulation between it, come up with something which is achievable. Because maybe that's part of the reason why people don't like measuring their performance or they're away from measuring the performance or something like that. because it's very exposing doesn't often end up well. Yeah, and to be fair, the example I pulled there was a drag to go for simplification of something that would probably not exist in that way. But I think the bit that I'm getting at is that we need to be willing to share those observations. Without fear of people taking personally what we have observed, if we try to, as long as we present those in a reasonable way, but also by being mindful of the way that those observations will be interpreted by people trying to make them, them more comfortable. not conflict based and that kind of thing. And for me, that's where again, it comes back to this idea of hypotheses, right? It's not about saying, hey, you're doing this thing and it's wrong. It's about saying, hey, there is a relationship between this thing over here that someone is doing and this thing over here that someone else believes is impacting them, right? A great example of This this is is that, right? if the product owner never attends sprint planning and the developers are saying we're unable to appropriately plan our work because we don't have the product owner. We can do all the coaching, framing stuff that we want, but that's a fairly direct link that we know from experience. Those two things are probably related and we should just make that clear and say Hey, now, how we solve that problem, like, if I, and I've been in that situation, right, my first thing would be going to the product owner and saying you want to say. Hey, the team's struggling with this. What can I do to help you to free up time so that you can attend planning or what's the problem that's prevented you from planning? That's the way I would approach there. that. And someone who's a much more coachy coach to not have a better word for it might even go in just with some open framing questions to help them see the problem right you might take it in a less much direct way. But ultimately there are certain things that we just know right. These things are connected, we need to talk about them and I think the reason those things are hard to talk about is because They are tied up with all these power relationships, but if we just turn it into iPodsus and say, look, we have observed But the team A is complaining about this. They believe it's because this person is absent. This person is absent. And especially if you're an organization that claims to be using scrum, right? This is one of the things I use in dysfunction mapping. if we say that we're going to use some framework and then we're going to just deliberately ignore the rules of it, then we should accept that we're just being idiots really, whether or not scrum is the right answer or safe is the right answer, but either use it or don't, right, until you've actually done it and followed the rules and now you're adjusting. And again, it's easier to make that point. It's not about, I'm saying you have to be present this meeting. It says, we said that we're using scrum. Why is it that we're now just ignoring this rule? So let's try... Following that we'll see if it solves this problem. And if not, cool, that's my fault. Right. I don't know what I'm talking about. That's fine. But more often than not, these patterns that we see. 80 % of the time they do relate in the way that we think they do as coaches because it's happened thousands upon thousands of times in different organizations so we just want to be clear better. about it. One of those coaching smells. Yeah, to have Michael, we are running towards end of our time. We haven't really had your particular efforts to speak about productivity, but maybe we will get back. And I'm going to be talking about it more and more as we go through these episodes anyway, so we'll get you back and I'm contemplating maybe a bit of a a round table conversation, a few people could be nice to get a few people involved. But we said we were going to go at measuring success and we have I've to spend spoken about measurement success, but I wonder if you fancy a challenge. If everyone is listening or watching this was a challenge which I haven't articulated to Mike before. Is I'm wondering if we play a little game of measurement tennis? Okay, so we'll have a timer for two minutes. Let's do a minute and a half. two minutes I was just trying to scare you for some reason. For a minute and a half and then what we'll do is we'll pay tennis and one of us will start first and we'll say something that... Perhaps a coach, a Scott Master Adryal coach or kind of product coach could measure to help indicate their effectiveness in some way and of course they're all context specific and we're not saying these are things which are universally applied but just things that maybe we could measure measure. and we'll just see how many we can get through in 90 seconds are you up for it? I could try. I feel like you're really put me on the spot with this one but I'll do my best. I'll go first to give you an idea. And we'll just see where we get to. And don't worry about explaining them. We'll just let them hang and then we'll let the internet so I'll answer the questions. Okay, you ready? I would measure average impediment resolution time. Nice. Yeah, that's a good one. So I'm a big fan of that. Back of the back of aging? I would look to measure work in progress across the life of an item being refined. And when it goes in the backlog to what it's been doing for team. Yeah. I suppose the easy one then there would just be cycle time Right. right. Yeah. How about percentage of product backlog items used by the user in the Sprint Review? Nice, yeah that's a good one. So I'm going to be kind of flow efficiency as well, I think that's a good one. That's it if I'm a coach or scrambler, how many teams more am I supporting from when I started? Oh that's an interesting one. I wonder which direction is good. Yeah, I think that makes me think actually that there's something there about how many people in the organization actually are willing to give you positive feedback, right? Like how many actual individuals have said that you've made their life easier? Yeah. Nice. Like a count of people who are willing to say anything about you maybe and then looking at how many people have said positive things too. Yeah, it feels a little bit like it's just a reddit thumbs up. Yeah, but still. But why not? It's better than nothing. Yes, we're not measuring to say that we are. We have been successful, but what can we do to increase? confidence that we have the hadn't effect. And I think that there and this would be the last thing I say in wrap this episode up, but you're people are always going to measure your performance in whatever role you in are in and to into a situation in any role and believe that you can just do whatever you want not worry about your performance or believe it. No one's actually measuring performance and let's naive. Somebody somewhere whether they're important to us and our career or not will be measuring our performance performance. and having an appreciation of who is measuring our performance that can actually affect our career and what we're doing positively or negatively. That's a really important thing to try and understand. If you can understand that, then you can do something about it, just avoiding and it. pretending like it doesn't, that isn't a thing. Winging it isn't something that works for all of us. Yeah, and just to add a little one -liner of mine that I like related to that, which is... Change what you measure and measure what you change. So if you don't like what's being measured currently based on your performance, make a case of changing it, give them something better, right? And then make sure you're constantly measuring how that changes over time. Lovely. Love it. I wonder if that will be the title of this episode. Thank you so much for this time. We've chewed through the time. So thank you for taking a couple of hours out of your life. to spend some time exploring these topics. It's been a bit of delight and nice to see you again after you I mean met on my train from the back of the room course. I feel like I'm gonna turn it in. Yeah, I appreciate it. It's been a good chat and yeah, ever since that course, I am a big fan of yours. I love the work that you do. So yeah, always happy. to catch up. Ah lovely mate we'll get you back and I said we need to think of people to form a little round table conversation or something juicy so mate we'll get you back.