Most agile transformations start with energy, and then stall out when things get complex. In this episode, Mike Cohn returns with a practical framework to help teams and leaders spot what’s missing, build lasting momentum, and navigate change with more clarity and intention.

Overview

Agile isn’t just a set of practices—it’s a mindset shift, a role shift, and a culture shift. And without the right support, even the best-intentioned transformation efforts can lose steam. In this episode, Mike Cohn joins Brian to walk through his Five Pillars of Agile Transformation—a practical structure for guiding change that actually sticks.

Whether you're leading a single team or rolling out agile across the organization, this conversation will help you focus your efforts, spot common gaps, and use agile principles to strengthen your transformation from the inside out.

References and resources mentioned in the show:

Mike Cohn
What Happens When One of the Pillars is Missing Graphic
The Five Pillars of a Successful Agile Transformation by Mike Cohn
#102: Communicating Agile Transformations with McCaul Baggett
#110: Overcoming Organizational Dysfunctions with Lucy O’Keefe
#152: The Five Pillars of Real Agile Improvement with Mike Cohn
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

• Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
• Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com

This episode’s presenters are:

Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.

Mike Cohn, CEO of Mountain Goat Software, is a passionate advocate for agile methodologies. Co-founder of Agile Alliance and Scrum Alliance, he thrives on helping companies succeed with Agile and witnessing its transformative impact on individuals' careers. Mike resides in Northern Idaho with his family, two Havanese dogs, and an impressive hot sauce collection.

Auto-generated Transcript:

Brian Milner (00:00)
Welcome back everyone. We are back for another episode of the Agile Mentors Podcast. I'm here with you almost as always, Brian Milner. And today I have the one and only Mike Cohn back with us. Welcome in Mike.

Mike (00:15)
Brian is good to see, I think you are here always, aren't you? Have you ever like called in sick for an episode?

Brian Milner (00:18)
Pretty,

well, pretty much. We did have the one little segment of time here that we kind of had the takeover with Scott. Yeah, so that's the only gap. Otherwise, it's been me along for this journey. We wanted to have Mike on, because Mike's been working on some stuff recently that we both have been kind of doing some work with individual clients and, you

Mike (00:26)
Yes, Scott took over.

Brian Milner (00:40)
talking about helping people make the leaps, the transitions that need to happen. And Mike's kind of developed a framework around this really based on a lot of the writing that you did back in your book, right?

Mike (00:54)
Yeah, a lot of this goes back to leading transitions since about 2008, significant size transitions.

Brian Milner (01:02)
Yeah. Yeah. And it's, you know, the, the, thing that people I think often don't understand is that the, these kinds of things, you know, when, organizations come and meet with you, they, they often think, we, we must be really unique and, you know, have something that no one else has ever had before. But then at the end of the day, it turns out they're all pretty similar. They all pretty much have the same kind of, things that they're struggling with. And, and so there are patterns that you can put in place to help.

do this in a successful way. And Mike has this pattern that he has put together. And one of the things that I know I believe in really strongly, learned this from Mike and others as well, is that when you are trying to guide any kind of change effort like this, especially if it's an agile change effort, that it's really useful to try to use these agile practices in becoming more agile.

And one of those is a transformation backlog. So for the people who aren't really familiar with that term, Mike, or what that means, or what it would look like, or why it's better than another way of doing this kind of thing, what's important or special about a transformation backlog?

Mike (02:09)
Yeah, good question. I want to comment on the uniqueness thing because you made me think about that a little bit differently the way you described that. you know, I think we both agree. mean, every client is unique, right? But I think what makes a good consultant or even a good coach is discovering patterns and looking for the patterns that apply. so, you know, we rarely see exactly the same situation twice with two different companies or even.

two different teams. It's not exactly the same, but you can draw on that experience. go, I've seen this behavior over here. Here's what kind of worked. Let me try something similar here. And so it's noticing those, those patterns. And I think that is what led to kind of the way I think about agile initiatives, right? And how we get better. And you're right. A big part of that is using agile to get agile, right? We don't want to.

You know, don't want to have a Gantt chart of how to get agile, right? That would just be a complete impedance mismatch. So, a big part of that for me is the backlog, right? I backlogs to me are, I wouldn't say they're like the most important thing about agile, but they're kind of the most in your face thing about agile, right? I mean, you know, what are we going to do, right? You have at least a little list of what you're going to do. And so backlogs are pretty...

Brian Milner (03:05)
Hahaha.

Mike (03:31)
prevalent thing. And so I like working with organizations and creating what we refer to as an improvement backlog or transformation backlog. But it's a list of the things that you want to get better at. And you load that up. You know, at the start, you can think of things that just kind of naturally are going to be there. Like how do we train our coaches? How do we identify who are good scrum masters? Those are going to be, you know, part of the pattern that pretty much every organization is going to have.

But then you look for specific things within a team or a company and you come up with specific improvement ideas to go on that backlog.

Brian Milner (04:07)
Yeah, I agree. It's always been something I've tried to do as well. I think it's, you know, one of things I love about it is that it's mirroring what you expect to see from them. And I think it gives them that ability to have that transparency into what's going on. It's not a black hole, right? And they know where things can go when they have something that they feel like needs focus. So for all...

Those reasons, a lot of others, I agree that I think it's the right approach to take. I know that in trying to come up with things and identify areas to work on, you've kind of come up with this approach of five pillars and I love them. I think they're great. I think they really kind of highlight the different areas that things can pop up in. I wonder if you might just...

talk us through one of those pillars and tell us what the concept is behind it.

Mike (04:55)
Yeah, I think it fits into that whole idea of, you know, seeking patterns, right? And, know, you might have a hundred things on your improvement backlog, but who wants to read a list of a hundred things? So you naturally kind of want to group them. And so, you know, for example, this grouping of things might be part of what we refer to as the mindset pillar. And, you know, you, you really, I don't think you can be agile unless you have a cultivated agile mindset and.

You have to, you have to think in an agile manner so that you're approaching a team does have to think in an agile manner so that they're approaching problems and situations and going to add it with an idea of inspect and adapt and small increments and thinking about it that way. And if we're not thinking in an agile manner, it's going to be, you're going have a really hard time of, getting agile later.

Brian Milner (05:47)
Yeah, I agree. would you think of mindset as sort of being the first in the list, the top of the list, or do you see these as kind of all equal?

Mike (05:55)
That's interesting. I guess they're probably all equal in that if we, if we fall short with any one of the five pillars, I assume we'll talk about all five of them, if we fall short in any one, we're going to have problems, right? And I do always think of mindset as the foremost among them. Don't know if it's the most important, but it's often the hardest to create inside of an organization.

just to kind of mention the second pillar and we can talk about it more later, but just to mention it kind of in contrast is practices, right? And, you know, we can have a team that goes through the practices of, of agile and they, they do a daily meeting and they have a backlog and they do a review and they plan their retrospect and, they do all those things, but if they haven't really internalized it, right? mean, from the outside, they look agile.

But at the first sign of trouble, do they stick with agile, right? If they haven't really cultivated that mindset. And so I think practices is an important pillar. It's the second one that I always list, but you know, it is a little bit subordinate to mindset. have to have that agile mindset. Or I think when times get tough, the practices don't stick. ⁓ You'll remember the old, the capability maturity model, the CMM, CMMI.

Brian Milner (07:15)
Yeah.

Mike (07:20)
Um, you know, a lot of questionable stuff in there, but one of the things I loved, absolutely loved this about CMM is they had level one, two, three, four, five, and level two is where you defined your process, right? You just, had it written down. You knew what your process was and level one was just kind of chaos. You just really just kind of ad hoc development. And what I loved is they said, you know, you're truly at level two when a crisis hits and you stick with it.

Brian Milner (07:49)
Hmm.

Mike (07:49)
Right.

And, you know, I think about that with agile and like, if you believe in, um, daily meetings, just as an example. And a crisis hits, you don't go, Oh crap, we're too busy to do those daily meetings. Let's skip that junk. Right? No, those daily meetings, those daily synchronization points, whether they're a meeting or Slack check-ins these days, but having that synchronization point every day is valuable. And if you truly believe that you don't give it up when a crisis hits.

Brian Milner (08:05)
Yeah.

Mike (08:19)
You know, you may say, let's do it at two o'clock because my head's in this thing right now, but you don't skip it. And I kind of, I kind of learned that from the CMM, that that was an important thing that you've really, you've really arrived at a defined process when you don't give up your process in a crisis.

Brian Milner (08:34)
Yeah, no, that's a great point. And I like how you frame that with mindset and practices. I agree. It seems like sometimes people start with the practices and feel like that's the entirety of it is just, let's get people trained on where you have this meeting and then we have this meeting and then people show up for it and think, well, why are we here? They know what they're supposed to do, but not why. And that kind of speaks to that mindset pillar that you...

address there. So that's that's great. ⁓

Mike (09:02)
Well, I know you're a, you're a movie fan and you know,

this is an interesting debate that's lingered in agile literally since the beginning. I remember these debates back in 2003 at conferences and it was the karate kid debate, right? Um, you know, think about, you know, the credit kid, he's just waxing the car all day. He's just doing the practices, right? And all of a sudden he can magically fight. If I remember the movie correctly, right? Um, don't know that it really works out that way, but, um,

Brian Milner (09:20)
Yeah.

Mike (09:29)
You know, if you have a team that's just waxing on all day, you know, they're doing all the practices. They never have any idea why they're doing those. Mr. Miyagi said to, right. ⁓ you know, agile coach Miyagi told me to do this. are they, are they truly agile? Right. And that's been a debate about, you know, about agility since the beginning, right? If they're, if they're doing all the practices.

Brian Milner (09:38)
Ha

Mike (09:50)
Can't say they're not agile, right? But to me, it's, they won't stay agile when a crisis hits.

Brian Milner (09:52)
Yeah.

Yeah, yeah, that's a great point. Well, let's keep building because we talked about mindset and practices and I know there's five of these. What would be the next thing to build on apart from mindset and practices?

Mike (10:06)
The next one for me is roles, right? Roles.

And there's really kind of two categories there. There's the new roles that Agile introduces, where we'll often have a product owner. We might have a scrum master or Agile coach. But then we also change roles, right? know, developers, and I use developers to mean anybody on the development side of the problem, right? So programmer, tester, analyst, database person, designer.

The developer's roles change, right? They have to become more holistic. They're never going to say that's not my job, right? They're going to do whatever they can to help out. And so when we introduce Azure, we have to clarify the new roles and we have to be clear about the changes to existing roles, right? What changes? Maybe we don't have a product owner, but the product manager now has to be more involved day to day with the team, if that's how we go. And so there's that.

change roles and the new roles that we have to introduce.

Brian Milner (11:04)
Yeah, because everybody wants to know who's responsible for that, right? mean, and so you can get into these kind of back and forths on do we need a racy chart? Do we need all these other things? What's your opinion when people kind of bring that topic up?

Mike (11:18)
You know, so many people in Agile are opposed to racy charts and it's like, get the point. I can see the value to doing that as long as you don't take it too seriously. Like I don't, I want to go through the exercise of creating it, but then I kind of want to throw it away and I don't want to look at it anymore, right? But the discussion, the argument about who does this, that type of thing can be useful. The example I used to love sharing in classes was we

Brian Milner (11:33)
Yeah.

Mike (11:44)
I'd always get in teaching a class. I'm saying who's responsible for the product backlog. Right. And I was used to like to counter that with an example of I have two daughters and they were much younger when I was first teaching. And I would say, well, you know, who's responsible for my daughter's becoming a productive member of society. Right. you know, is it my daughter herself? Is it, my wife, their mother is it, is it me? you know, who is it? And, know, people would get the.

would get the concept say, well, you know, it's all of you. Right. ⁓ and I would choke and say, no way it's my wife. Cause I'm out here traveling to teach this from class, but, you know, it's, it's clear, right? It's, it's everybody's responsibility. It's the kids, it's the parents responsibility that the kid grow up to be a productive member of society. And you know, who's responsible for the product backlog? Well, everybody is right. mean, you know, if the team members look at and go, man, product owner has been too busy to.

Brian Milner (12:14)
Right.

Mike (12:38)
You know, to refine these backlog items, I'll do it. Right. Everybody should help out, but primarily who's responsible? Sure. Let's say the product owner. So I'm not opposed to racy charts. just don't want to take them too literally. And I don't want to, I don't want to have the language lawyers pointing to it and go, you know, says you're supposed to do this. Right. And you haven't.

Brian Milner (12:58)
Yeah, yeah, I agree. I think there's something that comes up in classes sometimes where, you know, we'll be talking about who's responsible for one thing or who's responsible for another. And students will throw out, well, but couldn't anyone do that? Like, let's take writing user stories, right? Couldn't anyone write a story and have it go in the back? Oh, well, yeah, they can, right? Anybody can add things to the backlog. So I often think about it like with the word ultimately, who's ultimately responsible for it. If it doesn't happen,

who is the person that should have stepped up and made sure that it happens.

Mike (13:31)
Yep. But then we get into the, I do think of myself somewhat as a writer, even though I don't write that as much anymore, I think of myself as a writer. And so I should care a whole lot about words, but then we get into like, well, this person's responsible and this one's accountable. And was like, oh, my head's spinning.

Brian Milner (13:50)
Right, right, exactly.

Mike (13:51)
Who does

the thing? Right. And I think about my, my old, old, old boss way back early in my career, who always referred to the one throat to choke, right? You know, who do I get to go yell at if something goes wrong? Right. It was like, okay, I guess that's the accountable person, but I don't know. mean, there are differences between accountable and responsible, but I always have to stop and think about, okay, which, which means this, which means that. And if you got to stop and think about it, it's too hard.

Brian Milner (13:58)
Yeah.

Right?

Yeah, yeah, I agree. All right, so we got mindset practices roles. What we build after where do go from there?

Mike (14:25)
Yeah, there's two more. The next one I'd say would be teamwork. And, you know, we're touching on that a little bit with the roles. Team members are going to interact with each other differently. And that's one of the pillars of a successful Agile initiative is improving teamwork. We're going to be interacting more closely with one another. We're going to be interacting more frequently. We're going to be sharing responsibility, what we're just talking about. And all of those are changes.

for team members. not going to be necessarily supportive on an agile team of the person that says, you know, give me two months, I'll go in, I'll build this thing and I'll come back and give it to you perfectly. And I've seen that, I've seen that work, but not really on an agile team. And so we changed teamwork and that'd be the fourth pillar.

Brian Milner (15:11)
Okay, so teamwork. So mindset practices, roles, teamwork. And then what's the final one?

Mike (15:15)
The last one is outside the team, right? And so, you know, I didn't want to really kind of call it culture because that's a little too big and too fancy, but it's everything outside the team, right? It's going to be hard to have a successful Agile initiative if those outside the team are impacting the team in, in certain ways, right? If you've got a sales group out there making promises about dates and commitments, it's hard for the team. If you have.

any sort of leader interrupting the team constantly and not understanding the impact of that. Totally fine to interrupt the team, but you better understand the impact, right? And then, and then choose to take that impact. So, but if you have these outsiders behaving in non agile ways, it's going to impact an agile initiative. And that's really what these pillars are about. They're about the five things that we need in order to have successful agile initiatives.

Brian Milner (15:50)
Yeah.

Yeah, I love them because they're systematic. It reminds me of the old Ishikara fishbone diagram root cause analysis of how you think systematically through different ways of what might be the root cause of the problem.

Mike (16:27)
Yep. Absolutely.

Brian Milner (16:27)
⁓

Now, you talk about using these as a way to connecting back to what we talked about earlier, the improvement backlog and ways that we can sort of start to use these to generate those items that might go into our improvement backlog. I'm wondering if you can, do you have a practical example of that or can you demonstrate for us how that would actually work?

Mike (16:47)
Sure, they're really thinking tools, right? So if you notice a problem with a team, it's useful to ask yourself, are we seeing a problem with mindset? Nope, nope, that's okay. Are we seeing a problem with practice? No, team's doing okay there. Is it a problem with role clarity, right? Is it a problem with teamwork or is it a problem with outside influence? And so think about the five pillars and that will often help you identify a

way to, to fix the problem. Right. then the way to fix that problem that goes on your improvement backlog. And so as an example in this, I'm thinking of a very specific company I worked with, but you and I've both experienced this countless times would be, a team that is struggling with kind of what is agile. Right. And, know, they're not using it the same way inconsistent use of terminology and

You know, one team might think two months sprints are okay. Another team is doing one week sprints. I, the, team I'm thinking about actually had a difference. They were using the term sprint and iteration. And I've already mentioned that, you know, despite being a writer, I'm not that big of a, of a word purist. And so the first day or two that I'm with this company and they're using sprint and iteration. Both doesn't bother me. So some people have different preferences for words. No, no big deal.

but then we're in a meeting and somebody said, well, that's what we do during an iteration. It's totally different during a sprint. I'm huh, aren't they the same thing? I thought you guys reason them the same way. And they said, no, no. An iteration is when we're working at a sustainable pace. A sprint is when we have to work overtime, right? It's like, actually that's a pretty good distinction, right? I kind of like that, right?

Brian Milner (18:26)
Aha.

Yeah, right.

Mike (18:34)
You know, I'm running at a sustainable pace for the first 26 miles of a marathon and I'm sprinting for the last point two to, you know, to beat the guy next to me that I've been running next to for five miles. Right. And so, okay, sprint mid sense. And so what we decided there is that we needed to put an item or two on the backlog. And these would be in kind of in the mindset category of improving kind of our definition of what is agile. Right. And so.

do a little bit of kind of fundamental training, just some vocabulary, things like that. Hey, when we use these words, I mean this and, you know, here's some guidelines. Let's not use two month sprints. And so we had to get a little bit more in the mindset of what is agility.

Brian Milner (19:14)
I, I kind of want to throw a curve ball here a little bit at you. Cause I know, you, you talk about this as being the backlog. and a backlog has a team, right? A backlog has someone who's doing it. So I just, I wonder if that's a question in people and listeners minds here. Well, who's actually doing this? Who's actually carrying this out? If, if you need to clarify, you know, the difference between a sprint and iteration.

How you know who's who's who's the person who's doing that or who's the team that's doing that? So so whose backlog is this?

Mike (19:45)
Yeah. Great question. I tend to think of an improvement backlog as being kind of like a recursive idea. So a team will have its own improvement backlog. Now I'm not trying to make agile any harder than it already is. Right. I mean, a lot of teams will have a refinement backlog. Right. And, you know, it's just, you know, it's often just a word document or something of Google doc, right? Hey, here's eight refactoring. So I want to do when we have time, right. It's no big deal. Right.

or they are things in their main JIRA product backlog and they're tagged with refinement or refactoring. And so these might just be in your JIRA backlog and we just tag them with improvement, right? And they're just improvement opportunities in there. And so a team will have its own improvement backlog and sometimes these come out of retrospectives. But if we're focused on a larger Agile initiative, right? We're trying to get an organization or department or a set of teams and project program Agile.

then we'll have an improvement backlog or use the term transformation backlog. We'll have more of that kind of master improvement backlog that cuts across an entire product. And let's say that's, you know, 12 teams or something. And so we'll have that improvement backlog. What I like to do then is to encourage the formation of improvement communities. And these are people who are passionate about improving in a certain area. And there might be a group of people who want to

get us better at automated testing, right? And so they form an improvement community. Another one might be about how do we get better at backlog management? And that might be about how do we, what are these job story things? Are they better than user stories? How do we get better at acceptance criteria? How do we start using AI to split our stories? And so an improvement community forms around those topics. And so,

I like to have leaders in an organization encourage the kind of ground up formation of these improvement communities that are passionate about subsets of ways to improve much better than saying, Hey Brian, why don't you go lead the improvement of this thing? And you're like, okay, but I'm more interested in that thing. Right. And so encourage these to, form from the ground up.

Brian Milner (21:56)
I love that. Yeah. it's sort of organic, you know, like when there's a desire that they form and when the desire fades away, then maybe the improvement community fades away.

Mike (21:59)
We did.

Yeah. Yeah. They should not necessarily be persistent. Some of them, you know, could last forever. The, um, at Google many years ago, there was an improvement community focused on testing. And, it was a very famous group. Um, they put out, um, a document about once a week called testing on the toilet. Um, you can Google this. was written up in the New York times. I think there's still a website that has a lot of the old, um, articles they would do. And it was called that because they would tape them up in the various toilets around the.

Brian Milner (22:24)
You

Mike (22:36)
Google headquarters and you could read them while you were on the toilet. And so, but it was about how, you know, how do you test something as big as what Google was doing? Right. And it was advice on that. And was written by a group of passionate people trying to help others test their subsets of Google's products. And it disbanded after a while, right? They, they existed for a few years, solved the main problem they were after and disbanded. And that's ideal.

Brian Milner (23:01)
Yeah, that's a great point. Because if you want to raise the visibility of that and it starts to populate around, then yeah, we've done our job. ⁓ I'm kind curious about these. If we go through this effort and we start to flesh out this transformation type backlog or improvement backlog, I'm kind of curious. Is it sort of a

Mike (23:12)
Absolutely.

Brian Milner (23:24)
project-based mindset with this that we put it together to get from A to B and then these disappear or is it the kind of thing where maybe this could be more longer lived that could go beyond just an initial change initiative?

Mike (23:40)
think it can be any of the above, right? I mean, we just gave the example of, you know, at Google with the testing community where it was across an organization, right? It wasn't tied to a project or product. It was across an organization. And I would say it was long lived and that it was a couple of years, right? But that it wasn't permanent, right? You don't want to institutionalize these things. So I think it's a little bit, you know, it's a little bit,

product focused, right? You what can our product do better? It's also what can our department do better? What can our organization do? And so that's what I was describing is a little bit recursive, right? You can have these improvement backlogs at different levels.

Brian Milner (24:19)
Yeah, yeah, this is is great stuff. And I think it's it's so practical because it gives you that roadmap that I think a lot of times people feel sort of lost when they start this this kind of thing and they think, gosh, there's so much there's so much to do. Where do I even start to make a dent? Well, we have an answer to that in the agile community, because that's what we do on a regular basis anyway. So I think this is great because it gives that that kind of ability to

be transparent about what needs to happen and follow a roadmap that you put together. Mike, if people want to find out more about this or want to go deeper on it, is there something that somewhere we can point them?

Mike (24:54)
Yeah, I'll give you a couple of links that you can put in the, in the show notes. And certainly, I mean, this is, um, kind of what we do at Mount and Goat Software. So you can contact us at mount and goatsoftware.com, but I'll give you a couple of links in the show notes. have a, um, a good diagram I can give you that you can link that shows, um, what happens if one of the pillars is missing. For example, if mindset is missing, you end up with kind of temporary gains, right? You know, cause you're not really going to be truly agile.

And so we got a nice little graphic that summarizes what occurs if one of the pillars is insufficiently supported.

Brian Milner (25:28)
Yeah, I'm wondering too, if you can maybe kind of describe for everyone, because I know, you know, we're, we do a lot of training at Mountain Goat Software, but we also coach, you know, organizations and help them through this. I'm just wondering if maybe you could talk a little bit about that marriage, a little bit of the training versus coaching and why, why they're both important.

Mike (25:48)
think training is the thing that gets the big ball rolling, right? And it helps kind of get things started. And one of our goals in training is to have people leave excited, motivated about something. And that's what I love hearing. It's nice when somebody says, I learned a lot, right? I learned things from that class. But I think I get more excited when I hear people say that they're motivated to go do something with what they learn now.

And so that's a part of what our training is trying to do. And, I stopped many, many years ago doing engagements with clients that just wanted training. would always do at least one day now, ideally more, but at least one day and I'd stay for a third day. We do a two day class on the third day. I'd get their team started because otherwise people hear this great stuff. They're motivated, but they're behind, right? It's like, no email backed up for two days. Right.

Brian Milner (26:38)
Yeah.

Mike (26:41)
And, you know, now they have to take a week to dig out of that email hole. And then they like, what did we learn a week ago? And so we always try to marriage the, or marry the coaching to the training, just to kind of keep the momentum going.

Brian Milner (26:55)
Yeah, I've heard a lot of tales of people who come through training and they, know, the whole company will come through, they'll get very, very excited about it. They even have sort of a debrief meeting afterwards where they'll get together and say, all right, well, what are all the things we want to do? Here's what we're to do. But then you're right. The next day, it's sort of the real world of now we got to catch up from all this stuff and we're back to just the old way of doing it because, you know, you can't just instantly

be in this new way of doing things, you have to transition.

Mike (27:27)
Well, it's right back to what we talked about with the, the, the CMM, right? You know, you're at level two and you stick with it, right? You know, you know, you're really starting to believe in agile when you stick with it. And if you go through the agile training class and you can't make time for it, you know, not, not unsurprisingly, you're not really agile yet. Right. And how would you be just got trained two days ago, but you know, you gotta have that, you gotta have that commitment to do it. Otherwise it doesn't stick.

Brian Milner (27:31)
Yeah. Yeah.

Yeah, yeah, this is such good stuff, Mike. I really appreciate you making time to share this with us. I hope everyone finds this really useful. like Mike said, if you wanna find out more about this, we'll put some links in the show note, contact us, reach out to us at Mountain Goat Software. can email hello at Mountain Goat Software. And we'd love to talk to you a little bit more about if there's a way we can help you on this.

Mike (28:14)
That'd be great. Thanks for having me, Brian.

Brian Milner (28:16)
Thanks, Mike.