Agile Dysfunction Mastery (With Michael Lloyd)

Here we are with Michael Lloyd. Michael is somebody that I have known for a year via LinkedIn initially. And you came on my Truth in the Back of the Room course. It was awesome to get to meet you. And I really love. The stuff that you're putting out and have put out historically on LinkedIn in particular. I think it's different. I think it is thought provoking without being cheesy, contrived or an asshole, which I think is quite unique because some thought provokers out there are dicks at times and you're not one of them. But I guess a lot of people listening perhaps haven't heard of you or seen anything that you've been putting out on LinkedIn, such as dysfunction mapping or some of your opinions on there. So Michael, would you mind giving our listeners a little introduction to yourself? Sure thing. Thanks, Ben. So yeah, I appreciate that not a dick tagline might actually be something that I stick with because that does tend to be a bit of a guiding principle. But yeah, I'm basically, I'm an agile coach and scrum master, right? That's what I've been doing for the majority of the last eight years when I first found the agile movement. I spent a lot of time just focusing on getting better at understanding Agile tools and frameworks, figuring out how to help teams get better. But much more recently, it's turned into, I think a realization for me that the Agile industry is going off the path that I think it should be on. And it's in a bit of a precarious position and just trying to do anything I can to maybe shift the conversation in a direction back towards the right things. And that's where some of obviously the LinkedIn content comes from. My general approach is just, I try to be as honest as I possibly can, while also, like I say, not being a dick about it, right? So try to actually position things in a way that is likely to land with people, maybe likely to influence them, even if sometimes I feel like I'm saying things that are not popular. It's just about trying to open that conversation, get people talking about stuff, because sometimes it's just platitudes and soundbites, and we need to actually be talking about the big hairy problems in the industry. So it's a big statement. Which one? Around the state of the Agile industry, this podcast, when it originally was formed, was all really focusing on letting people know about large scale scrum and how useful it can be. But since I started the podcast, I've moved on, the world's moved on, Ness hasn't moved on and that's fine. That's a kind of statement of fact. And the podcast has evolved into much more broader conversations around product and agility. And I'm in a fortunate position where I, I suppose, I'm tentatively straddling both what people would maybe call the product world and then the, the agile world. And I suppose this is how I feel, but it's also, I think some of the feedback I get from people is I do, I'm trying to have a foot in each camp and I do find in the product world, things feel very different in respect to people's approach to learning and the people that are espousing certain things. I've done it and the agile world. seems to be more interested in having professional trainers. Then competent practitioner experts who are helping people grow their skills. I suppose I'm saying that obviously with an eye, with one eye thinking. Is this what you think as well? Partly, yeah. I guess the, the bit that immediately is just interesting to me, right? Is that why are they even two separate things? Like why is there this idea and, and you are right. Like I, I immediately are recognize the thing that you're describing, right? You've got the agile movement, which is this thing that's been around for 20 years. And the product movement has always existed as well, even before the manifesto. But this modern incarnation of the product movement, as you're describing it, is this thing that I perceive as having split off from the agile movement because of some of the problems with it. And why should those things be separate, right? Product is such an important, inherent part of agile. And the fact that so many really bright people have broken off to try to have a conversation away from that, I guess, big A Agile word. I think that maybe says a little bit about the problem that I perceive. And I think maybe you would as well. I guess I'm, I'm curious for you is what do you think is the difference between the Agile movement and the product movement? What separates those two things? I don't know. I obviously don't know for sure. I can go with my gut feelings, some of the things I've observed and some of the things I've been talking to organizations about here and there. Which is, Agile came from a lot of programmers, generally, and, um, was made popular by programmers. And it was called the Agile Software, Agile Manifesto for Software Development. So basically Agile Manifesto for Programmers. And it was really, it came from that world. And what was interesting is when you listen to The Land Scrum Forgot by Bob Martin and he talks about how The scrum master courses became so amazingly popular that the space that he was loaning Ken Schwaber to do the training just wasn't big enough. And he was wondering how come everyone's getting these set for a scrum master courses and they having to get a bigger space when our XP bootcamps aren't filling up and we can't, we're not having to expand and yeah, same way Agile is a, it's a software thing. So how come all these software professionals are going onto the scrum master courses and it turned out it wasn't software developers that were getting the scrum master courses. It was project managers. And at that point, the agile world bifurcated and I think that some of it is because it was, it did come from a programming background. I think it was embraced early as a method of managing projects and. It never really got deep enough into having a successful world. What creating, discovering, refining, managing, delivering a successful product was really all about, because other stuff had to be added to it. And I think the product world, so much great information, so many great people. I think that barriers to entry were dropped, particularly around COVID. I think technology moved forward and have great tools like Pendo where actually like validating your hypotheses can happen by actually understanding what the users are doing. Rather than on mass, rather than just a few kind of small kind of lab sessions where you're interviewing the user as you go. I think that's really tapped it all. And I think that why would as a product, if you're a product person who wants to make a living through talking about product, why would you try and hook into agile? When that isn't part of what you've done, you're a product person. So you just treat it like a product and you do your own thing. And I think that the, yeah, I think that's why it's different. Although I agree with you. I think you have a term which I. I'm very keen on is a product agility. I think that we need nimble, agile products. And I think these things work really well together, but I don't think that is selling as well as giving nice blog posts, explaining what we can wedge in between. Yeah, and that for me, so that's, I think that's exactly where the, like the source of pain is drawing me to like the issue with our industry as a whole is they say it's which things are selling well, right? Which, and it's, I think you, you said a comment earlier as well about we're chasing the certifications that we can sell, which we're chasing the, the ideas that people like to talk about. We're not thinking about this cohesive whole of what's this stuff that we're even doing, right? We're the value we're delivering for our customers. And it feels weird that the agile movement, which I totally agree, you're right. It definitely, it began as a software development approach, right? Philosophy. Um, but I think that the reason it was successful was because it defined itself as being broader than that, right? It realized that software development was about more than just writing code. It was about, , responding to change and, , delivering value. But the problem with the industry that sprung up around it since then is that it hasn't really properly taken on board all of the stuff that we've learned through doing over that next 20 years since the manifesto was written. And like you say, it's like , the product, the product game is like a, a good analogy for that because you shouldn't need to have. Individual specialists in how to organize teams to deliver value and then another independent team or group of experts on how do you even define what value is or you deliver the right thing to customers. I mean, that should be one big cohesive thing. And I think both of those groups know that, but the very large and powerful and influential industry around particularly the agile movement, I think this is nowhere near the same problem in that product sphere, but that has the ability to drive. The conversation and change the things that people prioritize, because there's huge amounts of money to be made from selling certifications and selling training from deliberately making your process or your approach more complex so that someone has to pay an expert to understand it that really just goes against everything we've learned. But again, it's you're fighting these uphill battles against just powerful structures that essentially monopolized. The learning aspect of our industry. And I think that's the part that the product side of things has managed to break away from a lot more, or at least just not get engulfed in it to the same degree as the agile movement has. But as of yet, there is nothing that's monopolizing things. And it's quite in the same way as they're in the product world. Yeah, I think that's a very, it's a astute observation. I mean, when you look at the current state of things at the moment as things currently stand, and there's been lots of, I say lots, not lots, but there's a couple of are CECs who are saying that certified enterprise coaches of the Scrum Alliance who are saying that they're not going to bother renewing, they're not Scrum Alliance anymore because they've taken away. The ability for those CECs and I believe CTCs team coaches to deliver certain training pathways. Now, ironically, I don't know how much you. Have seen what's going on, but CTCs and CECs, so Certified Team Coaches and Certified Enterprise Coaches for the Scrum Alliance, historically were allowed to run cohort based kind of coaching programs to take people on a pathway to advance Scrum Master. So multi month process, giving them some education, some support, coaching them along the way and watching them improve and get better. And they're not allowed to do that come next year. What was the, what's the stated justification for that? Why are they saying they're taking that away? I've not seen an official statement. All I, and I suppose I have spoken to some people, and I wouldn't want to say anything for fear of incriminating anyone for saying stuff that they maybe shared with me in confidence. I don't know. I know, but what I can say, and as you say on your LinkedIn profile, these opinions are your own. This opinion is my own, I can't help but feel that whether it's the intended consequence or an unintended consequence by devaluing or removing the incentive to become a CEC and CTC, it just pushes people more towards becoming a certified scrum trainer, which means more courses, which means more. Revenue in the end state. I don't know. I really, I don't know. But the 1 thing is true is, I think that those people who used to do it, who were making a living from it, who now can no longer make a living for it will be looking for somewhere else to turn and I don't really understand the rationale for that. I mean, any ideas I had about coming a CEC, I parked a little while ago because I didn't see value in it as it stood. Yeah, it's, I think this is part of the, I guess the rot that exists in our industry that a lot of people don't want to talk about is regardless of how passionate and knowledgeable and just like careful individual like trainers and people who run certification programs are and I know a lot of these people and I, I haven't met a single like. Scrum. org trainer, for example, that I don't deeply respect. I think they're all fantastic at their jobs, but as soon as you like form a collective and an organization whose revenue is based upon selling certifications, the only thing that organization really is going to do is incentivize selling more certifications, right? That's just the way the incentive structures work. And it doesn't really matter how thoughtful the individual. And a practitioner is if the entire industry essentially is building up this perception of you need this particular certification or this particular framework in order to be hireable and to demonstrate that you do some particular thing and particularly then tying the business model to how many people you can get selling those certifications on your behalf. Right. As I think you and I both joked in the past, it's very pyramid scheme ish. And again, that's overly harsh sometimes because it's not a deliberate intent of the individuals doing it, but Yeah, when you create these kinds of structures where there's just so much money to be made on these certifications and then the organizations that have monopolized the industry off the back of that just has so much power because let's face it, right, like I, one of the things we might talk about a bit more later is some of the stuff that I'm doing on the side to try and build some alternative training pathways for people. Um, but like, how am I meant to compete with scrum. org, right? Why should I even think that I could possibly be yelling to the abyss in the direction of scrum. org and hope to be heard? But there's, there is, I think, a growing contingent of people, and there are people I'd love to talk about a bit later, maybe, that I think are doing some really good work and shining a light on some of the anti patterns that we've baked into this training and certification model. And I think that as that realization starts to dawn on people, that things will start to change. And I don't necessarily know what's going to replace it, but I think that, like you say, this model where an organization just wants to sell loads of two day workshops, and perhaps starts reorganizing things so that... What people want is less important than how many certifications they can sell. Hopefully that starts to go away because people can see through it. And again, that's not to undermine the value of the training or the value of the organizations themselves. It's just that model that just, in my opinion, has outlived its usefulness. Like we are way beyond the point where too many people are certified in basic level. Two day workshops of something X, right? Like it doesn't matter what workshop pick a framework and there are probably too many people that have that certification to the degree it's college degrees, right? Like they say in America that they've become useless now because everyone has one. So it just becomes the new high school degree. That's what the PSM one is now, right? PSM one doesn't tell you anything about a person's knowledge of Scrum. It's just a thing. It's a benchmark. It's a step you have to take if you want to be considered hireable as a scrum master. And again, I've taught. The PSM one equivalent content. I've certified people in it. I know lots of people who are PSTs and trainers aligned to scrub the org, respect them deeply, but that doesn't change the reality. That's not enough to help someone demonstrate that they are a master of scrum and we, as an industry are not doing a very good job of actually putting that structure in place to demonstrate that level of mastery and help people to get there. That's it. And I wonder if that. That horse has bolted. I don't think that there's any coming back from it quickly. And we've, we have set a precedent that people have a knowledge gap field. That's what training does. Training fills a knowledge gap. It's the ongoing support and the coaching and the practical application that then makes people skillful, knowledgeable practitioners with a true understanding of the concepts or topics or tools or techniques. Certifications is just filling a very small knowledge gap. And I think this is what the product world are being and have been quite savvy, which is if we deliver some self paced learning, which is two to four hours long, and it's engaging, guess what? People will leave remembering it, people will have it there to refer back to, and people will recommend it to their friends, and it will probably do a good job. Like, I don't think that a lot of the stuff which is taught In your standard kind of scrum master course around the events and the roles, people could watch a pretty engaging video and learn that you don't need to attend a two day course to learn a lot of those things. And I think where I think if you take a product view of it and say, how are we going to make a product, which is scalable. Which kind of gets them, it solves a problem. So it's a value to people. I think the route that some people in the product world are taking, or if you look at the mind of product used to have a subscription service as well. So you've got articles. Although, you know, I think the articles were of varying quality, but it was a good shout. I think that does probably more for the average practitioner and going to good conferences and say, going on the, all of these two day courses. I mean, I did some research. I'll bring up my screen here that when I looked, this is a month or so ago, there was about 284 certified scrum trainers in the world, and there were 364 PSTs. There were, and I did then have a look at how many safe SPCs there were. Yeah. If I was to tell you that the, there was one organization, one organization alone that had 485 SPCs. Wow. Yeah. But I mean, and this is part of the problem, right? Sorry, I didn't mean to off, but it's the, so as we might get into, I'm not necessarily as critical of safe as a lot of practitioners like me are, although I certainly. Have my criticisms. The biggest one of those is that safe makes it far too easy to achieve that kind of SPC high level certification and the benchmark of quality that they hold is very low for their practitioners. I think scrum. org is on the better end of that spectrum. They do a much. Better job of holding a high bar, but the PSM one level, which is the entry level is very low bar, but the right level is for an entry level, but I think that the bit for me, and I'm doing some work on the side to actually try and make progress on this is. If that entry level thing, the, the, the base level of knowledge that you need just to be successful in a role, um, is that low bar, right? If we're not saying that you need to be up here and you need to be multi year level practitioner to be a scrum master, but in fact a scrum master is someone that just needs to have basic knowledge of scrum and then these other assorted, maybe soft skills, which again, we could argue whether or not that is true of a scrum master. Given where the PSM 1 sits, the way the industry is moving, I think that it's mostly being agreed upon that a Scrum Master position can be an entry level position. I would maybe disagree with that. But if that's true, then it shouldn't cost 1, 000 to, to get the, just the basic foot in the door certification to prove that you've got that right. Those, there's a mismatch between those two ideas. Is, and I say safe, kind of does this problem wrong on the other end, they charge you even more. It's not necessarily any harder. And then they allow you to train people without any confirmation that you actually really know what you're doing. No, no experience necessarily in anything you're saying. Yeah, exactly. And it's, so the thing for me is a trick. Like visualizing what a good, let's just use Scrum as an example, right? I'm not married to that framework, but yes, the most popular, if you were going to create something that was going to help people to get into a Scrum master or Scrum type position, as well as move down that path of mastery. There's two elements. There's like you would sort of alluding to earlier, there's the cohort style programs, right? You need some longer term pathway where you incrementally test and verify your knowledge and learn. But you also need that foot in the doorstep that should be self learned. It should be easy and in my opinion should be free, right? So that's what I'm trying to create at the moment with the help of some other adult practitioners is what if that PSM one equivalent was something you could get for free, right? You do, you learn the stuff on your own, you take the exam, imagine the exam was harder than the one that currently exists for PSM one, not by a massive amount, but enough to demonstrate that it at least is as good, if not better than a PSM one certification. And imagine that first step was entirely free of charge. And then the only thing that you have to pay for is the time of the, the high level trainers, the really experienced practitioners to guide you through the, whichever parts of the program that you think are the skills that you need to develop. And you can, you know, do this in a modular way and get badges or certifications for the bits that are relevant, but it's a fully modular process that you can just pay into as is relevant to you. And that you could potentially audit as well. So you maybe you could go through and get that content without paying for it. You just wouldn't get certification or the badge at the end. If that was the model that our industry was built on, my sort of suspicion is that we would have a much higher level of a practitioner community, how to create something like that and break it in against that wave of things like Scrum Alliance and Scrum. org and Scaled Agile is just a, such an uphill battle. Yeah. But what is success for that? Because I don't think that everybody really. Cares enough, if I'm honest with you, it's like that you care, I care, like lots of us care, but for many people out there, it's, yeah, it's just a job and it's not like accountancy where you are with a or CIMA certified registered accountants and you working alongside them. You're not going to get away from just winging it on the profit and loss or your reporting of that VA to your KB of HMRC. You're not going to get away with, no one's going to get away with winging it or cocking it up because you are all at a certain level, there are repercussions for getting it wrong. And you know what, you're just not going to get away of it because you're around good people. Look at the professional coaching world. In the professional coaching world, you have to go to supervision. If you want to remain part of the ICF, you have to be mentored. If you want to be part of the ICF, that's just the way it goes. There are lots of brilliant coaches out there who have never, ever been a member of the ICF and they have a good living, but most professional coaches, you look at the ICF and you're like, that's the gold standard. And I bet that started at the beginning and it grew from there. We've never had a body that cared as much. about the people that are on the receiving end of this, of the knowledge, which is being espoused to people. No one's really cared enough historically to do it. And I just wonder, I think that what you're saying makes sense. I would join you on that crusade, but I wonder how much impact it would really have. Yeah, and that's the problem, right? Like with all these things is I don't know either, right? I've just got this vision of something that could be better and I want to test it and see what happens and I say I'm working with some other Fantastic agile practitioners to bring this to life. Hopefully we're only on the early stages of it But I think you're right, there is, there's an element here as well as, it's what I often call that bar that our practitioner community has to hold, that maybe it's actually something more formal than that is, we need to have some kind, there needs to be repercussions for people who are not competent, and that probably sounds really harsh, but I think our industry needs a bit of that, and again, I do think the majority of people have the best intentions, and they try to get good information, but In an organization that is highly dysfunctional, as most are, let's be honest, if you're not a person that spends a lot of time, like you say, talking to other professionals who are doing this and have that expertise, it is very hard not to have your ideas of what good practice looks like soured by the things that you're doing on a day to day basis in a highly dysfunctional organization. And so my experience of this, and again, I can only speak to mine, but I've hired a lot of Scrum Masters and Agile coaches over the years in various places and companies. I usually find particularly the scrum master, I think it's an interesting one because it's quite a well defined role, right? It's not something that necessarily varies that much Uh because scrum is something that's central in the scrum guide and when I hire scrum masters I would say that nine out of ten of those that I interview And that's not even excluding the ones even that don't get to the interview stage But nine out of ten of the ones that I interview I would describe as being not competent scrum practitioners And I don't mean that in a harsh way. I just mean They don't know scrum. And as, as you and I've talked about in the past, like I don't necessarily think that scrum is the be all and end all of being a good agile practitioner, being a good product person, being a good delivery person, any of those things, I think actually it's entirely possible to just throw scrum to the side and still be really good at helping teams and delivering value. But if you're going to be going into a scrum master position and you have not even read and understood the scrum guide and every other sentence is just a very clear misunderstanding of something in the scrum guide, that to me is a concern. And it makes me wonder what else it is that you have pulled in from the dysfunctional organization that you've come from and don't realize is a problem. And I think that's what I mean about the higher bar. Sorry. Yeah, no, no, no, don't apologize, man. No, because you're right. You are right. But then they've been in an organization where they were able to get that role and execute that role to an extent where that organization said, that's, that's adequate. They will go and go get a job in another organization where they'll get a job, but they'll get a job. And this is what we are not saying is these are bad, unskilled people. We're just saying that if you're aiming for a certain level of scrum as an example here, it could be anything, right? An understanding of walnut trees. You're hiring a bar of culturalists, and then they turn up and they're like, Oh no! So what I'll do is, when I climb that tree, I'll just keep, I'll get my, I'll get my shears, and I'll just, I'll, to keep them open, I'll just put the rope in between the open blades. So it keeps them open, you can be like, and when you fall, what's going to happen? Oh, but it might just snip through it, but that's fine because it's on grass. Yeah, I'll be like, okay, not hired. You haven't quite reached the bar for my walnut tree or a culture company. Right. But they will go somewhere else and undoubtedly they'll get another job somewhere and then they'll, they'll break their legs or whatever. Right. But that's just that they're saying there's a certain bar we want to go for here. But if you are going to get a job as a product manager, all right, sack off product ownership for a moment, cause that's just a bag of snakes. Right. And then we're just going to end up going tigers up a notch. You're going to get a job as a product manager. You're going to be interviewed by people that understand product. And you're going to be interviewed, my guess is by people who aren't going to. And yeah, so you've come from a product job and you're going to be interviewed by people that understand product. If you're no good at it and you've got no experience, you're not going to be able to get a job in that realm. You're just not, right? You're just not. But chances are that you will be very skilled and experienced and you will be able to have the conversation and you will get a job in a product company. But it isn't something you can just go on a two day course, call yourself in and try and get a job. And I think this is like the, when I think of product and yeah, this is a broad sweeping statement, but I think of situations where there's less room to hide because you're not talking about coaching a team or something, which may be deemed as one of the more kind of. Yeah, softer, fluffier side, and I say that with absolute respect, right? Cause that's what I spend a lot of my time doing. And that's what the fluffiest side, you're talking about, can we make money from this thing and what techniques are we going to use to understand by creating good hypotheses? And can I convince my senior stakeholders that actually this is worth giving me a credit line so we can invest some money in this and see how it goes. And I have to see a return. Like there's nowhere to hide in that. But I think with scum mastery and anything in the kind of, most of the stuff in the hedgehog world, there's so many little nooks and crannies to hide or cower. Or just to let stuff get glossed over because there's so many little nooks and crannies and a vast array of different interpretations of the roles that people are being hired into. And there's two big reasons for that, in my opinion. You can look at this in two directions, right? And so I agree with everything you've said. And it's when you look at it from that product perspective is, I can't think of a more eloquent way to say this, but the product industry is not up its own ass in the same way that the agile industry is right. Which is to say, no one perceives the product, the study of product or the study of product delivery, whatever you want to call it as being an end in and of itself, right? Everyone understands that it's for a purpose, it's for a reason, and that's to satisfy customers, right? It's to deliver valuable products. Whereas the agile movement, at least in part, and I would argue probably a majority, I would say maybe 60 percent of practitioners to pull the number out of thin air, probably fall into this camp, which is to say that agility is the end goal. They see this idea of an agile organization and an agile utopia as being something that they are there to create because they have this vision for the future that they believe will make things better. But they're not tying that to the actual outcome. And, and I think that the. Conversation that I have quite frequently with other agile practitioners. And again, many of whom I respect deeply will say things like what an agile coach does cannot be measured, right? We fundamentally do something that is not measurable because it's like, say it's this soft stuff, right? It's about making people enjoy their work or satisfying customers more, but not from the sense that you could, um, measure any of those things just in this high level kind of fluffy way. And yeah, like the problem for me is that you cannot. Expect to be taken seriously really by anyone who is outside that bubble when you make the case that you're this, this person that you're expecting to get paid to do a job, right? Not just in here doing this out of the goodness of your heart. You're expecting someone to spend money and time and not only that, take a huge risk often on giving you some level of influence or authority in some organization. That could potentially have a very expensive knock on effects if you are an ineffective or not competent person to then try to say, I'm not only going to not be able to prove to you that I've been successful, but there's no, I cannot define what failure looks like to you up front either, right? This is entirely just based on how happy people feel or how, how nice we think. The day is or whatever. And again, I don't think most practitioners put it. I'm deliberately putting that in like the least friendly way, I suppose. But I do think there is this very, very deeply embedded kernel in the practice of agile coaching and all the supporting stuff, which is that as long as people are happy with the work that we do, then we are successful. And I think that's partly true. But, and this is something that, like you say, you cannot hide from in the product world and you shouldn't be able to hide from the agile world, in my opinion, is that you also need to be able to demonstrate actual results. And that means more value delivery or teams that can deliver more frequently or integrate with fewer or any myriad of things. And I'm not implying there is one single catch all metric that will solve all these problems for you. But again, if you're not measuring stuff, if you're not measuring something. Then, like, why should anyone listen to you? And that, I think, is why it's so easy to hide, is because, as a practice, even, say, the... Even if it's not the majority, let's say it's a minority of practitioners that buy into this worldview I'm describing of not measuring and not demonstrating. I still think that the vast majority of practitioners in the Agile world accept that worldview and don't push back against it. That much I think is fair to say. And if we don't do that, we're just allowing that bar of practice to lower and devalue what we do, right? Which just leads us to, I think, where we are now, which is facing possibly quite a big existential challenge to the Agile movement. That's no, this is what, so a couple of things, one thing which like hit me square in the face and I'll come to it in a second. I want to detour around the fact that coaching, when I think of coaching, I think of it all coming from something up here, which is professional coaching and all the work that was done 20 years ago to prove individual one on one coaching was beneficial. And it was proven, not proven, they weren't able to disprove. There was evidence which suggested that one on one coaching helped people improve their performance. It helped them attain their goals and I don't think that many people will turn around and say that a good coach doesn't give them a significant impact, beneficial impact on their life, which is in some way measurable by them saying, look, I've got the job, or I mean, there was somebody that I coached once and I don't do much one on one professional coaching anymore. But somebody contacted me and said, do you do career coaching? I'm like, well, no, but tell me what is the problem you're facing? And they were going for a job. And so we had a couple of coaching conversations and she got this job. It was a brilliant job, more senior, looking after all the sustainability for one of the UK's largest building companies. It's a phenomenal job. She's a phenomenal person. So was, yeah, how do I measure my performance as an individual coach? That person got a shit hot job and they're really happy and it helped their career. Brilliant. Right. I'm equivocal. When I think of Paul Barber or someone else I will name drop, a lady called Alice, they are. Paul's a brilliant team coach. He goes in, he works with a lady called Lucy. They help increase team performance. They get more work. That's objectively measurable because the teams will say you've increased her performance. Alice is someone that she might be surprised if she ever listens to this. I'm talking about her, but I think she's quite, quite a force to be reckoned with. She's really good at her job. She coaches teams get better. She gets invited to go to talks. Objectively, you can measure her performance. I think that as our coaches. We should be taking some of that and saying, are we objectively increasing team's performance? Yes or no? And I think you can already measure that, but I think that many of us don't because we're not hard into a role where that's believe that's what we're supposed to be doing because there's, to convince people that agile is the thing we should be doing, rather than focusing with helping teams improve their performance. And I think that's a big problem. I think we can measure it. I just don't think that we, yeah. Sorry, the way you phrase that then it really does bring the point home to me because I think this is where again we as a practice as a community have failed to, I guess, stand by what I believe our principles should be right, which is that we are here to improve value. We're here to make people objectively better at. Doing whatever the job is that they're hired to do. And cause you mentioned that sometimes we're not hired into a place that understands or empowers us to do the thing that we actually should be doing as agile coaches. To me, that's a terrible excuse. And I know it's not really the one you're saying or that you would use. But the idea of an agile coach saying, Oh, I wasn't empowered to do the thing I was hired for, but that is the thing that you were hired for is to help management and leadership and other people understand the importance of empowering people to do the valuable things. So if you can't even get to the point of unlocking your own potential in that organization, how on earth are we meant to believe that you're qualified to unlock the potential of all of those other people around you? And again, I know that probably comes across super, super critical, but I don't mean it as a, as a way to, um, Discount the individual practitioners. What I'm, what I'm saying here is that we have to take that on, right? That's our responsibility is to say, I'm in this situation surrounded by these people, how do I make it better? And I am by no means like the best coach in the world. I am not perfect. And I have made mistakes, but with one exception. Every organizational team that I have ever been a part of has been so obviously and measurably better by the time that I've left that no one has questioned the values that I've delivered. And the one exception of that was a place where literally two weeks in, I realized this is just completely beyond saving. All I can do is say, sorry, you're on your own and leave. Right. And so those places do exist, but that even that, like that was, I know. So that organization that I started with, there were other coaches that started around about the same time I did. And a lot of them, they just said, Oh, I'll just stay on for the next year and collect the paycheck. And it's not going to improve. It's like, that's the sort of integrity that we have to be not, or the integrity gap that shouldn't exist in our industry, right? Like we have to be able to say, here's what we're here for. Here's what we're going to do. Regardless of the exact direction of the exact place that we end up, we need to be able to show that we have made things better in some way. And if we can't do that, then we should be leaning on the rest of our practitioner community and figuring out how. And that's the part I think that's missing, is we're all so insular. The only training and support we offer is these, here's how to do SAFER, here's how to do Scrum. It's not, how do you navigate your way through these problems? How do you come up with a concrete plan for change? How do you actually get people on board for making change? And there's just so little and it's not that there's none of that out there, but it's Not common enough and it's not pushed hard enough by those of us who've learned these patterns as a requirement, right? As you must know this stuff, not just this framework or this certification, you must know how do I actually make change? And that's what we need to just solve, I think. Doesn't sell though. Doesn't sell, man. And I think that people, like, if it don't sell, then it's only as altruistic as certain organizations are going to get. I think that's part of it. I mean, one thing that I've read, I've thought of recently. Was that you look at your framework, played a blinder, absolute blinder. I'm even wearing the rugby top today. So when I was invited to the safe leadership retreat five years ago, I never got invited back. I was quite upset about that, but yeah, I had some great lunches. I met some nice people. Yeah. I did. Yeah. One, one person who really, who's no longer with us, a bloke called Martin Burns, lovely bloke, really great loss that he passed away a couple of years ago, that as an aside, they played a blinder because they gave a framework, a harness, something which said. Learn these things in these contexts to do well, and the thing is scrum stops too early. It starts late and ends early. So you've got a very little frame in which to people to learn. Honestly, once you learn the key roles, why bother with the rest? Like scrum. org doing some interesting stuff, where they're saying like, learn about scrum and UX. I think it's, I think scrum. org got the right idea. I think they're offering some of the right syllabuses. I think they are pushing it a little bit, which, which needs to happen. I find it interesting that with scrum. org, you can pay to do the PSN one. You don't have to go on a course, unlike Scrum Alliance. And yet in org, they have more trainers. So there's a weird, yeah, but maybe the course is lower for scrum. org trainers, but there's an interesting thing there, but yet they can only learn for instance within the frame of scrum. I see Agile, I've got this amazing roadmap with brilliant collections of learning outcomes that have been written by some of the best and the brightest that we've got. And nowhere near as popular as Scrum Master courses, because there's no frame to hold all that together. And I think there's something about us as humans, that when I think back to my childhood, right, and this is one for the people who are watching this on YouTube, I liked a sticker album. Do you want to see one of my favorite sticker albums? Go on. Uh, My Little Pony sticker album. My Little Pony. I never completed it. Makes me sad. Gaps in My Little Pony sticker album, which I'll never fill. I think that this is a good metaphor for SAFE. It's a sticker album. And it allows organisations to fill their book with all the stickers they need to complete the whole story. The Scrum sticker book is much, much smaller, with far fewer stickers. And there's some extra little things. Oh, you can buy a little add on at the back and you can... I've completed the album, mate. I'm gonna move on to the next thing now. Why do I need to do it again? I think that people need a frame in which to learn about the extra stuff to make it real. Because, because we love collecting shit. Yeah, interestingly, though, I think that's a good metaphor for say, for another reason is that you're probably going to get a message from someone after this, that's got a rare, unopened My Little Pony sticker thing that they're willing to sell you to help you complete your collection. And that's it, right? There's always someone that's willing to sell you the thing that you think you need. But I think, so the bit that's interesting for me, and again, so I, full disclosure, right, so I've... I'm PSM3 with scrum. org. I'm SPC6 with SAFE. I've trained and certified others in both of these frameworks. I have friends and enemies on both sides of both of these spectrums because I'm just honest and people don't tend to like that. That's harsh. People disagree with me and they're allowed to. But the, the thing that's interesting for me is that I look at Scrum and SAFE as being a lot more similar than most people realize. And that they've both fallen. They've both committed the exact same crime. They've both done the exact same thing wrong, just at different ends of the same spectrum, right? And that's Scrum in its attempt to be lightweight, right? In its attempt to, in my opinion, to sell more certifications to more people has made itself too broad and has stripped back too much in pursuit of Allowing more people to think that it's a useful thing for them to learn. And so one of the side projects I'm working on at the moment is rewriting the scrum guide from the perspective of software. Because I believe 90 percent of people who are using it, they are using it in software. We like to pretend that it's not, but that's the reality. And I've been very curious to think, what would the scrum guide look if it stopped trying to be broad and explicitly said, this is what it would look like in a software delivery environment. And so I'm just going through that process. And then safe on the other hand, right? Like it, it's. Very, it's got lots of really cool tools and it uses a lot of really good thinking, some of which it changes in ways that I think are not bad, not as good as the source material, but for the most part, it provides a lot of good guidance, but it also just drowns people in stuff with no framing or context for how to actually connect. These other than to get a certification and to go through a implementation of roadmap that involves certifying a bunch of other people, right? The only reason that I think I know safe as well as I do is because I went through that process, right? I was skeptical of it. I decided I want to actually understand it. So I got my SPC certification. I got the SPC certification was like, wait, is that all that was easy? So then I was like, I'm going to certify a bunch of other people. And so I went through safe for teams and leading safe and lead portfolio management, taught those to other people. Now I feel like I know it. My criticisms of it have very much been peeled back as I've gone through that process, but the thing that remains in safe for me is that as the big positive and the reason that I now, I think, just less critical than the average practitioner is because it does provide actual guidance on stuff that is important that other frameworks and processes just pretends I'd like to pretend it doesn't exist, particularly for large organizations, right? I totally understand the sentiment of don't scale to big, complex organizations if you can get away with not scaling, right? Cool, yes, we can all agree on that. But let's face it, there are hundreds, if not thousands of organizations in this country alone. that are already operating at a scale where that level of complexity is just inbuilt and you can't just peel it all back to individual scrum teams and, and build it all up from there. And when you, when I hear agile coaches and scrum masters and the like, and they're like criticizing, for example, one of the big ones that say it gets a lot of flack for is the way that it handles story points by starting from a single normalized. Starting point for teams and says one, one story point is one day roughly. And they criticize that for good reason. And I understand why, but most agile practitioners don't have an alternative approach for a big organization that needs to know how bloody much it's spending, not just in general, but across various value streams, whether it's operational expenditure or capital expenditure. These are like big, important business problems that frameworks actually really provide any guidance for safe guidance. Isn't the best. But it's guidance, right? Something I think this is where I start to get really frustrated sometimes is you can't criticize the thing unless you both have an alternative, like an actual real usable thing that can take place that you have actually demonstrated success with. And the vast majority of Agile practitioners that I talked to, they have never helped organizations with dozens of teams, I guess that Safe and Scrum, they both fall off. They have the same issue at two ends of the spectrum. Scrum is incredibly broad and it tries to be. A framework or a tool for everyone, but we know realistically that 90 percent of, of people using it are in software or software like delivery environments. And so one of the things that I've been working on, right, is this idea of rewriting the scrum guide from the perspective of software delivery. What, what would it look like if it didn't try to be everything for everyone to try to sell more certifications, but what if it was more concerned with, um, providing real concrete guidance still in a lightweight fashion and without compromising any of the end. Being a bit more concrete to what does it look like in a software environment, and I'm really just doing that as a thought experiment to see what it would look like and see how drastically different that would be from the current scrum guide, because I think this version of it that I'm putting together is probably closer to what it should be to be useful to people. Whereas safe, right? It goes off the other end of the spectrum, which is, there's just so much in there and a lot of it, I think, is really good. Actually, I think there's a lot of stuff that is a bit questionable. Some of it's not as good as the source material they've pulled from, but at least it's giving people real guidance of how to solve some of these more difficult problems, particularly that problem of scale. Right? And I think. Where I start to get a bit frustrated with the conversation around safe is that yes, I can buy into the idea that you have to descale an organization where you can or just not scale up if you can avoid it right. If you can have individual feature teams delivering valuable products end to end, that's awesome. And you should do that. But the reality is there are hundreds or thousands of companies In this country alone that are already massive and incredibly complex, and they need guidance. How do we get from this old fashioned bureaucratic, dare I say, waterfall approach to something that's a bit more incremental, a bit more value led? And SAFE gives people real practical tools for that. And so, yeah, the challenge as a practitioner, the bit that annoys me, as I've learned more and gotten my SAFE certification and taught people. More about it is you have to have real guidance that you can offer that you can demonstrate works right before you can shit all over someone else's idea is in my opinion. And the problem with the way that the conversation happens with safe is people want to shit over something that they don't like, but they don't really have something to replace it with. And the example that I get pulled into a lot is because I think it's one of the more controversial things and safe is this idea of normalized story points. And to be clear, so SAFe doesn't say you should normalize story points across teams all the time. It says that as a start point, when teams are starting out, because you need to find a way to plan across big complex teams, start by making one story point one day. And then from there it'll evolve and grow and it doesn't matter. And I do still have some challenge with that. The reality of it is if you're a big complex organization and you have to worry about Figuring out how to transition your funding and budgeting model into these value stream ideas where, where you've not got the ability to calculate people's man hours and figure out what your operational spend versus your capital spend is. And those are important questions and I would say probably 98 percent of agile practitioners, I know I'm good at just pulling random percentages out, but. What 1 in 20 probably is the degree to which my experiences have led me to practitioners that can actually legitimately say, instead of that, do this thing, and I can show you how I've done it before and why it's been successful. What most people do is just say, oh, just add no estimates, right? And I happen to be a big advocate for the no estimates movement. I'm, I think it is absolutely the future of the agile practice world, but in order to get there, you have to go through a bunch of other things. You can't just take an organization that has millions of dollars that it needs to justify to the tax man as to where it's gone and then say, Oh yeah, it's just no estimates, right? No, that's not helpful. And so say for better or for worse, it gives people concrete stepping actions in the direction of greater agility. And. Again, I'm not without criticism of it as a framework, but I think for those contexts, you need that guidance. And then scrum say, on the other hand, it just, again, I love it. I think it's a perfect tool for the vast majority of software delivery teams, but it doesn't actually provide enough guidance to get people solving problems. And the irony there is that most scrum masters that I talk to. The patterns that they end up falling into in their teams are very similar team to team. And yet we always talk about this. The reason you can't provide concrete guidance is because everything's different and you have to experiment and that's all true. But let's talk about the fact that 90 percent of what we do seems to be about the same across teams and how we actually got to that point. And I think if we did a bit more of that, we'd be in a more successful spot. Yeah. No, I think I, if, if safe was pitched as a library where you could go and just take on what you need, but no one would have an issue with it. But I think it isn't that I think it's the fact there are in my calculations, somewhere around 4, 800 SPCs globally and more than almost 10 times the amount of the SCRUM. org and SCRUM Alliance trainers, like CSTs, PSTs put together. There's a phenomenal amount of people out there who are set to train it. And. It was, it's a great product and it allows people to make money from it. And I think that taking your sensible, pragmatic view of it, absolutely. It's got a whole heap of guidance, but say there's less, but less isn't popular. It couldn't solve enough of the problem. Yeah. And. The scrum master role is flawed. It's a problem because it should be a coaching role, but it's not deemed as coaching and to be a coach, you have to be an agile coach, which is different. And it's, that's a nonsense. And if I loop back around to talk about the product world as well, is that like safe does well, because it isn't all about, here is some education on how you can support people. It also says to people, here is some education on what you should be doing. Right. In the product world, It's very little. When you look at the education around stuff in the product world, actually says, and this is how you support people in the protocol is much more about here is something practically you can go and do go and try. I've tried it. It worked. And it's very much where it's all is that there's the agile world. It's those are people who. Don't create product anymore. Don't do product management. Haven't worked as part of a team to live, creating a product and been through that pain, the anguish and the joy for a long time. Maybe for some people, if ever. So it is this kind of fluffy supporting role or roles that exist without a strong code of ethics, without any link back to actually how you measure the effectiveness of proper coaching. Or mentoring. And I think that's kind of part of the problem. And I think that there are things we can do to tweak the system, but and to challenge it and to help people. But I, yeah, I do wonder if, as I said earlier, if that horse is bolted and it's not, I'm saying it's not where it's definitely worth trying, but. This is why I think that the third way for me is product and agility, and there should have always been one, they're not one, and let's not try and drive a wedge between, let's try and bring it together. And if we do, that opens up new opportunities and perhaps a new way to try and make the best of both worlds. I don't know. Yeah, yeah. Oh, sorry. I shouldn't say because the, a little bit of a segue into plugging my own content, but this is why I started thinking about dysfunction mapping is because to your point that we. Has the horse bolted? Can we actually make a difference in raising that bar of the practitioner? For me, the answer is partly challenge that monopoly of framework certifications, but it's partly give people actual tools that they can use that help them to do this stuff, right? Because like I say, for me, the thing that I've learned of eight years of doing this is it's. Mostly a repeatable pattern when you're a coach, you enter a team, right? And yes, every team is different. Every team has its own challenges and you cannot just bring solutions in that you've seen elsewhere and expect them to work. But your approach as a coach, as a practitioner, as a scrum master. In pulling out those problems and finding patterns and helping shine a light on them so the team can self organize and figure out a solution to them, that is in itself a somewhat repeatable approach and something that I have found at this point, like every team and organization I've joined in the last kind of four years, it's been almost cookie cutter in terms of my approach to getting to concrete plan for change. The plan itself is drastically different for every organization. But that approach to getting there is repeatable. And it occurred to me, it's why, why is no one else sharing their approach to doing this? And so dysfunction mapping is that, right? It's my attempt at how do I make this something repeatable that you can teach someone to do? And it's not just, Hey, here's a framework, get certified and how to do it. It's, here's a thing that you can use that you can actually apply in your team or organization to create one of those concrete plans, which luckily both already agreed on is anchored in. Real perceivable outcomes, right? Not necessarily metrics, not necessarily like a number that goes up or down and tells you that you're 92 percent successful because it's not quite that exact, unfortunately, but that gives you does give you specific. I have seen and observed these specific problems. I have taken these specific actions and these problems either have or have not gone away. That is something that gives you a level of. Clarity that your actions are useful that I think most scrum and agile practitioners would really benefit from and really crave, but that no one seems to be providing. And I think, like you say, the reason is because there's no money in it. So the answer in the short term for me is okay. I, I do this as a side project and I just try to change it in whatever degree I can, but I think longer term, if you can just lower the bar of entry and make, if I can create these tools in a way that doesn't require me to sacrifice two days of my time to teach it to someone, and I can just say, here's some content, consume it, now you know how to do it, hopefully that means a lot more people will be interested, so they don't have to fork over their hard earned money instead of buying beers or a new PlayStation. Nice as a whole can of worms we could open around the... The perceived value of free things and actually what is the right, is free or is it charging just a little bit? But I think that we should draw this episode to a close because this is, uh, we've been talking for a while. It's been lovely. I enjoyed it. There we go. Went a bit deeper than normal, which means that we're probably going to have time to record one more episode. Before we wrap up, Michael, I will ask you the question, which I ask many people is, what do you think we should talk about in the next episode? So I'd love to talk a bit more about this detail of how do you actually support people into, I guess, being more effective practitioners and actually measuring the success, but yeah, I'm also interested in a bit more in this, future utopia, right? Product and agile together. What does that look like? That, that's something that interests me. Okay, sweet. All right, let's, let's talk about the measuring success and we'll throw some ideas out for that. We'll try and make it as practically useful for people as possible. Um, and we'll look at both sides of the coin, product and agile, and then time permitting, maybe we'll talk a little agility as well. Yeah, sounds good. Brilliant. Thank you so much. Yeah. Cheers, man. Michael, it's been wonderful to have you here. And for one episode down, one more to go, everybody, thank you very much for listening and we'll be back again in the very foreseeable future. Thank you. Thank you.