Too many teams try to “do Agile” by adding layers of process before they understand the problem they’re trying to solve. In this episode, Brian Milner and Cort Sharp discuss how to start Agile simply, avoid unnecessary complexity, and build practices that actually fit your team.

Overview

When organizations first adopt Agile, they often make the same mistake: they start with frameworks, terminology, and process layers instead of focusing on visibility, feedback, and learning. The result is a system that feels heavy before it ever becomes useful.

In this episode, Brian Milner and Cort Sharp explore a more practical approach to getting started with Agile. They discuss why teams should focus on foundational concepts like transparency, short feedback loops, and clear priorities before worrying about scaling frameworks or advanced practices. Brian and Cort also share the common “drag factors” that slow Agile adoption down, including process overload, coordination complexity, and measuring the wrong outcomes.

If your team is trying to become more Agile without creating more bureaucracy, this episode offers a practical starting point.

References and resources mentioned in the show:

Cort Sharp
Introducing An Agile Process to an Organization by Mike Cohn + Doris Ford
Relationship between Definition of Done and Conditions of Satisfaction by Mike Cohn
Why Agile Teams Put So Much Emphasis on Being Done Each Iteration by 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.

Cort Sharp is the Scrum Master of the producing team and the Agile Mentors Community Manager. In addition to his love for Agile, Cort is also a serious swimmer and has been coaching swimmers for five years.

Auto-generated Transcript:

Brian Milner (00:00) Hey, welcome in Agile Mentors. We're back here for another episode of the Agile Mentors podcast. I'm here as almost always, Brian Milner. And today I have back with us ⁓ Mr. Cort Sharp. Welcome back in, Cort.

Cort Sharp (00:14) Hi Brian, thanks for having me on.

Brian Milner (00:16) Yeah, glad to always have Cort on. ⁓ If you haven't caught Cort in a previous episode, Cort is a trainer with Mountain Goat Software as well. ⁓ So if you do some work with us, you may see him in a class. You may also see him in a class. I teach sometimes, so I'll help out ⁓ and do that as well. So ⁓ we wanted to have him on because there's a topic area that's kind of come up about how to get started really with Agile. And well,

rather than me really spoiling it. I know this comes more from kind of a question that we've gotten from listeners or even from just in the classes as well. So Cort, why don't you set us up? Tell us what kind of the big question is that we've been hearing.

Cort Sharp (00:58) Yeah, sure. So I don't know if it's just, you know, the age of AI, everyone's starting their own company, everyone's starting their own business, whatever it may be. But this actually has popped up quite a few times, ⁓ both here at Mountain Goat and just in the web as a whole, the interwebs as a whole. ⁓ And it kind of boils down to one question, which is how do I start an agile process without over-engineering it right out of the gate?

Right? Do you just start with Scrum? Do you start with Safe? Do I grab one of these off the shelf frameworks and just run with it? Or is there something else entirely that needs to be done? ⁓ And I've seen it a lot. I know you and I both have had some experiences with introducing Agile into some companies, into some organizations. I know we've helped out with transformations. I know we've helped out with just enhancing the Agile framework or process as a whole.

in various organizations. And I can't speak for you because I don't know all your experiences, but I know for me, it's very rarely just, ⁓ Scrum's perfect for you. Or, yeah, let's do safe. That's no problem, right? This is the off-the-shelf solution that you're going to get for everyone. So I think we should sit down, we should chat about it, and figure out an actual pragmatic way and help everyone out with starting out with Agile here.

Brian Milner (02:23) Love it, you know I'm all about being pragmatic. So yeah, I'm definitely on board with ⁓ that approach. Yeah, I mean, I think kind of the big concept I would want people to understand is that don't get lost in the details. ⁓ Let me give you kind of like the worst case scenario. And I have encountered this worst case scenario in the past. ⁓ An organization that was just starting,

They did not have Scrum teams. They did not have any training that they had done previously. And the first thing that they decided to do as far as this transformation process was to have people trained in the Scaled Agile Framework. Now, please, if you're a Scaled Agile Framework person, I'm not ⁓ kicking the Scaled Agile Framework. But what I'm saying is the Scaled Agile Framework is built on top of Scrum. And this organization didn't know

anything about what a scrum master was or product owner or a sprint or anything. And now they're trying to learn what a release train engineer is and all this other stuff that is advanced beyond normal scrum. ⁓ So that's the extreme case, I think, right? Where we get so bogged down in the details that we ⁓ we launch into all of the definitions and we treat it like,

someone needs to pass a college exam in order to do this thing. And I think what I would say mostly is take a step back and ⁓ what Mike and I have always said is use Agile to become Agile. If this stuff is stuff you believe, then why do we try to introduce this new thing in a very different way than we're teaching people to actually do the work once they're in it? ⁓

Cort Sharp (04:07) Mm-hmm.

Brian Milner (04:21) So honestly, if I own my own startup company and I have a team of people, let's just say I have a team, a small team, 10 people or so ⁓ that I have as a Scrum team, or not a Scrum team, right? But I 10 people and we're getting to the place where I want to introduce Scrum. I'm not going to start by getting everyone...

Cort Sharp (04:36) You

Brian Milner (04:46) in the same place as far as terms and definitions and everything else, I'm honestly going to start with Agile. I'm gonna start with a mindset. I'm gonna start with the things that really underpin what we're trying to do and make sure we get on board with those things first. Because ⁓ if you don't, I mean, I come back to this over and over, transparency inspection adaptation.

Right? If I can get my team to understand we're going to make the work as visible as possible so that nothing's hidden. We're going to always dedicate time to figuring out not just how to fix the problem, but also why the problem actually happened in the first place. And we're going to do something about it. That if we can get into that mindset of whenever something goes wrong, we dedicate time to figuring out why and we change something.

then honestly, those three things together will ultimately lead you to the right practice. But I think that there's so much focus initially on, well, we got to learn all the practices. We got to learn all these, what's a daily scrum? We got to learn all these things that people, the team doesn't really understand why. What are you trying to accomplish in doing that? Why would we even do that?

And that's what leads to this approach that becomes more dogmatic than pragmatic of just, we're following the rules because that's what the rules say. Right. And I think that's really the key to it is trying to take a step back and say, look, we're not just going to follow rules. We're going to figure out what works for us. And we're going to apply that moving forward.

Cort Sharp (06:31) I like that a lot, that starting point of saying, hey, let's figure out what we're doing, why we're doing it, starting with why, really. I think so many people just want to jump into, I don't think, I see so many people just wanting to jump into, hey, this worked over here at this company, why can't it work for us? Let's jump in and let's do it. ⁓ Called out safe, we're going to stick with that, not to just, again.

Dog on safe all all episode, but I think it's I think it's one of the more common ones. ⁓ At least I see it a lot more frequently of yeah. We've heard of scrum. We've heard of safe where we're bigger than one team, so let's use safe and use that to scale our agile process or agile framework. And if you've ever looked at a safe diagram explaining the overview, the high level overview, it is a whole lot of stuff.

Brian Milner (07:00) Right.

Cort Sharp (07:28) And if you don't understand even why you're doing this, that whole lot of stuff is just gonna be noise, noise in your process, noise in your company, noise in your organization, and noise in your development cycle. And it's gonna stand in the way rather than help you deliver more value repeatedly, iterate, get better over time. So starting with why, I'm 100 % in agreement with you. And I think it is very much so. Let's understand.

we have to have a little bit of a mentality shift here too. It's not just, we just need to build stuff faster. No, there's so many things that can help you build stuff faster. You want to build better stuff faster. And if you can't grasp that, good luck. This is not for you.

Brian Milner (08:14) Yeah. Well, ⁓ and

let me just give a practical example here, right? Because I think just to make this day by day, ⁓ if you are going to start up a new Scrum team, ⁓ what do we got to do to get started? Well, we need a backlog. We got to have a backlog of stuff that we can start from. But here's where we start to diverge. Do you need a complete backlog?

Do you invest all your time in trying to get a complete finished backlog of everything we could possibly ever do? Or do you focus on what's most important to start on and then maintain it as you go? And that's the difference, right? If I'm going to implement this into a team, am I going to make sure everyone understands every possible scenario and every possible term and everything else before I can start? No, I'm gonna make sure they understand

what's core, what's basic. And then we're big believers in learning through experience. You have to get started. You have to actually experience what this is like. There's a big difference between book smarts on Agile or Scrum and experience in Agile and Scrum. And just like you wouldn't want a doctor doing a procedure on you that they've studied a lot but never done,

Right? You'd want them to say, no, I've done this a million times. ⁓ The same applies to us. You want the minimum amount to get started. And then you want to start the learning from just experiencing.

Cort Sharp (09:53) Yeah, I just continuously come back to kiss. I know you know what that means, but for anyone who doesn't, it's keep it simple, smarty pants. ⁓ We don't need to get too smart for our own good, right? ⁓ So let's just keep it simple. Like you said, when you're building a backlog, when you're just starting out on something, build, come up with the ideas that you think you can get going on right then and there, and over time.

Brian Milner (10:05) you

Cort Sharp (10:23) believe me, you will come up with way more ideas than you could possibly ever build. ⁓ I think Jeff Bezos, I saw some recent, it definitely wasn't a recent interview, but it's a recent clip that's been popping up on my Instagram feed for whatever reason. ⁓ But he was working with, early on in the days of Amazon, he was working with some consultants and one guy called him out and he said, Jeff, you have enough ideas to destroy Amazon. You have enough ideas.

to end Amazon. So keeping it simple right out of the gate is probably one of the best things you can do and focus on one thing. So actually, Brian, I want to throw it out there. What do you think is the minimum structure needed aside from, so let's say we have a mentality shift or enough of one, we have enough buy-in from leadership or just some small teams or something. Let's talk about kind of the structure that we need.

Cause I know my thoughts, but I'm curious yours and I don't want to influence you. So I want to know, want to know what you're throwing out there first.

Brian Milner (11:23) Yeah.

No, this is great. I love to compare notes and see what you think on this as well. But I mean, I probably boil it down. If I'm thinking minimum viable process, kind of a new MVP term, Minimum viable process. I'm thinking things, very simple things like ⁓ have a very visible backlog, right? Make the work visible so that everyone can have insight into what's coming.

Everybody can see the prioritization, right? It's not hidden, it's visible. So have a visible backlog. ⁓ Commit to short planning horizons. ⁓ Move from this approach of three months, six months or whatever, till we do something and shift that down to small iterations ⁓ a week, two weeks, three weeks, right? Have small little loops that you are gonna repeat.

over and over again so that you can inspect and adapt. So you can see how things went and then make changes. ⁓ shorten your planning horizons. ⁓ Get a clear definition of done. ⁓ I can't stress, overstress how important this is, but get everyone on the same page of what done looks like. Try to make it as strict as possible. I don't mean dogmatic. mean just that it is the highest level of doneness.

that we can actually accomplish. And I think you have to be realistic here, right? You can go overboard and say, well, we really want this to be our definition of done. Well, all right, how long will it take you to get any item done? that'll take about three months. No, no, no, back up, right? ⁓ You have to kind of think, well, what can I get done in a few weeks? What is actually, and when I say done, I don't mean a big feature.

I don't mean the stringing together of a bunch of different things. I mean any item, any small thing that you would do, what are the tests you would want to run to ensure that it was a high enough quality, that it's not going to cause problems, ⁓ that as Mitch Lacey kind of says in his classes, ⁓ that if you're a developer, you'd be comfortable releasing it in the worst possible time, Friday afternoon. If you feel like, yeah, I'm confident I can...

call this that level of done that I would be OK releasing this on a Friday afternoon. That's what we want to strive towards. So have a good clear definition of done. And then with that short planning horizon, just make sure that you have regular inspect and adapt loops in place, that you are inspecting and adapting on quality, you're inspecting and adapting on usefulness to your customers, to your stakeholders, and inspect and adapt on your process overall.

Because that's really the igniter, I think, that has to catch. It's like when you turn on the gas oven or gas stove and you hear the little spark that click, click, click, click, you're waiting for it to catch and the ⁓ flame to start. That's what that is for, think, an Agile team is that short inspect and adapt cycles because...

Cort Sharp (14:38) Yep.

Brian Milner (14:46) If you inspect and adapt your process in short segments, problems don't become big. Problems are always small because we handle the big things first and then as things pop up, as things occur, we address them right away because they're visible right away. We notice them right away. ⁓ So yeah, that to me is the key to, ⁓ you

turnover and getting it actually up and running to start to improve. But those are basic things. you notice none of those things that I say, make sure everyone understands the definition of this. Other than done, right? There's nothing, you know, there's no role, there's no anything else. I think that those cons, you can start very simple like that and then start to grow it. You can start to layer on top of that. But... ⁓

That would be to me kind of more of a minimum approach, minimum viable process. What about you? What do you think? Any differences?

Cort Sharp (15:45) I

don't disagree with anything that you said. Maybe a slight difference on that Inspect and Adapt. I would want to formalize it a little bit more so and say, we need to have at least three regular conversations within our team during that short iteration cycle. We just need to check in with each other daily and just know what we're working on. When we're done with something, when we've met our definition of done, let's get some feedback from stakeholders. So let's present it, show it, share it.

whatever it may be, and then get some feedback. And then we as a team also need to just sit down together and say, OK, what can we do better next time? And that's it. I would formalize that a little bit more so. So right aligned with you in saying, hey, let's inspect and adapt. Let's be transparent. Even as well, that's the daily check-in type thing. ⁓ But I would just want to formalize it there. And I think even to getting more into the basics, I thought it was funny that you jumped right into like, hey,

We need to have a backlog. need to go into short iterations. I think we need one, a team. So some people to build stuff, right? And it doesn't have to be a big team. can be one, two or three people, but I want that team to also be as stable as possible. Or I would love to see them to be as stable as possible. We don't want people shifting around all the time. ⁓ And then someone to just say, what is it that we're working on next? One clear voice of

Brian Milner (16:48) Yeah.

Cort Sharp (17:12) Priority right because we can have a backlog and I've done this I do it on my own personal projects I don't listen to my own priority orders and I jump down and work on whatever I feel like working on that day if we're not Having someone just say no we we need to work on this. Here's why I think we're also missing out a little bit there So maybe two technical things that I'm throwing out there that you probably assumed ⁓ But or should be assumed I should say

Brian Milner (17:35) You

Cort Sharp (17:41) But think that the clear priority person is the only thing that I would change there or add to it.

Brian Milner (17:45) There's, in

thinking about this topic too, I want to throw something out there to you and get your take on this. But I was trying to think of what are the things that really, what are the, what are the drags? What are the things that really slow the implementations down and really prevent people from being successful? So I came up with three things and I'll get your take on this. ⁓ One is what I just call cognitive drag. ⁓ Meaning that ⁓ sometimes an organization

or people will spend more energy learning the process than instead of actually doing the work. And that's one source of drag, I think. If the onboarding to the process takes longer than the onboarding of your product, that's a bad sign. I mean, that's a sign that maybe you're building more of a religion than actually a...

a useful process because at end of the day, the goal is product, right? The goal is something that is useful to our customer. So that was the first one was cognitive drag. The second one I thought it was coordination drag. ⁓ This is about the handoffs, the overlaps with other groups and how you coordinate across things. ⁓ Just kind of...

Cort Sharp (18:53) Yeah.

Brian Milner (19:12) ⁓ Do you have more dependencies, right? Then are your dependencies the thing that's really slowing you down? What's the source of that dependency drag? Can you reconfigure your teams in a way that makes there to be less dependencies? ⁓ That was the second one. And the third one, I was trying to come up with three Cs, but I couldn't. ⁓ The last one was kind of, well, maybe it's...

Cort Sharp (19:38) you

Brian Milner (19:41) I mean, it's false confidence ⁓ is kind of the way I phrased it. And what I mean by that is that ⁓ people often will put in place metrics and it's often performance metrics ⁓ that can give them a false sense of confidence that things are working when they're not actually working. ⁓ Maybe because they're using a metric that doesn't actually tell them what they think it's telling them. ⁓

but they kind of can get a false sense of confidence. And that's a drag because when you have that false sense of confidence, everything's going great. There's nothing to worry about. looks like, well, look at our metrics. Our metrics say this. Yeah, but are you measuring the right thing? And I'm much more interested in impact versus velocity, right? I wanna know if what we do, I could care less if we build

Cort Sharp (20:27) Right.

Brian Milner (20:39) half the things that we used to build. But the things that we build have double the impact of the things we used to build. If your customer gets something and they think, wow, that's amazing, that's so awesome, versus, hey, here's 10 things, but they're kind of meh, like they don't really do much for me. You haven't won. You win when you make a huge impact. So what do you think about? What are things that you think are kind of drags or things that might slow it?

Cort Sharp (20:57) Right.

Brian Milner (21:08) a group down from being successful in making this kind of change.

Cort Sharp (21:13) I agree with everything that you threw out there. And truthfully, the only thing that I would add is ⁓ change paralysis is what I would throw out there. We know we're making this change. If you're in the process of making this change, you got one change to go through. And in that one bigger change, there's probably a dozen smaller changes to you. You might be working with new people. You might be working on new things. You're definitely breaking work down differently.

if you're going into this realm of product process. ⁓ So just being aware of that and understanding, hey, we're going to go through a bunch of changes. Some of them right out of the gate probably won't stick and that's okay. But most of them, the ones that are going to stick, they're going to stick. So we're not going to change everything all the time. And we do want to be aware like constant change can take a toll.

pretty heavy-toll mentally and just even motivationally. I think it falls into your first C there of ⁓ the cognitive load of saying, look, things change. We're going to change. ⁓ You're probably not going to like it initially, but it will be for the better in the long run. So just think being aware of that and being wise, having some wisdom when approaching that.

Brian Milner (22:37) Yeah, it's the difference between teaching your team to overcome whatever the present change is in front of them and successfully navigate the change that's right in front of them or teaching them how to overcome and navigate change in general so that it doesn't matter whether it's this change or another change that's coming, but they'll be ready because we've used this as an example of here's what you do when you encounter this type of thing.

Cort Sharp (22:44) you

Absolutely. And I would even take it a little bit of a step maybe further, maybe slightly in a different direction. But I would encourage you to just minimize the change upfront. Again, back to, I like keeping things simple, Brian. Just keep it simple. I hate over-complicating things, ⁓ which so many people love to do for whatever reason. ⁓ And I would just say, keep it simple. So change the current way, sure. That's gonna be a big change. But from then on out.

Brian Milner (23:16) Hahaha.

Cort Sharp (23:32) just make small incremental changes and you will gradually build up into just this powerhouse of a product team and product delivery. And you will be, like you said in your last C, actually delivering great valuable products. When you were talking about that, again, I spend too much time on Instagram. I think I need to get off of it. ⁓ But I was looking through and ⁓ there's a, and I,

wish I could remember the name of this. It's effectively just a blog. But the dude wrote it in, it's a Ruby on Rails project. So pretty lightweight. Ruby on Rails is known for being kind of fast, pretty quick on the load times. But he was bragging that he was using AI to write 31,000 lines of code a day that he was putting into this product. And when you look it up on Google and you click on it, guess how long it takes to load?

12 seconds, it takes 12 seconds to load because he's just focusing on how many more lines of code can I push out there? What's the max that I could do? Like look how fast AI is enabling me to build this thing. Does it matter when your users can't even use it? No, right? So think about that. Build in the change into your process so that you don't end up.

Brian Milner (24:34) ⁓ wow.

Yeah.

Right.

Cort Sharp (24:59) tracking the wrong metrics so that you don't end up fatigued cognitively on just continuously changing, continuously trying to figure out where you're standing, what you're building, what's going on. I think too much change right out of the gate cuts down progress very quickly.

Brian Milner (25:19) Yeah. I also was trying to think about, know, is there a simple kind of staged approach to doing this that I would recommend? And regardless of what your framework is of choice, which I know there's decisions to be made there and I'm not trying to minimize whether you're going to do Scrum or Kanban or safe or anything like that. I completely understand that that is an important decision, but regardless of which one you choose, there's kind of five stages of this that I kind of laid out. So I want to run these by you and see what you think.

The first one I wrote down was visibility, meaning that can you see the work? That's part of it. Can you actually see the work in a backlog? Can you see the finished work? Can you finish anything? Can you get something to done? That's a big hurdle to get across right at the beginning is just being able to get something done. Then layering on top of that flow. ⁓

Cort Sharp (26:10) Yeah.

Brian Milner (26:16) working on things like whip limits, work and process limits, ⁓ so that we don't have too many things in process at once, but we have just the right amount so that we have continuous flow through our system. ⁓ That you're slicing things up smaller and across all the different ⁓ skills rather than just layer by layer of the cake, as they say. ⁓ And clear kind of ownership, clear ownership of who does what. That would be kind of a

Cort Sharp (26:27) Uh huh. Uh huh.

Brian Milner (26:45) a second stage. A third stage would be sort of the feedback stage where we're getting stronger reviews. We're getting stronger ⁓ feedback from customers, stakeholders injected into the system. And it actually makes a difference. It's not just, yeah, that's great. But you know what I like about it is this. And what I don't like about it is that, all right, well that actually will change what we do next, right? ⁓ I think that's an important kind of milestone is.

Cort Sharp (26:58) Mm.

Right.

Right, right.

Brian Milner (27:14) when you start to see that happen. ⁓ For stage four, I wrote down decision quality, ⁓ meaning that do we have a discipline in place? This is especially important for the product area, but a discipline in place for the prioritization framework that you're using so that it's not just, well, I think today this is the right thing, but you actually have a structure of how you're weighting things and trying to figure out what's most important, not just the loudest voice or.

Cort Sharp (27:40) Mm-hmm.

Brian Milner (27:42) you know, the favorite term, hippo, highest paid person's opinion, ⁓ that you actually have discipline in how you're prioritizing things, that you have discovery habits, ⁓ of figuring things out, ⁓ that your metrics are actually tied to outcomes. Those would all be things that I think are kind of that fourth stage of trying to increase your decision quality. And then kind of a fifth stage, ⁓ scaling but only

when there is pain that justifies it. ⁓ Meaning that we're only, we're identifying pain points and when the pain point presents itself, that's when we actually try to change something. You don't go to the doctor and get every cure, right? You go to the doctor and say, what's hurting? Well, this is hurting me. My knee's really hurting me right now. I don't know what's caused it, but a couple of weeks ago, this started to happen. Well, that gives the doctor enough information to say, well, here's some therapies we can try.

Cort Sharp (28:14) Hmm.

Right.

Brian Milner (28:40) And we don't do that often in this realm. We often just kind of approach it as, hey, well, here's a bunch of solutions, right? Here's a bunch of different medicines you could try. Why don't you take them all? And then you probably won't have any problems. ⁓ But that's kind of that fifth stage is getting to the point where I think that it's not just scaling. I know I said scaling, but it's not just scaling. It's that we're matching the cure to the actual disease.

We're actually figuring out what the real source of the problem is and we're making changes that address that problem specifically. So what do you think? What do you think about those five phases?

Cort Sharp (29:22) I agree. It all starts with being transparent. ⁓ If you can't see the work or even see the problems, how do you know that you're going to be able to prioritize which ones are the most important to solve? ⁓ And I forgot several of the ones in the middle. Typical kind of brain spikes there. You you start, you spike in the beginning, you spike at the end. But I think the end caps right there.

Brian Milner (29:42) Yeah, it's okay. It's okay.

Well, that's why it's great. It's on a podcast.

You can always rewind and go back and yeah.

Cort Sharp (29:53) Exactly.

You tap the back 15 seconds, whatever it is. But no, I think your end caps there are 100 % spot on. And that's through lived experiences. I mean, I've seen it dozens of times, hundreds of times probably at this point, where if you try to solve problems before they're actually problems, you can get into some hot water there. You can get into more real problems.

Brian Milner (29:57) Yeah, yeah.

Cort Sharp (30:22) later on down the road, right? Not that you shouldn't anticipate some problems coming up and have process in place to be able to manage them and handle them, but like my fingers aren't broken, so why would I go get a cast right out of the gate right now, right? ⁓ In anticipation of me breaking my fingers, I don't know about that. ⁓ Don't live that risky of a life. ⁓ But things along those lines, I like that, I think that's great. ⁓

I'm curious though, is that, is that how you would approach gradually adding structure is just say, Hey, start, start with the most basic thing. Once we get this thing under, under our belts, so to speak, or under our feet or feet under ourselves, so to speak there to say, okay, we're pretty transparent. Everyone knows what's coming up. Everyone knows what's, what's in the backlog. Then we take that next step up. And then once we figure that out and feel pretty good about that, then we can take that next step. Or are you trying to.

throw out there like these are indicators that you are ⁓ having a successful agile transformation.

Brian Milner (31:29) Yeah, I I think that I try to put it in terms of stages of like just noting what's going on around you. And, you know, if I'm in the thick of that, then these are things you would look for to say, yeah, we progress. We're moved from this to now this. ⁓ And I think that's that's kind of regardless of what framework I was implementing, regardless of how I was going about it, if I was trying to do.

some kind of an agile change within the organization. ⁓ I would start with the concept of what agile actually is. so that's why I kind of like this terminology of using it sort of more in stages is because it's not really about, well, do they know this? Well, do they have this term down? Are they doing this meeting this often? It's more about the outcome of what's, what do you actually see as a result of it? And

That's where I would not get hung up too much is just like saying, hey, we did 20 story points on this sprint and last sprint where they had 15. So we must be better, right? Because we did 20 stories. Well, no, it's not a performance metric. It really can't be used for that. And the same thing here. Well, we do all the meetings, so we must be doing scrum right, right? I mean, this must be working. Well, no, you're checking off a box, but...

Are you seeing the outcome from it? Are you seeing the purpose achieved in each one of these things? And that's where I think if I'm taking this approach, if I'm taking the approach to implementing this in an organization, I want to stay outcome focused. I want to stay focused on what the end result is that we're looking for. that's why I try to put this in terms of stages because I want to, know, visibility, I want to make sure that the work is visible. I want to make sure the results of it are visible.

Because we can't do anything more if we don't see the work. We can't you have to stack these right? have to stack those outcomes and and regardless of whether I'm using scrum or Kanban or Say for anything else XP, you know, it's that that's a stage in the process is actually getting visibility into

Cort Sharp (33:29) Right? Right.

Yeah, yeah, yeah. And it's all a callback to the first three minutes of our conversation here. It's all built on those three foundational pillars, as we like to call out in our classes and just when we're working with teams, transparency, inspection, and adaptation. And from those, you can build up whatever process works great for you. I know I've called it out before on this podcast.

You've called it out many times. ⁓ Spotify, when they first started going towards the agile route, they were like, okay, we're going to start with the foundational layer. And then on top of that, we're going to build the process that works great for us. And from that, they built what is now known as the Spotify model. And the dude who made that, or who helped them develop that, goes to other companies and says, don't use this, because it works at Spotify. It doesn't work here.

Brian Milner (34:37) Yeah.

Yeah, not only that, he'll say, not only that, he even says in the videos, this is not how we're doing things now. This is just like a snapshot in time. And that's an important thing to recognize as well is that what works for you today isn't gonna work for you always. ⁓ And it's important that you have the structure in place to be able to recognize when it's not working so that you can adapt and change and grow.

Cort Sharp (34:41) Starting with the basics.

Right, yeah.

Absolutely.

Yep. And when you're starting out with Agile, that foundational layer is, as I would argue, the most important so that you can continuously tear it, build it up to whatever you need to build it up to, tear it down back to the basics, so to speak, and then build it up for whatever the future might hold and whatever you're going through right now or working on right now. So totally. I'm right there. That's awesome. Sweet.

Brian Milner (35:26) Yeah, absolutely agree. Well, we're

at our time box for this. So want to be respectful of our listeners' times. But Cort, thanks for ⁓ bringing the topic and ⁓ participating in the discussion and giving us some good insights here.

Cort Sharp (35:40) Absolutely, Brian. Always happy to hop on here. Thanks for having me on again, and I look forward to the next time.