[MUSIC] >> 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. Court Sharp. Welcome back in, Court. >> Hi, Brian. Thanks for having me on. >> Yeah. Glad to always have Court on if you haven't caught Court in a previous episode. Court is a trainer with Mountain Goat Software as well. So if you do some work with this, you may see him in a class. You may also see him in a class. I teach sometimes, we'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, Court, why don't you set us up? Tell us what the big question is that we've been hearing. >> Yeah, sure. So I don't know if it's just 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? 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? 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, oh, Scrum's perfect for you. Oh, yeah, let's do Safe. That's no problem. 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. Love it. You know I'm all about being pragmatic. So yeah, I'm definitely on board with that approach. I think the big concept I would want people to understand is 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. That's the extreme case, I think, right? Where we get so bogged down the details that we just, 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 that 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. So honestly, if I own my own startup company and I have a team of people, let's just say I have a team, you know, small team, 10 people or so that I have as a Scrum team or not a Scrum team, right? I have 10 people and we're getting to the place where I want to introduce from. I'm not going to start by getting everyone in the same place as far as terms and definitions and everything else. I'm honestly going to start with Agile. I'm going to start with a mindset. I'm going to 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 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 it 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 what 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 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, well, we're following the rules because that's what the rules say. 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. 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 wanted 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. Call it out safe. We're going to stick with that, not to just, again, dog on, safe all at this. But 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. We're bigger than one team. So let's use safe and use that to scale our agile process, our 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. And if you don't understand even why you're doing this, that whole lot of stuff is just going to be noise noise in your process noise in your company, noise in your organization and noise in your development cycle. And it's going to stand in the way rather than help you deliver more value, repeatedly iterate, get better over time. Yeah. 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, oh, we just need to build stuff faster. Now, 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. Yeah. Right. This is not for you. And let me just give like a practical example here, right? Because I think just to make this kind of day by day, if you were going to start up a new scrum team, right? What are we going 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 going to 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. 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. 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 need to, we don't need to get too smart for 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, just come up with the ideas that you think you can get going on right then and there. And over time, believe me, you will come up with way more ideas than you could possibly ever build Jeff Bezos. If 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. you can do.
and focus on one thing. So actually Brian, I wanna 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 wanna influence you. So I wanna know what you're throwing out there first. - No, this is great. I love to compare notes and see what you think on this as well. I mean, I probably boil it down. If I'm thinking minimum viable process, kind of a new MVP term, right? Minimum viable process. I'm thinking very simple things like have a very visible backlog. Make the work visible so that everyone can have inside 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 until 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 over stress how important this is, but get everyone on the same page or what done looks like. Try to make it as strict as possible. And I don't mean dogmatic. I 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, oh, we really want this to be our definition of done. Well, all right, how long will it take you to get any item done? Oh, 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? And when I say done, I don't mean a big feature, right? 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 gonna cause problems as Mitch Lacey says in his classes, that if you're a developer, you'd be comfortable releasing it in the worst possible time, Friday afternoon, right? If you feel like, yeah, I'm confident I could call this that level of done that I would be okay 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, adapting on quality, respecting and adapting on usefulness to your customers, to your stakeholders, and inspecting adapt on your process overall, because that's really the igniter I think that has to catch, right? It's like, you know, when you turn on the gas oven or gas stove and you hear the little spark, the click, click, click, click, click, you know, like, and you're waiting for it to catch and the flame to start, that's what that is for I think an agile team is that short inspect and adapt cycles because 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 turnover and getting it actually up and running to start to improve. But those are basic things, and it, you know, it's none of those things that I say, make sure everyone understands the definition of these, other than done, right? There's nothing, you know, there's no role, there's no anything else. I think that 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? - I don't disagree with anything that you said. Maybe a slight difference on, you know, 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, right? 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, okay, what can we do better next time? And that's it, right? 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 get more into the basics, I thought it was funny that you jumped right into like, hey, we need to have a backlog, we need to go into short iterations. I think we need one at team. - Yeah. - Some people to build stuff, right? And it doesn't have to be a big team. We 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 priority, right? 'Cause 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, nope, 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. But I think that a clear priority person is the only thing that I would change there or add to it. - We'll be right back to this discussion in just a moment. In thinking about this topic too, I wanna throw something out there to you and get your take on this. But I was trying to think of 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 instead of actually doing the work. 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 useful process. 'Cause at the 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 I was coordination drag. This is about handoffs, the overlaps with other groups and how you coordinate across things. Do you have more dependencies or your dependencies that thing that's really slowing you down? What's the source of that dependency drag? Can you ref configure 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 C's, but I couldn't. The last one was kind of, well, maybe it's, I mean, it's false confidence is kind of the way I phrased it. 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. They kind of can get a false sense of confidence. And that's a drag because when you have that false sense of confidence, oh, everything's going great. There's nothing to worry about. It looks like, you know, look, well, look at our metrics. Our metrics say this. Yeah, but are you measuring the right thing? I'm much more interested in impact versus velocity. I could care less if we build half the things that we used to build, but the things that we build have doubled the impact of the things we used to build. Right? 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 me, you know, 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 a group down from being successful in making this kind of change? 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 OK. 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 even motivationally. I think it falls into your first see 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 I just think being aware of that and having some wisdom.
them when approaching that. Yeah, it's the difference between teaching your team to overcome whatever the present changes 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. Right, 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 up front. Again, back to, I like keeping things simple, Brian. Just keep it, I hate over-conflicating 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 going to be a big change, but from then on out, 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 see, actually delivering great valuable products. When you were talking about that, I, again, I spent 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. Wow. 12 seconds to load because you're, 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's enabling me to build this thing. Does it matter when your users can't even use it? Yeah. No. Right. Right. So think about that. Build in the change into your process so that you don't end up 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. Yeah. I also was trying to think about 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 scrawm or con or save for 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 biodes to see what you think. The first one I wrote down was visibility, meaning that can you see the work, that's part of it, right? Can you actually see the work in a backlog? Can you see the finished work? And can you finish anything? Can you get something to done? That's a big hurdle to get across right at the beginning. Just being able to get something done, then layering on top of that flow, working on things like whip limits, working 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 ownership, clear ownership of who does what? That would be kind of 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 customer stakeholders injected into the system and it actually makes a difference. It's not just, oh 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 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 waiting things and trying to figure out what's most important, not just the loudest voice or you know the favorite term, hippo, highest paid person's opinion, that you actually have discipline and 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 identifying pain points and when the pain point presents itself, that's when we actually try to change something. We don't go to the doctor and get every cure, right? You go to the doctor and say, well what's hurting? Well this is hurting me. My knees really hurting me right now. I don't know what's causing it, but a couple of weeks ago this started to happen. Well that gives the doctor enough information to say, well here's the therapies we can try. 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? Then you probably won't have any problems. 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. We're matching the cure to the actual disease, right? We're actually figuring out what the real source of the problem is and we're making changes that address that problem specifically. Right. So what do you think? What do you think about those five phases? I agree. 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. That's okay. It's a typical kind of brain spikes there. You know, you start, you're spiking the beginning, you spike at the end. Well, that's where it's great. It's on the podcast. You can always rewind and go back. Exactly. You tap the back 15 seconds, whatever it is. But no, I think your end caps there are 100% on spot on, right? And that's through limb 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 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 let that risky of a life. But things along those lines, I like that. I think that's great. I'm curious though. Is that how you would approach gradually adding structure is just say, hey, start with the most basic thing. Once we get this thing under our belt, so to speak, our feet under our cell, so to speak there, to say, okay, we're pretty transparent. Everyone knows what's coming up. Everyone knows 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? Yeah, I tried to put it in terms of stages of just noting what's going on around you. If I'm in the thick of that, then these are things you would look for to say, oh yeah, we progress. We're moved from this to now this. I think 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. 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 do you actually see as a result of it. That's where I would not get hung up too much is just like saying, hey, we did 20 story points in this sprint and last sprint with it at 15. We must be better, right? Because we did 20 sorbings. Well, no, it's not a performance metric. It really can't be used for that. The same thing here. Well, we do all the meetings. We must be doing sprung right. 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? That's where I think if I'm taking this approach, if I'm taking approach to implementing this in an organization, I want to stay out. I want to stay focused on what the end result is that we're looking for. That's where I try to put this in terms of stages because visibility. I want to make sure that the work is visible. I want to make sure the results of it are visible because if we can't do anything more, if we don't see the work, you have to stack these. You have to stack those outcomes. And regardless of whether I'm using scrum or conbon or say for anything else, XP, that's a stage in the process is actually getting visibility into the work. And it's all called back 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. From those, you can build up whatever process works great for you. I know I've called it out before on this podcast. I'm, do you've called it out many times, Spotify when they first started going in the, towards the Agile route, they were like, okay, we're gonna start with the foundational layer. And then on top of that, we're gonna 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, it's Spotify, it doesn't work here. So starting with the basics. - Not only that, he even says in the videos, this is not how we're doing things now. - Right. - Yes, it's just like a snapshot in time. And that's an important thing to recognize as well that what works for you today isn't gonna work for you always. - Absolutely. - 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. - And when you're starting out with Agile, that foundational layer is, 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. - Absolutely great. Well, we're at our time box for this, so I want to be respectful of our listeners' times, but Court, thanks for bringing the topic and participating in the discussion and giving us some good insights here. - Absolutely, Brian. I'm always happy to hop on here. Thanks for having me on again, and I look forward to the next time. - Well, let me start by just saying thanks to Court again. I really appreciate him making the time for this and walking through this with me. When we have Court on, it's nice here to hear your conversation there. And that's really what I hope for when we started this thing is to have conversations like that. So I appreciate him making time and bringing it when he comes, being ready to talk about these topics. If you like this topic and you want to help us out, you like this show, what we'd ask you to do is to help us grow by doing just one of a few things. The biggest thing you'd probably do is just tell a friend, tell a coworker that you found this and that you thought it was useful. But the other things, the normal things you'll hear on any show, anything today, like the podcast, subscribe to it, that'll make sure you don't miss any. It also makes it easier for others to find us. So I know it may not seem like it does much, but it actually does push us up in the rankings and we don't advertise anywhere. We're just doing this with community and we wouldn't love for other people that could benefit from it to find it. So that's a great way you can thank us. We'd also like to hear from you. So send us an email,
[email protected]. Tell us what you think about this topic. Tell us what you think about getting started with Agil and what you've experienced. I'm always curious to hear kind of reports from people who are out there listening. So feel free to send that to me. I'd love to hear it and interact with you a little bit on it. Or if you have any suggestions for guests you might want to hear or topics you want us to cover that we haven't covered in a particular way, let us know that as well. We're always looking for what might make this more practical for you. And like I say a lot of times, I hope your week's going well. I hope things are going well for you. We'll talk to you next time on another episode of The Agil Mentor's podcast. [MUSIC PLAYING]
PodcastTranscript AI