Speaker 1: 0:03

All right, welcome back to that Change Show. It's Friday, June 21st. This is the pre-Agile 2024 chat with a few folks that are talking at Agile 2024. So if you're listening to this at thatchangeshowcom, if you want the video version, you can head over to leanchangetv and you can find those, which those are all posted on our YouTube channel. So let's get into who's here today. So first, john Tanner. John's the CEO and chief strategist for C4G enterprises, and I know you used to work at leading agile as well. So do you want to give us a little bit more info about your background and how you got started with agile in the first place?

Speaker 2: 0:42

Yeah. So I came up a developer track, which I think we got more on this call than have. So I was engineer all the way up. I took Agile across. The federal space is really where I started with it, working as an engineer at the White House Communications Agency, then started doing Agile support and training there, spread it out to state departments so on. I joined up with leading Agile when I moved out of the Fed space and went across commercial, working with enterprises on large transformations, took a couple years off from the Agile scene for COVID and then came back, started my own company to start supporting those enterprise initiatives again. Especially with the new wave of AI, it's really exciting stuff.

Speaker 1: 1:23

Right on, right on. Thanks for taking the time to join us today. Yeah, and Quinton Cortell. It's funny, I got a friend whose last name is Quinton, so every time I hear that, it just always I get confused a little bit. So Quinton's the founder of Fast and I'll let you say a little bit more about that. And also, how did you get started with Agile in the first place?

Speaker 3: 1:43

Okay, I'll do that in the reverse order. So I'm a developer as well, like John, and back in must have been 2002. Yeah, like my team took on extreme programming, it was the dumbest thing I've ever heard of. I hated it and I'm like this Agile thing is stupid. Luckily I stuck it out. I said, all right, I'll give it six months. And after that six months, well, by that six months period it made a lot of sense. So if you can turn a hater to someone that likes it, they end up being evangelists. So that was me.

Speaker 3: 2:23

So from there I went into consulting, I did some management, I did contract work, I did pre-sales work. So I've done lots of things. Always I get itchy. If I leave the code too long, I tend to come back to it, and I have always been in the agile and software space, mostly short stint with a startup which was really neat to see how that works, especially from a product management point of view. At an Agile conference, sitting in an OpenSpace event, had this aha of like hey, why aren't we using OpenSpace as a way to solve this Agile at scale thing? That was the birth of an idea which I've since been working on, sharing, on experimenting on. It's now called Fluid Adaptive Scaling Technology, or FAST, or FAST Agile, and that's my baby that's now out in the world. There's multiple experiments going on. Uh, we just started doing online classes and trainings and something I can talk about all day, but we're not here to talk just about fast. But thank you for asking, jason.

Speaker 1: 3:38

Oh, cool and the interesting part is I think all of us got I never do introductions of myself, I'm Jason started as a developer way back when. I like to call myself the world's greatest ColdFusion developer, which, by astonishing coincidence, I'm the world's only ColdFusion developer back then.

Speaker 2: 3:58

No, that's where I started. I got from trashy PHP straight over to ColdFusion buddy.

Speaker 1: 4:03

Me, too, got from trashy php straight over to cold fusion buddy. Me too, and um I I think like a lot of us in a similar spot who've been involved in agile in a long time, I think once, at least for me when I discovered it was like, oh, I've always worked this way anyway. So I think that you know the folks that really got into this in the late 90s, uh, with, and then early 2000s with Agile. It's kind of the same and that was basically the same for me. And then, since the mid 2000s, most of the time has been spent on the organizational change aspect of Agile. But the thing I like is that we all come from technical backgrounds and the intention of what Agile was in the first place. So once it started to become a license to print money you know, 2012, 2013 ish at least my thoughts I thought the intention started to get lost and you started seeing people look at agile as a set of processes and tools, like, basically, they started looking at the right side of the manifesto. Only and now there's been a lot of conversation around is agile dead. Agile doesn't work.

Speaker 1: 5:09

I saw some really crazy article from some, like framework or process pusher, that said agile projects fail 290% more than traditional ones. I don't know if you guys saw the same article on LinkedIn and I was just like, oh geez, here we go again. But so I thought what we would chat about, since we're all talking at the big Agile conference, which, oddly enough, started up as a conversation with like 10 people. So Ellen Gottsteiner was at the first Agile Alliance conference, which was people sitting around in a room talking about stuff, and it's kind of grown into this global event, and so I thought that would be a really good topic is now the good time to sort of double down on Agile. But before we do that, I'm going to introduce our third guest, chris Schenkel, who's just joining us now, and let's wait till he gets his audio and his camera going. Chris is the director of innovation at SDP and we were talking beforehand that I can't remember if we've met before because you're familiar. We did.

Speaker 4: 6:10

We did. It was the 2009 Lean and Kanban, the very first Kanban conference, I believe, or three of the Kanbans I don't know if you were at 2009 or the one right after that but yes.

Speaker 1: 6:22

Yeah, that's when it was called LSSC.

Speaker 4: 6:26

Yes, that's when it was called LSSC. Yes, that's correct, lean Software Systems Consortium. I don't know something weird like that, right.

Speaker 1: 6:31

Yeah, okay, so we just finished our introductions and did you want to go ahead? Just give a quick introduction of yourself and then how did you get started with Agile in the first place?

Speaker 4: 6:42

Sure, so my name is Christian Cole. I'm the director of innovation at a company called SEP. We're a software product design development company and started doing Agile here in 2004 and then Lean in 2007. And really at the time it was a way for us to start working better to help our clients. Our clients hire us to help them build software products. A lot of times, the products we work on are both hardware and software medical devices, aerospace engines, precision ag equipment a wide variety of industries and so it was a way to help them change the way they think, as software started to become a much larger part of their products software started to become a much larger part of their products.

Speaker 1: 7:31

All right, very cool. So let's dive on in. So, thinking about how Agile's kind of evolved since the days when we got started actually even before social media, so there really wasn't any way to learn about this stuff compared to today and then how it's sort of evolved into a big business and now people thinking that it's declining and stuff. Who wants to start us off on? What does that arc of that story look like for you and where do you think Agile's at today?

Speaker 2: 7:54

I think you said something interesting there. We didn't have the social media. In a lot of places I worked, we just honestly didn't get online to even get our code snippets. A lot of little government facilities and things. It grew from word of mouth, from people attending little meetups or hearing that there's a better way. I remember talking in the halls like have you guys heard of Scrum and what that looks like? And then trying things. We experimented and there was no three-day course. You have to do it this way. There was no book that said you had to do it this way. It was a collection of practices and we tried it until we found what fit.

Speaker 2: 8:29

You put together your own puzzle, but it drove toward a different sort of development. I mean, it's mostly unheard of now, but we would plan six months. We would work for a year and a half and then we would release a completed thing and you shipped it once and you didn't plan to update it a lot. You might be able to patch it. You might have to do a disk for it in a lot of cases, but the fact that we were able to plan quicker, build quicker, test quicker was really interesting to us. It came with all the technical practices. It wasn't just the process, it was like all that rigor that you needed to do. It drove improvement.

Speaker 2: 9:04

So it spread and then over time, over the course of just a couple of years, every developer was talking Agile and what it meant, but it wasn't in a framework sense, it wasn't in a.

Speaker 2: 9:15

You know, I took this class, since it was here's what we learned within our team and that was exciting. I mean, that was really exciting and our topic today is talking a little bit about that. A lot of that excitement went away. It's like you know, you got your favorite cereal or anything else and as soon as the big conglomerate gets a hold of it, it's got the logos on the box. It just doesn't taste right anymore. It started to feel like that, but I won't delve into that yet. But like it was an exciting, an exciting like rising up sort of deal and having been a developer and come up and and being forced on those late night death marches to like get, get the thing pressed like on the cd before it goes out. It was refreshing to be testing and trying and improving the excellence, the technical excellence aspect and having a bunch of people excited about it together um. I liked that it was a movement.

Speaker 4: 10:05

Yeah, I would say my experience. We started as an organization through XP and introducing developer-level practices which were fantastic to help pairing and test-driven and continuous integration and all of those pieces which I think everybody probably does today to some extent. I would be surprised that there's lots of organizations who, who, are not.

Speaker 4: 10:30

It may look a little differently depending on where you are, but but I'm guessing everybody does some version of those. Those practices are sort of pretty well established. And then we, we started going down feature driven development, old and old and crystal clear, from Alistair. It wasn't even Scrum, I didn't even know. Now Scrum is kind of like, I think, the brand for Agile, almost where it gets replaced.

Speaker 4: 10:56

But completely agree with John, it was a way for us to work better and there was a lot of excitement with it. And so this whole movement of it, of its dead, and like the labeling of it and all that stuff, like I just maybe I'm just ignorant, but like it, it just almost confuses me, like I just I don't know that. I like I understand, like I still see us doing it, I still see us striving to do things better. We, we're still emphasizing, you know, people and you know I don't know, I don't, I don't see the absence of those things. So sometimes I'm confused, I guess, when people talk about it being dead.

Speaker 4: 11:37

I agree, it was an exciting time. It helped us get better. We grew into that. And then we started doing Kanban and Lean, because, well, that helped us get better too. Like we weren't doing visualban and Lean because, well, that helped us get better too. Like we weren't doing visual boards and tracking at the time, and so it was like we did it and it helped us deliver better. It helped our customers. They liked the results of what we were delivering and the way we were working, and so we kept doing it Right. Like it wasn't something like, well, we need to take a class or stuff, there's some label, we need to go and do this or be this or whatever. It was simply a way that helped us deliver software in a better way to our customers, and our employees enjoyed working that way more, and so why would we not do it right?

Speaker 1: 12:24

Yeah, and I remember, quentin, you were mentioning in the opening around your experience with getting started with XP that it wasn't so good. What got you over the hump?

Speaker 3: 12:36

I noticed the people that were doing it in my team were laughing and having fun. How come they're having so much fun? And I'm like I don't need to write tests. Why should I write tests? I'm a senior dev, like I fix bugs. I don't. I don't create bugs. You know I don't need to. I need to write tests.

Speaker 3: 12:57

So I always like kind of arrogance and stuff, and and then you know, talking to the others in my team trying to say these testings and they're, ah, these tests are actually pretty good. I'm like, oh, and then so, being willing enough to just say, all right, put all your judgments aside and just do it, just try it. And yeah, I guess my aha moment there was a couple of aha moments was when you know you hit build Back in those days. You build it's going to take 20 minutes, and then two-thirds you know we're 15 minutes in and the build crashes and you're like what happened? This test failed. Why did that test fail? And you go oh, because I just wrote a bug and I would have never known about it if it wasn't that test. So you know, you know you go. Okay, this is why we write tests.

Speaker 3: 13:52

Now I'm in love with this. This is great, so that and and pair programming, sitting next to someone that knew more than me and and saying, um, you know that person saying hey, do you have an idea? And me having to be, uh, eat humble pie and say I don't. And but this person didn't shame me, uh, didn't embarrass me and says, look, I got this idea, did it? Uh, here, slides the keyboard over, let me walk you through it.

Speaker 3: 14:12

And and getting having such a really great first positive experience of of being mentored, uh and coached by someone who I thought was below me, and I'm like that changed me forever. I'm like I'm throwing my titles out. I'm never calling myself senior anything anymore and I'm going to always do this for whoever I'm with, I want them to have this same experience. So it was a number of these little things added up, when this is the right thing to do, that I could go on vacation or holiday and matter Like I wasn't going to get called up because collective code ownership. So all of these things meant this is the right thing to do for an organization and this is the right thing to do for me. It makes my life better and it made me a better person. Agile made me a better person.

Speaker 1: 15:11

It did give me confidence it made me a better person. Um, agile made me a better person. It did give me, it made me more social. Um, so that was that's what won me over. Yeah, that's that's. That's interesting, because that's what I really like about agile is that sense of uh, working with people together towards a common purpose.

Speaker 1: 15:24

And you know, all of us coming from a technical background, I think I wonder if that's one of the reasons why there's so much chatter and noise around agile dying, because we've seen so many people try to just apply the process model and they don't have the technical chops underneath to do it and it it's infinitely more difficult. So you start to get into things like well, we'll do a two week development sprint and then we'll do a two week testing sprint because we have to, and those aren't. I don't think those are problems with the teams not wanting to do it. I think some of it, at least from what I've seen, is in the organizational layer. So you talked about pair programming.

Speaker 1: 16:02

I'm sure you guys have seen this too, because you've worked in enterprises that it's not allowed, right? You've got to bill your time to a certain time code. You're not allowed to pair program because that means if you're asking for help, you're a bad team member or bad developer. You don't have the skill or measuring by lines of code, because the myth is that productivity is how much how many widgets you crank out in a day. So I wonder if it's these things in the organizational layer that have caused people to not be able to bring in the technical stuff. So now they think, well, agile just doesn't work because they're not actually changing how they build stuff and test things and involve customers.

Speaker 2: 16:42

I think to claim Agile's dead, you've really got to define what you call Agile. And the big problems we've faced over the past decade is every good idea, every bad idea, every marketable idea gets called Agile and shoved into this Agile box of things. And we've got Agile up at the C-suite and Agile in HR and Agile at the portfolio and program level and Agile funding and everything's just called Agile with no direct correlation to what Agile is or an explanation of how that fits any sort of Agile mindset and approach. And we've done about a decade of selling Agile without ever really defining what Agile is. When I get to the core root of where I get to Agile technical excellence, peering and pairing those XP practices integrated with those sort of iterative and incremental processes the very basic things right, I love Toyota production system. I roll that in All the thoughts that led to this. It was localized, it was very focused on how we do engineering well, and then the principles do apply. They can apply elsewhere, but you got to reframe it for where you're applying it. You can't just call something agile.

Speaker 2: 17:55

So when people start saying agile's dead, I want to understand what they mean. Is it the framework they're using? Is it working. Is it that something we call the enterprise doesn't work at the enterprise? Because to me, the fundamentals they've been around since the 40s. It's not like we invented it in 2000. It's the stuff that built up over time. We just grabbed a good label for it and put a human focus. That's not dead. That's what we need more than ever. We make a mistake I think all of us and engineers here probably can attest to this. We let the technical conversation wander away from the agile conversation. We allowed it to split off and we could help process agile conversation, technical agile conversation, enterprise agile conversation.

Speaker 2: 18:42

We never should have let the technical excellence wander away from the process, because they're both necessary to do agile and we shouldn't let it blow up to cover absolutely everything else, because not everything is agile and not everything needs to be agile if we're using agile as that core technical thing.

Speaker 4: 19:01

Yeah that's really good, that's really good stuff, john. It makes me think, you know, what do I define, or how do I define it? And what you know, would it be dead? And I don't remember where I heard this. I certainly am not smart enough to come up with it, but I sort of go back to like three things how are you forming teams? What do your teams look like?

Speaker 4: 19:20

And Agile has an opinion about, like you know, everybody sort of being part of the team that you need to make decisions or do that right, sort of a cross-functional team. Do you have like a backlog of work? Right? So the concept of a backlog or some organized work right, which is just really a governance model, right? So Agile has an opinion about what the governance model should look like and how work should flow to teams, about what the governance model should look like and how work should flow to teams. And then, probably the most important thing is, can you produce a working, tested quote-unquote increment on a regular cadence? And I mean it just goes like you said, it goes back to the 40s. It's like structure, governance and metrics. It's like those three kind of concepts. And Agile has an opinion about what that looks like for modern software development. Well, guess what, like. But those things work in lots of other uh, um, industries too. My wife is a chemist here in town for eli lily and, uh, you know, she started using some kind of bond in agile. So she started seeing me stuff and started recognizing oh, I could break this work into smaller batches. Oh, oh, I could pass around documents for review or think about how I'm approaching clinical trials differently. Right, like, the concepts I think are still really solid and good.

Speaker 4: 20:34

Like you said, where are the struggles? And is it a process struggle? Is it? You know, where are those challenges that people face? And then, is that really agile or is that? That's something else? Is it? Is it a contextual issue? Right? Is it, um, um, you know, an organization issue or or whatever it? I don't know it's, it is the thing that got the big label and all the press, and so I think it gets all the blame.

Speaker 4: 21:03

And at least where I'm at and I'm in Indianapolis, so Midwest Central Indiana right, like people I talk to who want to claim Agile is dead or they just want to rail on Agile or whatever, if I ask them, have you ever been responsible for shipping a software product or a feature or anything. So many of them have never shipped software and I don't mean that you can't work or have a job or whatever if you haven't shipped software or done it. But I think to your point. Sometimes it feels like there's a disconnect from the management process and tools or how we think about building a product, from the actual technical tools and skill sets right, the XP and some of those things provided for us. That really sort of changed the way we think and I love your point.

Speaker 4: 22:02

That made you a better person. I think that is so good, so true. I can remember one of the first projects I was on. The client I was working with we started doing Agile and it had greater visibility into what was going on and had a better clarity around what the schedule looked like and had a better understanding of his role or responsibilities. And I remember after one weekend he said to me he said, chris, this is the first time I've got to go and watch my daughters play softball and not worry about work and it's just like, well, that's awesome, like what? Yeah, so the whole like make me a better person. I uh, that resonates with me. I think that's. I think that's really good, I think those stories sometimes get lost.

Speaker 1: 22:49

Yeah, same.

Speaker 1: 22:49

One of the first open spaces I went to is in North Carolina, I think, somewhere in the mid two thousands ish or something like that, and it blew me away how, uh, everybody was so generous with their time and their skills and their thoughts, like you could walk up to an esther derby or johanna rothman and just they would welcome you in and give you as much knowledge as you wanted.

Speaker 1: 23:15

So there it was, I same with, uh, you know, I was on my way probably down the path of your typical command and control person, because I think just parts of my temperament aligns with it. And discovering that and how generous people were with their time and things like that, and how you could just reach out to somebody who you know you would think would be you know why would they want to help me or talk to me, like they've written 12 books and they travel the world and stuff and they're more than happy to have a conversation with you and stuff. And just seeing that that, that level of helpfulness, to want to, you know, genuinely help other- people, I think was a huge factor in the, in the turning point for my career too.

Speaker 4: 23:56

So what do you think I mean? What do you think the value is? Or why, why there's so much talk about like agile being dead, like, what? Like? How does it help somebody in the situation they're in? Like, if I think about like I don't know, maybe it's just me I'm probably a selfish person. I think most people are to be selfish, like you, like, how does it? I struggle with even understanding the like the value right, is it? Is it just a social media thing and get you know clickbait and get looks or whatever Is? Is there something underlying there that that is a fundamental problem that is worth, uh, I guess talking through or helping or or or share? You know what I'm saying.

Speaker 1: 24:41

Like, I just yeah, I think that's part of it for sure, like people want eyeballs on their articles or they've got something they're trying to sell so they want to get people who've kind of latched on to that same emotion. I've experienced the same thing you have because I worked in an organization where Agile was used as an excuse to make us work harder. And I've seen that in organizations too where they add agile things onto the existing team's processes. And you know, I always had a situation in one of the banks here in Canada where the QA team was up to like three, four in the morning running their test suites and stuff, because they still had to do all the old world things. Plus, they had these annoying agile people coming in and they had hired like five different consulting firms and all five were kind of giving these poor QA folks different ideas and different objectives and stuff. So they had a very bad experience. So in their view it's.

Speaker 1: 25:36

I don't like this because I've gone through it and I don't think a lot of people have really experienced the power of working on a really good agile team. There's a great book called the New Kingmakers and it talks about baby duck syndrome. It talks about it in the context of development. So, developers, the first language they use, that's the one they love and they compare everything to it. So nothing else will ever measure up to their first true love. So that first experience, if it's not a good one, up to their first true love.

Speaker 3: 26:05

So that first experience, if it's not a good one.

Speaker 1: 26:08

Immediately. Agile doesn't work and I think a lot of the times, especially at LinkedIn, is pretty bad for this. People jump all over those people and say, well, that's not what agile is, it's not this, it's not that and the other, but they've already felt that emotion of this was not good for me. Therefore, I don't like it. So I think it's two, but I think the first one you mentioned is probably the one that's the most People want eyeballs on their articles, they want more LinkedIn followers, they want to sell something, and it just spirals on from there.

Speaker 2: 26:36

I would add to that. So I agree there's so many trademarked new frameworks that are the new thing that's going to solve everybody's problems. So that's one. I'd also say it's a self-inflicted wound for a big part. To me, agile has always been something that is only successful if it's voluntary, and for many years organizations have been forced into Agile. You take a really high performing, good development team that maybe could use a little help and you go force them into a three-day training or you force them into a process. You don't let them grow it. It creates resentment. So we're seeing people they're casting off these shackles of agile that was placed on them because they didn't volunteer. They asked for the training, they were forced to get the certification. So there's that side of the backlash as well. I do think the first one's more prominent the instigators that are out there to brand and sell something, but they're tapping into resentment from a forced march into something that, even if it was done well and beneficial, they didn't sign up for.

Speaker 4: 27:36

Love the framing shackles of agile Like that's. I love that.

Speaker 3: 27:42

I want to pressure test something we've been saying. Is it that by saying Agile is dead, that's helping me sell something? Do we have an example of that?

Speaker 1: 27:54

That article. I don't want to mention it because I don't want to trash it publicly. But the gist of it was they fail 289% more than regular projects and when you read through the article it basically becomes a selling thing for their products and services, stuff like that, yes, okay, yeah, I have seen an article.

Speaker 3: 28:19

I wonder if this is the same one we're talking about. Yes, caught. I wonder if this is the same one we're talking about. Um, yes, and they're. They're saying, yeah, agile is dead here, use this new process, um, which it looks it's strongly around documentation and and specifications, kind of, hey, waterfalls back, agile is dead, but they're not calling it waterfall. Okay, yes, I think that is an article, because but how many is that? The only place we're hearing it? Um, because we had capital one, I think was that was the first public recognition of of, like, the industry's changing.

Speaker 3: 28:56

For me, anyway, the, the shock news where they laid off 11,100, I think it was agile people and in the agile industry it's like what does that mean? And is this going to keep happening? And sure enough it has, and I think that's also lined up with the big tech downturn. There's lots of software developers getting laid off as well. So the agile people have gone along with that. The agile people have gone along with that. But the yeah like is that is that part of the agile is dead, is it just? Is it riding on the coattails of the big tech downturn?

Speaker 1: 29:35

and the patterns here too, like at least in canada, with the telecoms, banks, insurance companies. You know, five, six, seven years ago it was easy to find an agile coaching, external consultant job. Now, now nobody's hiring them. They want internal people. And with letting people go, it's it's management by spreadsheet. Who's delivering direct value? Well, the developers, the testers, the project managers, the whoever, the whoever's. What are these coaches, people, doing? What are, what's their deliverables? Oh, they don't have any tangible deliverables. We can cut all of them.

Speaker 1: 30:09

So a lot of the people I know up here, they really have a hard time finding companies that see the value of coaching, because they've been going through it for so long that they're not seeing any tangible, measurable direct value. And the assumption is oh well, I can, just what's a scrum master? We have project managers, we don't need them, let's just get rid of all of them. So they're still kind of managing their system with their old worldview of seeing things. I think that's why a lot of companies like this came out of Australia.

Speaker 1: 30:42

But you've heard the phrase new ways of working. They got so fed up with agile five, six years ago they stopped using the word and they started using new ways of working as a replacement for it, because there was bad word association with it. So I think there's a lot of factors that kind of combine into it. But I still think it's a great time to invest more in it, because I think companies have started to learn that it's not just about development teams, even though we've been saying that for two decades now but now that they've kind of felt going through these waves of transformation, it's like, well, maybe there is more to it than this. Maybe it is more about how we change our organizational system to support these teams instead of dropping change through the hole in the floor and pushing it on them.

Speaker 3: 31:30

You mentioned that you know, like, why are they laying these coaches off?

Speaker 3: 31:33

Because they can't measure what impact they had.

Speaker 3: 31:37

And is this a time that we now need to say, hey, if we are going to lean in heavier, how do we start measuring the impact that we have, because we don't want this to happen again and that we can actually say, hey, yeah, you do want to hire me because, look at this, here's a case study I've just done. Here's the impact, here's the actual measures, here's what we measured and here's the return on investment that we can actually give them something in the language that management want, right? So, for the very reasons they're laying us off, we need to go all right, we need to be smarter about this and maybe, by starting to measure it, we might find we're not actually needed. That could hurt, but all, all right, we have a hypothesis that we are. Let's prove that hypothesis like using data and saying this is why you want us, here's what, here's what we do, here's what I can do for you. Um, and if, if, if, the kpis haven't moved this far in this time period, let's call that experiment done and, idfs, I'll go find somewhere else.

Speaker 1: 32:45

Yep, yep. If we only had somebody on the call who was doing something on metrics at Agile 2024, that'd be great, because I think that'd be a perfect question for them to answer.

Speaker 4: 32:54

Is anyone there, by the way, john?

Speaker 2: 33:00

It's actually so. The last time I spoke at the one of the agile conferences it was 2018 and then 2019, and I was talking about using metrics for good. That was the basics of it goal question metric, and it was that message that you need to learn how to leverage this data to do good things in your enterprise, and I was raising the warning flag to coaches even back then. If we can't demonstrably show what our hypothesis is resulting in, if we can't actually document the experiments we're doing and we can't demonstrate the value to the org, you will just become a line item to cut in the future. On this year, I'm talking very much about um, the adverse impact of measurements themselves and things like that how to safely start to measure things because I think we overcorrected a little. I'm sure you guys have seen reports by McKinsey and other big ones that have productivity measures for the developers and instead of lines of code, they're doing things like velocity and really weird twists on how we do productivity and stuff. But we're not doing outcome based measures. We're not doing an assessment of the impact on the organization of the, but we're not doing outcome-based measures. We're not doing an assessment of the impact on the organization of the things we're measuring. And with Agile, one of the problems a lot I've seen a lot of the coaches have trouble with is at the end of an engagement they go in for three months, six months, a year, whatever. There's nothing they can show, there's not a spreadsheet they can pull up that they can say this is the good we did, because they didn't have a measurement like data insight oriented mindset going in. You can look around, the people are happier, you can point to things and say that we're doing better. But if it's not quantifiable, if you can't like get that number down, you can't prove the hypothesis. So, starting with that mindset I mean you were spot on with that you have to start there. And if you don't know how to, I will talk to anybody about metrics all day long because it's really not that hard. Most executives want to see like the same three things ROI, however you define it. They want to see efficiency gains, however you define that. They want to see expansion of the market or time to market getting better, like it's the same stuff. How you measure it for that organization. You have to learn the organization. What I love about Agile is because we get those really tight feedback loops, we get those really tight measurement cycles. We learn, we learn. We get our data insights quicker. Not the metrics, the insights from the data gets to us quicker.

Speaker 2: 35:21

I've never struggled with keeping a business engaged with a transformation if I could show them measurable results along the way. If you can't do that, this is the thing that I fight most against. We went from doing continuous improvement to doing continuous transformation and a lot of these orgs have been transforming for years and years and years. And then they let go of that one consulting firm and bring in the next one and we start the change curve all over again. I'm sure we have a change expert on this call as well, but the problem is we're not measuring, we're not stabilizing, we're not getting that good data and saying, okay, time to sit where you are and mature before we do the change cycle.

Speaker 2: 36:05

It's a lot. It's a lot you have to do to do it. Well. If all you have is a certification and some history, having worked kind of around Agile, and you're not taking a logical approach, the enterprise can measure. It's really hard to prove your value and they may like you a lot, but there's not the budget anymore to keep people around that they like. It's the budget to show demonstrable results. It's that downturn we were talking about. It has hit everybody hard. If you can't show the numbers of why you're important or why the change is important, that change is going to get cut. That's going to be another line item.

Speaker 4: 36:39

I think people forget too that the application of Agile is very contextual, right. Like if you were doing something that wasn't working and you weren't seeing results, I would encourage you to try something else. Like I'm an avid golfer, there are lots of swing theories and that's changed over the years and stuff like that. But the reality is not every swing works for every player, right, Like everybody's not trying. You got to figure out what works for you and maybe it's agile, maybe it's not right. But to your point, like if we're not, if all we're measuring is how agile we are and we're not actually measuring like sort of the outcomes, the real business benefits of being there, if that's not clear, great, Then don't do agile, I don't really care. But if you're going to tell me it's dead or you're going to you're going to tell me you're not going to do, agile what are you going to do?

Speaker 3: 37:33

And can you?

Speaker 4: 37:34

measurably. Tell me it's better in some way.

Speaker 3: 37:36

And if it?

Speaker 4: 37:36

is great. There's an article I used to share with people years ago. It was article I used to share with people years ago was in Fast Company. Happy to share it. Give it to you, jason, if you want it. It was a fascinating read. I don't remember when it was written but I'd share it with people almost just as like an aha, like agile is the best thing it was called. They Write W-R-I-T-E. They Write the Right R-I-G-H-T stuff. They Write the Right Stuff.

Speaker 4: 38:03

And it's about the company who wrote the engine control software for the space shuttle and you want to talk about like Waterfall. They were Waterfall to a T, like to the extreme right. But they shared stats in the article that it's like the last three versions of the software each version, 420,000 lines of code, like had one error right. The last 11 versions had a total of 7, 17 errors right. Like by all measurable accounts. They were pretty good. Like they delivered on time, on budget, high quality.

Speaker 4: 38:40

The space shuttle launched many, many years doing it. So it's like they found something that worked for them and we would all look at it and say that's not agile and great. But if it's working and from a bit, it's not only working from a, like a developer standpoint or whatever else, but it's also working from a business. Right, you've incurred additional costs coordination costs, transaction costs because you're working in a different way, but people see the value in it, or they want it, or the business is willing to pay for it, or the company that you're selling. If that's all working, then great, right, and if you find better ways to improve it, do that.

Speaker 4: 39:23

But I mean, I'll be honest, there's a lot of companies around here that I see agile coaches coming in and they're agile coaches because, well, they were something else before that and that went away and they needed to do something and the agile bandwagon was easy to jump on and they had never shipped software. And they came into our customers who are working building medical devices, blood glucose meters, infusion pumps, and man, they gave them bad advice and those people really shouldn't have been there. You know, and I hate to say it that way, but like, I think that really is the truth and so it's coming in and coaching or whatever we're doing from an agile perspective. Like you know, I tell people all the time perspective. Um, like you know, I tell people all the time there's a difference between knowledge and talent and ability. Uh, I'm an avid sports fan, so I probably used way too many sports metaphors, but you know there are 32 teams in the nfl and there are 32 starting quarterbacks there's a lot of

Speaker 4: 40:16

backups too, and all those backups know how to like, take handoffs and make all the throws and and take snaps and all that kind of stuff, but they're not starting, for a simple reason their value is not evident when they get on the field.

Speaker 4: 40:31

And so if we can't demonstrate our ability to like, make a difference or improve and I don't think it has to be always qualitative, it could be, you know, or quantitative, it could be qualitative, like there could be but.

Speaker 4: 40:43

But the reality is, if, if, if it's not better in some way or measurable way, then what are we doing? Right, and I certainly don't want to be in an organization trying to coach or help. And then it's like, I'm like, well, this isn't better, I'm not helping. Well, maybe I'm not the right person to be there, I don't, life's too short, I don't want to spend a year, six months, whatever coaching and doing something and not being effective. Like, maybe I'm not the right person to be there, and that's fine, right, like, but we got to make a difference. I appreciate you guys, both sort of, really are hitting that. That the value, however you want to measure it, look at it needs to be measurable and clear, and we need to accept the fact that maybe in some cases it's not delivering on the needs of the business and we need to look and do something different.

Speaker 2: 41:39

I love what you said there, chris, because it intones you're taking the time to understand what the business needs, and every business is going to be different. Right, it's not. Just let me pull my five. It's what does this business need? Do my talent, skills and education, my knowledge, does that all work for this scenario? It's scenario based, yeah.

Speaker 1: 41:58

Yeah, and we sometimes underestimate the value of coaching agreements and system entry point, just to get a little bit nerdy because sometimes you're brought in with an expectation that you are going to be a process coach for the team, but you as the agile coach and I've gone through this too is, oh, I'm being hired to help you transform, which means I can run amok everywhere in the organization. So there's a disconnect between what I think is being asked for, which shapes my behavior, versus what the client or the customer wants, and I think that can radically vary, especially once you start talking about enterprise, because enterprise agile COEs tend to have measurements already set out, so coaches will be responsible for X, y and Z One smallish to medium-sized company. It's the only case I can remember somebody asking me how do we know you've been effective? And you were the right consultant or coach to come in. And I said why don't you just in the lobby, why don't you just put a big poster about the value of the contract, like how much you're paying me, and have people rate it from zero to 10, if they're finding value, and a comment why? And I really wish they would have done that. Because it would have been an awesome picture to tell, or and story story to tell.

Speaker 1: 43:07

Um, because, like you mentioned, chris, the the qualitative or quantitative. Sometimes does this feel better than it used to be as a good diagnostic. So I like to talk to them about the difference between diagnostics and measurements. Diagnostics are we still headed north or are we in the ditch? Uh, measurements how do we know? When we got there and everybody knows that roi and and hard numbers and smart numbers and things, those are lagging indicators. You're not going to find those things until the coach's contract is up and they're gone. Uh and chris, you already mentioned that as well.

Speaker 1: 43:42

So I wonder if there's. You know a lot of the conversations swirling around Agile being dead or not working right. I wonder if there's a difference in if that's isolated to enterprise, just because the systems are a lot more complex. Once you step into an enterprise, there's established rules, there's established performance management, established structures, established rules. There's established performance management, established structures and sometimes you can't break those. Every Agile team has a project manager, a program manager, an Agile coach and a scrum master and then a team project manager. So you've got five people now competing with all different objectives, reporting potentially to different areas of hierarchy, and we're handcuffed by that system.

Speaker 4: 44:26

I do think it's interesting and, quinton, I think you sort of alluded to this a little bit earlier, but I've been going to Azure conferences for a long time lean conferences.

Speaker 4: 44:39

You know who I don't ever see at Agile and Lean conferences talking about being Agile and Lean. Like I don't see Amazon there. I don't see Apple there. I don't see Apple there. I don't see, I don't really hear from Google. I don't like. There are these huge tech companies and you can argue like right or wrong or wherever they're at. You know the FANG companies and all that Like but measurably.

Speaker 4: 44:57

These are huge tech companies that have made significant differences in all of our lives, or you know that have made significant differences in all of our lives, and I don't hear them talking a lot about Agile Dead, not dead. Whatever they're doing, what works?

Speaker 4: 45:14

I'm sure they are doing some Agile things and I'm sure there are probably some things there that aren't Agile, but it's interesting to me that there oftentimes feels like this huge, like absence of those companies there. And if you probably like counted, we'll go to Agile this year and play a drinking game or something, or how many times you hear one of those companies mentioned in somebody else's talk? Like they're mentioned all the time but they're never there themselves and like I don't know, they're just in my head. I kind of think like well, why is that? Like maybe it's less about being agile or doing agile, or agile being dead, or it's more about, like shipping product, making a difference for your customers, or maybe it's just about making money. I don't know. Some of those companies are just, you know, whatever, but whatever the number is Principle number one.

Speaker 1: 46:07

the customer matters the most.

Speaker 4: 46:09

Right.

Speaker 1: 46:10

And they center everything they do around it.

Speaker 4: 46:11

They care about. They're optimizing for it in some way, and I don't know. Maybe in the oddball there's a better explanation than that.

Speaker 2: 46:23

Something that was mentioned earlier. Right, the ways of working, terminology, if you go like. Google has their way of working, amazon and their different areas have their way of working. We all know the Spotify model. Right Book came out. Spotify model it works in some cases, not in others. And then recently there's the whole conversation around. Well, even the Spotify people say the Spotify model is not one for all. Right, these big players.

Speaker 2: 46:47

We got OKRs mostly because Google really adopted the heck out of it and it got a broader reach right, these orgs are very agile in pockets and then they're not in others where they don't need it, just like you said. So I don't think they need to stand up and trumpet it because they do the Google way of working and they're very internal with it. And you know, amazon has their way of working and all that. What we see mostly at these conferences is people that are in this under the Agile banner for some reason, some reason or other.

Speaker 2: 47:17

I'm there because I like supporting organizations with business agility and I've done this so long in the dev capacity up to where I'm at now, and I really truly believe in the core principles when done right, like there's a reason, agile exists. I wish we had a conversation about where it came from and whether it scales like we want it to and things like that. But the core of it's good and I meet great people like on this call, and there's always during those conferences some conversation that lights my brain up and I hear something I haven't heard before. I think the big thing companies they have their ways of working and then we get the books, we get the result, we get it spread out to us when they get something really successful. But they've got their own internal thing that they're huge and they're doing this stuff every day. But a lot of it is very agile. It's just under their banner, their brand.

Speaker 3: 48:07

What does that mean?

Speaker 2: 48:08

to be under your brand or banner. Spotify model Great example of it, right? Well, that's a method.

Speaker 3: 48:14

Here's where we get to Like is agile a method? Right, that's yeah.

Speaker 4: 48:20

Good point, good point, excellent point.

Speaker 1: 48:23

And copy-paste syndrome right? Good, good point, good point, yeah, excellent point, yeah. And copy paste syndrome right, we, we want to copy paste what we've seen. Uh, one of the banks I did some work for when those videos came out they wanted to implement the spotify model, so they printed out the posters, they made everybody watch the videos. They did a town hall and the first question the cio got asked was uh, so are we going to be allowed to wear jeans now? It was such a leap from where they currently were at.

Speaker 1: 48:46

But I think people missed that it wasn't about fancy labels, it was about structural changes and a lot of companies. You guys have probably seen the same thing. We're not a development team anymore, we're a squad, qa squad, a development squad, a project management squad. Because it looks so simple and easy on the outside. And then when we bring it into our organizations, it's like well, we can't cross, collaborate across these vertical dividers and silos in our organizations for these reasons. And then we realize, oh, it's kind of our HR stuff, it's our performance management, it's the way we do, it's the way we have product team or project teams aligned around products and matrices, and we learned that those things are largely invisible and very difficult to change. But it's very easy to bring in a process model and make a presentation and make a flow chart about how you'll follow the process and we kind of just bounce that and the argument I have with that a lot of the times is maybe these organizations don't need to actually change how they do work, so maybe it's not working for them because they don't actually need it.

Speaker 1: 49:50

You know, and I know I do pick on the banks in canada a lot, but it's an ogleopoly up here, the big five yeah, you could say the big six, depending on the day. They don't really need to out compete each other to a certain degree. They just need to protect their ecosystem and they all do the same thing. It's all circular. So when they have been running these transformation programs for the last 15, 20 years every 12 to 18 months, um, they're not entirely necessary. They optimize their process a little bit every year and it does get a little bit better. But they still use transformational language, which I think sets the expectation. When I come in as a coach oh, you want mindset, you want behaviors, you want beliefs, and then I start acting that way and I realized that that's not really what this system is capable of at the time or needs right or needs yeah.

Speaker 1: 50:42

Yeah, like I mean you've probably seen this in maybe more conservative organizations that have less um, uh, less mature technical practices and you start showing them a few tricks here and there and it blows them away. I showed a development manager a simple way to do some some automated testing for some complicated thing that we were doing. And, uh, they've just never been exposed to this stuff because they haven't needed to in their system, right, and then once they see it, they can start doing little things here at kind of the team level, and then another team notices and they start to spread things more organically, but the whole system itself is still going to be a conservative, a more conservative organization.

Speaker 1: 51:24

So I know we're kind of getting close to the time box.

Speaker 1: 51:29

What I like about the sessions everybody has, there's a theme around uncertainty. For all of them, you know you're talking about John, you're talking about metrics, chris, you're talking about forecasting and managing uncertainty in that way. And Quentin, you're talking about dynamic teaming and more self-management at the team level, and I think these are really the core things. We're not talking about how to be okay with uncertainty and just embrace it, but more what are some tactical things we can do to manage it, which I think is much different from the language that has been coming out of Agile forever, which is just embrace uncertainty. I'm like, well, no, you jump off the cliff first. I don't want to do that, but these are very specific tactical things that say we can't predict the future. But here's some things we can do to make sure we build guard rails so we don't fall off the side of the mountain. Do you guys want to each give a little quick description of your talk and why you think it's a really good time for the agile community for these talks?

Speaker 4: 52:32

Yeah, I can go.

Speaker 4: 52:33

So I'm talking about using forecasting, a different method for effectively estimating work.

Speaker 4: 52:41

I mean the industry industry we're in where people hire us to real software projects turns out they actually care how much something's going to cost and when it's going to be done, and they care that it's fairly accurate, right.

Speaker 4: 52:54

And so I tell people that like this, this method or these methods aren't, aren't, aren't better, because the math is better, like the math works, like the math always works. But they force us to ask different questions and they help us model and talk about uncertainty in different ways and in doing so, creates a level of transparency and, to start with our customers, and to be able to answer questions like well, what if we add more people, or what if we reduce this, or what if this risk was materialized, or what if we could reduce the impact of this particular? Then you can start to ask better questions that hopefully lead to that ultimately better decision. But if you're going to manage or deal with uncertainty and being able to predict the future, I think forecasting helps you understand what that future uncertainty might look like and gives you some levers for for making some, some adjustments Right and making decisions. It's not about the math path. It's more about a communication device to help facilitate better conversations around when and how something will be delivered, how long it'll take and so forth.

Speaker 4: 54:12

And so, jason, you sort of said it, but it's also a simple trick, it's pretty easy. There's some very simple just spreadsheets and there's lots of other tools that people have out there, but it's completely changed the way we do business and it's changed our clients. They love it, and so I think it's a great time to sort of step back and reflect on how agile sort of fits into this and this notion of like being able to sort of, I'll say, predict the future why it matters and maybe how to do it a little better than we are today.

Speaker 1: 54:55

Yeah, I love that. We want the ability to make better decisions with data sooner, and any project I've ever worked on whether it's a small company or big company the sponsors or stakeholders or the people paying for it they hate last minute surprises more than anything else, and the more we can get in front of that with predictive models. That aren't going to be perfect, necessarily, but giving us enough good information to make decisions based on how our current reality is, I think, is a fantastic topic. Quentin, did you want to talk about your self-selection session?

Speaker 3: 55:31

Yeah, 20-ish years ago, there was a group of people that said we are uncovering better ways of developing software by doing it and helping others do it. And that's what I'll be doing is sharing something that we uncovered. So it's not. We never stopped Like we should continue to try new things, uncover new things, not to say, hey, this thing that was invented 20 years ago is the one way of doing things. There's new things and I want to share some experiments um, that that I've done. Um, in particular, it set out to say, solve a lot of the pain that comes with heavily siloed teams, so with static teams. That creates issues like dependency management is is is a challenge. There's ways of solving that and, uh, I started experimenting with using open space as a basis of a way to solve that. So I'll be sharing that. The business problems it solves, as we said, is dependency management, increasing resilience, adaptability and also in including product management, the process of product management, as well as discovering and delivery altogether in one combined process. So that's what I'll be sharing.

Speaker 1: 56:52

Very cool. I remember, chris you mentioned we were at LSSC many, many moons ago. I remember Alan Shalloway. I had a conversation with him. He did a session, something around here's. Here's how we did things in a smaller organization. You know, we we'd put the work in a basket and then people would walk up to the basket and, yeah, let's take this, I'll take this, these three people will go do this. I think that scares the hell out of people in organizations because you you get the feeling of loss of control. So I think it's a great session to show people that there's, there's ways you can put this in place and still protect your budgets and still protect it from being the you know the wild west and stuff. But uh, I I. It reminds me a lot of um, um. What esther derby says is organize people around the work, and the people who are doing the work best know how to organize it, and I think that's a really strong message for folks as well. John, you want to talk about your metrics session?

Speaker 2: 57:55

Yeah, I'll make it a quick one when this came from. A few years back I was working with a CIO of a very large company and on his metrics he wanted to see team velocity increase 20% every three months. He wanted to see that velocity go up and my response to him was well, that's really easy. We can increase velocity tomorrow. We'll just have everybody estimate things differently. And it's that mindset.

Speaker 2: 58:19

With measures, unintentionally, we've got organizations putting in measures that actually hurt productivity, that hurt their people, that hurt their organization, and now, with AI, we're automating a lot of that. So we're breaking organizations and people faster than ever. So throughout the course of my career, and especially the past several years focused on measures, I've started thinking of it in terms of adverse impact mapping. It's an HR term adverse impact. You make a reasonable change here. It adversely impacts a population of your organization and you want to measure that, so you don't allow that to happen.

Speaker 2: 58:56

I want to help people understand what a good data insight and measurement looks like. So how do you get there? Not the broken OKRs we see nowadays, where everybody's just kind of slapped out things as OKRs, but how do you get to something meaningful that's going to be insightful. How do you measure the impact of that measurement on the org? The way you're measuring, what you're measuring and how you're measuring changes your org and it can really hurt people downstream.

Speaker 2: 59:18

So providing some tools, toolkit, actionable it's a little bit of philosophy, but it's mostly how do we do this? Hopefully people walk away with the templates and toolkits and can start doing that in their org. One of the big problems I've seen with the agile measurements lately is, at the end of the day, they disrupt agility by trying to measure it in the wrong way. So trying to help people with some tools to get them through those conversations, whether it's with the CIO, the project manager, the scrum master you know how do we do this, why are we doing this and how we make sure it's not hurting people in the process.

Speaker 1: 59:50

Oh, that's great. That's great, yeah, things that really speak to the people who want those measurements, as opposed to the things that are important to us. You know it's people. I find it's hard to really have empathy for the people at the top who are asking for measurements that we might not call agile measurements, but I think we need to understand what it is that they actually want and we have to understand. You know one of the banks again on a big HR project where the director was like agile will never work here because of these reasons and how we're measured for these things, and it basically came down to he wasn't willing to take the risk to try something different because they were responsible for payroll for 80,000 employees. So it was well then, let's just not force it. So, yeah, any final thoughts? I'll probably see all you guys there.

Speaker 3: 1:00:43

Tell us about your session.

Speaker 1: 1:00:45

Jason.

Speaker 4: 1:00:46

Yes, I'll say Jason, what are you?

Speaker 1: 1:00:47

talking about you guys. Remember the Iomega zip drive. Yeah, yes.

Speaker 4: 1:00:52

I do.

Speaker 1: 1:00:54

Would you devise an enterprise data storage strategy around the Iomega zip drive?

Speaker 2: 1:01:01

I think the answer is no I think the answer is no I'd have to hop in my delorean and go back to a time that that was a real question. Yeah, 1995 called.

Speaker 1: 1:01:11

They want their change framework back because we cling to these pre-internet approaches for change, which is very serial, waterfall driven. Let's go plan a transformation for six months, let's unleash it on the organization and then the context has changed and it's basically do. What we were talking about on the call is we already have all the things we need to do. Gather enough insights this week, so you have a snapshot of your current reality. Pick the top three things that you need to work on to move the needle one step forward. Make your diagnostics and measurements, try it, see what happened and do that on a cadence that makes sense for the context of your change. So it's really I see a lot of agile folks kind of starting to look into the change space and vice versa. A lot of change folks have been poking around in the agile space and there's really good things on both sides that I think we can learn. To simplify how we approach change. Let's not make it a gigantic big process, because now we've got another complication in how we do things. So I'm going to share a bunch of the six big ideas of adaptive organizations and different strategies and metaphors for how we can understand what is it that we actually want to do when we talk about bringing change in and adapt it, to adapt how we do it to our context, as opposed to just picking a set of steps, um. So, yeah, that'd be great, it'd be. It'd be great to catch up.

Speaker 1: 1:02:35

I haven't been to, uh, grapevine since it was agile 2012, when they last did it at the texan. I can't remember. I did a session with like a long, long time ago and I think so, yeah, it's going to be. It's going to be fun to come back, provided the border services in canada isn't on strike because I might not be able to get in or out of the country. But, uh, so for those folks listening, everything we mentioned, if there were links or urls or anything, check the show notes for those. And to to close us off, if you had to say something in the size of a couple of tweets about this whole Agile is dead thing, what would you say? I know I'm putting everybody on the spot.

Speaker 4: 1:03:17

I don't know the thing that keeps coming to my mind. If somebody said to me Agile is dead, I think I would want to respond with okay, so now, what, like, what, what, what are we going to do now? And um, how are you going to know it's working?

Speaker 2: 1:03:34

I think for me it's um, if you're telling me agile's ted, you've got to define agile, because agile, as a movement based on the truth that it was that, can't die. You might relabel it, but it can't die. So if you're telling me it's dead, define, define what you're talking about I'll say that.

Speaker 1: 1:03:55

I'll say that it's all noise. I think it's. I think it's mostly noise. I went to an entrepreneur conference which I don't even think we use that term anymore many, many moons ago, and one of the adjunct professors at University of Waterloo said in 50 years from now I'll be dead unless my students can figure out how to put my head in a jar. You'll still be talking about this, but you won't call it entrepreneurship anymore. It'll be whatever people have latched onto, but you'll be doing the same things. So very much what you said, john. It's not about the thing that you call it.

Speaker 3: 1:04:31

It's about how you choose to learn how to think in your own context. I'm going to steal a quote from Marty Kagan's book Inspired. I have no doubt that many people and teams are, in some measure, disappointed with the results from their adoption of both lean and agile, and I understand the reasons for this. That said, I'm convinced that lean and agile values and principles are here to stay, not so much the particular manifestations of these methods that many teams use today, but the core principles behind them. I would argue that they both represent meaningful progress, and I would never want to go backwards on those two fronts.

Speaker 1: 1:05:09

Excellent, good way to close off that part. So wrap up. Thanks everybody for joining. I'll reach out after the conference as well. Maybe we should do like a post-Agile 2024 and share what are some cool things that you learned. But thanks for taking the time to join everybody and share, like, what are some cool things that you learned, but thanks for taking the time to join everybody, everybody else listening show notes. Head over to thatchangeshowcom or leanchangetv if you want to see the video versions thanks, jason, appreciate it, appreciate everybody, thank you.