Detailed Notes
Scope creep is one of the most common — and costly — challenges in software development. In this episode of Building Better Developers with AI, Rob Broadhead and Michael Meloche explain what scope creep is, why it happens, and proven ways to prevent it from derailing your projects.
You’ll learn: * The difference between scope creep, feature creep, and healthy iteration * Real-world examples of how uncontrolled changes can damage timelines, budgets, and morale * Practical steps to define requirements, set checkpoints, and manage change requests
📖 Read the blog version: https://develpreneur.com/scope-creep-explained/
Transcript Text
[Music] He's loud. And we are back and we are uh let me go where did I put too many screens too many okay so this one we're going to do mastering scope creep navigating the hidden challenges in software development and this is going to be our AI version of this hidden challenges so this will be interesting I thought we had talked about scope creep a little bit before but I Guess that was maybe that season. So, we'll see what it says. Um, it looks like Oh, good. I'm back to my uh Let me do it this way. Let me do it so I can read a little better because this is a little bright. Oh, actually, it is brighter. But let me do it this way. If I brighten this up. No, I like this monitor better. Sorry. Sorry, folks. Because now I'm going to be looking over here a little bit and I don't want to move on. I guess I No, I don't want to do that. Um, so it starts with great podcast topics. This is we're back to one of those. It's in it's in a good mood today. So we'll see how it goes. Um, let's just dive right in. Go. Oops. We're going to start with three this too. Oh, we're going to go back. Those uno. Ola. We are back again. This is building better developers, the developer podcast where we well for one word are multilingual and not very well. I am Rob Redhead, one of the founders of developing building better developers. Also the founder of RB Consulting where we help you do business better. We do it by helping you leverage technology for your business. Now, there's a lot of companies out there, don't want to throw shade, but they're going to just give you a solution. They're going to say, "Here's our stack. Here's our solution. Here's our vendors. Here's our products." Or they're going to be a vendor that's like, "Here, buy our stuff." And what we do is we we've played around with all of that. We've worked with that for big and small companies and through simplification, integration, automation, innovation, we're going to work with you to find a way to craft your own specific recipe for success, help you build a product, a technology roadmap, maybe even a product road map and either hand that to you for you guys to take it and run or we can stand beside you, work with you, we can help you build a team. However that needs to be implemented, we have the resources to do that. So, we're going to help you leverage technology better, and we want to do it in a way that allows you to move forward with the best ROI on one of these most expensive pieces of your business. Good thing, bad thing. Literally, uh those of you that are watching, uh those of you are not, shame on you. Um you can watch us on the on YouTube. Those are watching will know that I have a little monitor, little side monitor. Well, played around with these for a while as part of my being a remote developer. And uh for my laptop, I worked with a couple things. Initially, I had a nice big like thing that you can mount on a laptop. I've got two extra screens. It was pretty cool. Only problem is I want to travel a lot and those were heavy. So, I went to a a lighter monitor. And in doing so, I have now like got my got one cuz one for my wife cuz it it worked out. Uh her laptop only supported one monitor anyways. So I got that, went back and got the other one. So good thing is I got my other monitor today. Uh a good bad thing as part of this is the first one I got was when these were first coming out and it wasn't that long ago. They were first being released and they were 200 bucks a piece. Well, a little less than 200 bucks a piece. When I went to get the second one, they're like 65 bucks a piece. So, if I had waited a month and a half or whatever it is, I would have saved myself money. But the good news is the good part is I did save myself some money. And what's also good is I still have for my own little laptop a slightly better highly, you know, more geek cred than Michael has for his laptop thing that he carries around at least last I checked. But he's going to let us know about that. But more importantly, let us know about him as he introduces himself. Hey everyone, my name is Michael Malashsh. I'm one of the co-founders of developer building better developers. I'm also the owner of Envision QA. We help startups and growing companies build better software faster and with fewer problems. Our software covers software development, quality assurance, test automation, and release support. Companies come to us when they want to avoid delays, reduce bugs, and launch with confidence. Whether you're building your first MVP or scheduling a live product, we make sure your software is reliable, efficient, and ready for growth. Check us out at envisionqa.com. Oh, good thing, bad thing. Well, actually, first I'll take get a little throw out there. So, I have two uh 48 in ultrawide curve monitors for my desktop slashie laptop for my workstation. And when I do have my laptop, it is just my laptop. I don't carry the other things with me because if I do need the screens, I'll just go home and plug in and basically have this big humongous wall of screens. U anyway, digress. Good thing, bad thing. Uh kind of the same. Uh allin-one today. Uh wife came out to the river yesterday, turned on the water, had everything set up. We were going to spend the week out since the weather's nice and enjoy the river. And our water pressure dropped within an hour to nothing. We thought they turned the water off because we didn't pay the bill. Nope. paid the bill. Come to find out, we had a broken pipe in the middle of the yard. Took uh the plumber 48 hours to get out here to look at it. Good news is they finally found it after 3 hours of digging around. Uh patched it and I have water again after let's see, I've been at this location. So, I've been here for over 9 hours with no water today. So, it it's been an interesting day. Well, the day is going to get more interesting because we're going to go back to uh sorry if I do dove right into this, but this is our season where we are taking a past season and we're going to do it with AI. So, we take a topic, throw it out to Chat GPT and say, "Hey, what would you do if you were going to create a podcast like this?" And uh we start going. So, this time the title we're going back to is Mastering Scope creep, navigating the hidden challenges in software development. And this is back to the responses that's given in the past where it's saying great podcast topic that taps into a very real pain point for developers, managers, and even clients. It's also a perfect match for your podcast theme of building better developers below our ideas for structuring the episode suggested segments and discussion angles that could engage your audience. So, uh, they add a couple of podcast episode title ideas, but let's just dive right into the structure itself. Item one, and I think this is back to going to give us eight. So, we'll see how far we get through this. What is scope creep and why it happens? Define it in plain terms with real world examples. Differentiate scope creep versus iteration or agile flexibility. stakeholders. Who introduces creep? Clients, developers, or managers? Oh, wow. Scope creep. I think I want to tackle the scope creep versus iteration or agile flexibility because this is where I think a lot of people get lost. Scope creep is when and and this is my term. So if you look it up in Wikipedia or something like that, if it's exactly like my term, then let me know because I need to charge them money or something like that. But this is my thoughts on it. Scope creep is when we have defined requirements and we agree to the requirements and we start working on the requirements and now the requirements change. Scope creep is essentially changing requirements. Now this is different from uh iteration which is where we go through with a requirement. We complete it essentially we review it we iterate and now we have a new or a evolved requirement. So that would be more the iteration side and then on the uh agile flexibility side is where in there when you get into ads where we have requirements from the from the start we'll say and then as we go into a sprint we have requirements the requirements that we have at the start may evolve so that by the time we get into a sprint and we're actually working on that requirement it may have evolved may changed may have even you know disappeared it may be brand new things like that scope creep in that sense is not so agile flexibility means that as we're going through we can create new requirements as we're going we can evolve what we are building as we are working down that agile path that's not the same as scope creep scope creep and agile would be that we set a uh requirement we say it's done essentially and then we move or as we get almost to done we move the goalpost So the easiest way to think of scope creep is moving the goalpost. Scope creep is more about changing what done is essentially or what completing that requirement is or what that requirement entails as opposed to going back and saying all right we're going to we're rewriting the requirement and sort of a little bit of it's not starting from scratch but if you get that idea it's sort of the idea of instead of changing the requirement when you're almost done change the requirement before you step into it and it is very much a a squishy you know type of area, but I think it's something that we do want to make sure that we understand when there's there's a difference between being flexible or saying that, hey, this is a bad requirement and rewriting the requirements versus scope creep, which is really like stretching that requirement out and making it into something that wasn't originally intended to be. Like I said, this is lot of places we can go here, so I'll be interested to hear what are your thoughts on this. Yeah. So, it's interesting with scope creep because scope creep can to me I've also heard feature creep and feature creep to me is different than scope creep but they're kind of the same. Um, and there are also you mentioned requirements. So as like you gave a good explanation about scope creep but with scope creep as you're working on the project as you're working on features you can run into issues where a feature that was agreed upon for the requirements if that was 6 months ago depending upon where you're at in the development cycle that feature might not be there anymore. So you could even run into a place where hey you're actually building something that is not that meant to be there anymore. So you've run into a requirement change and you are essentially it's not necessarily scope creep but you've kind of diverged. You've gone down a path a rabbit hole doing a feature that was agreed to initially but isn't there anymore and that's it it it is it is similar to moving that goalpost but it is not just moving the goalpost away. You've kind of oh instead of going in the straight line you've kind of gone around the town. you're building a bypass when you need to just build the tunnel through the town. So that's one of the things you got to be careful of with scope creep and feature creep is you have to make sure that you do regular checkpoints. Rob talks about agile and scrum all the time and is perfect for this. But a lot of companies even though they're trying to do scrum or maybe they're not even doing scrum or agile, they run into situations where we talk about this once right up to tickets and then just go off and expect the developers to do it. And if you don't do regular checkpoints to make sure that hey, are we on track? Are these requirements still fresh or have they gone stale? And you could essentially end up with a different type of scope creep being meaning that you're working on a project that really doesn't exist anymore or has changed so drastically that your scope is you're working on features that are outdated and that sometimes is the case is that you end up in a situation where you are you're building to the wrong you're building to the wrong target. Um, that's where I do I I very much agree that it is important to do those regular check-ins to make sure that are we agreed that we're working on the same path. For example, if you think of of driving on the road going from point A to point B, it may be that there are, you know, that along that road, it makes sense to follow that road. Those are the, you know, that is the features essentially that you're going. The creep may be somewhere along the way that you're like, hey, we need to, you know, take a bathroom break or something like that. that is not really as much of a feature creep as more of like, hey, we're gonna go take three days and we're going to go have a vacation somewhere else is really the the effect of a a feature creep or a scope creep. The next one, how scope creep affects developers, burnout from uh burnout from endless changes, confusion about goals and ownership, missed deadlines and technical debt, loss of confidence in estimates and planning. Oh boy, that is those are all actually really good uh issues. I think I want to go with the estimate side because I think this is a this is an area where it is it almost becomes I mean I hate to say it this way but it almost becomes the equivalent of a self-fulfilling prophecy. I have been in situations where you've got a customer that is uh whoever the customer is, it could be internal, it could be external, however it is, they are driving the product that we're building software for this customer and they're sometimes it's they're not totally sold on it in the first place because they think it's going to run over or it's going to be late or it's going to slip or all the politics that can happen. And what ends up happening is in some of these is you have people that are this customer doesn't really know where they're going. They don't really understand what they want to do and then they start feature creeping is they basically scope creep says they're say hey we need um you know it's like we need this report. This is so often this where it starts. We need this report. We need these five items and we need them displayed this way. Cool. All right, we have it and now we're going to push that out there. And they see it and they say, "Oh, wait. We need this other piece of data. Oh, can we summarize that data? Can we add totals? Can we uh we want to be able to sort stuff? We want to be able to filter. We want to be able to run this for certain criteria that initially were not included. You know, initially it was like we just want to run it for dates." And they're like, "No, we want to run it for dates, but we also want to run it for specific customer or only specific employees or specific blah, you know, all of that kind of stuff." And next thing you know, this little ritty report that should have taken 3 hours and maybe did initially now has taken 3 weeks because the goal keeps changing. Everything keeps moving and now everybody's complaining. It's like, hey, this should have been done a long time ago. Yes, it actually was done a long time ago, but then everything changed and those changes make they cost more to change than it would have had they been there initially. because now this stuff that you built for you built the solution for one thing and now there's all this extra stuff that's gets added on and the next thing you know you're in a a death march because of a you know a report or something like that. So I think those are where it gets really frustrating on both sides because the developers get frustrated because their estimates are crap because as soon as they put it out there they're held to the estimate but now the requirement they estimated against is different and so they know that they're going to lose. they know that they, you know, or if they change it, then it's like, why do you keep changing it? Well, because the goalpost keeps moving. And on the customer side, they're sitting there going, "Why do we even ask for estimates?" Because we never get an estimate that means anything. They estimated 3 hours and now it's 3 weeks later. And so, you end up with this like everybody's pointing fingers and stuff like that. And so, scope creep can be very devastating in that kind of sense as far as just the trust, the estimation, the the planning, the milestones. Uh I'm I don't know how many projects I've been in that were, you know, failing or failures that you can point to changing requirements. And before I pass it to Michael, I will give the like the the epitome of bad like this is going to go bad in that kind of sense of bad requirements are these kinds of projects where somebody is like, hey, I need you to make eBay but for dog food, you know, or something like that where they they're like, well, just take this this thing and I just want to make it, but I want to make it slightly differently and that's the requirements or just use the existing app as a requirement. ments and just make something else that looks like that but only better. You know, there's there's too much wiggle room in there. There's too little definition. And so, whatever you're initially going to look at, whatever you're initially going to estimate, you're pro unless you're really really good at like mocking that thing up and spending a lot of time in that estimation phase and basically halfway building the solution or more, then you're going to miss it because you're going to have a different picture in your head. So that being said, where do you want to go on this one? >> Well, you kind of touched on three of the four bullet points, so I will go with the one you didn't touch on, which was burnout from endless changes. Because literally everything you laid out, you know, talking about the confusion about goals and ownership and missing deadlines and technical debt and the loss of confidence in estimating and planning, all those things lead to burnout. You know, from developers perspective, we've talked about being in firefighting mode. This is not firefighting mode. this is I am working on a ticket and you know I've agreed to the requirements of this ticket and it's only going to take me a day to get it done and next thing you know you are 4 days into it 6 days into it two weeks into it is like a neverending death march when the hell is this going to get done when are you going to quit changing the requirements of this ticket so that I can actually complete something which goes back to before you commit to a ticket. Make sure that your tickets or the requirements have a clear definition of done. What is it that they want? If it changes at that point, the ticket needs to close. Write up a new ticket and define what specifically it is that the new change wants. Trying to cram it all into one ticket is so much scope creep that you don't you basically start out with apples and you end up with oranges. You the ticket never is what it was at the beginning. Sometimes it is. Sometimes it is simply okay what we thought this change was going to be. You run into a blocker or a situation where you can't implement what it was or the way the ticket was written up. You can't actually implement it that way. Sometimes that requires a pivot and an update to the requirements of the ticket. Sometimes that happens. That's not necessarily scope creep. that is, oh, this should have been a discovery ticket because we found something that wasn't there. So, in a sense, you could keep that ticket open, re-update the requirements to what it needs to be, or really close that ticket, create a new ticket based on your findings as to what it is you need to do, and then focus on that reestimate on the new requirements. So, if you don't do this, you run into again those situations where you're just on that death march. You it's like you're working on it. You think you're done. Oh, you're told it's not done. Well, why is it not done? Well, because it needs this, this, or this. Well, that wasn't in the ticket. Well, it needs to be done. And you get into those loop back scenarios where you just can't get done. And burnout. I it it just is so prevalent that it it these are the types of tickets that will cause burnout. If you find yourself running into like low energy or, hey, I don't really want to do this anymore or, man, I've been really at this for a couple days, take a time out, take a step back, revisit the requirements of the ticket, and maybe have a quick conversation with your manager of like, hey, we need to reset this ticket. Either close this ticket and create a new one or really redefine what it needs to be done and get it done. >> Yeah. Sometimes that's the when you catch yourself in this situation that is the best thing is to just like take a deep breath step back and I' I've been in projects where we've done that as a group as a project group and said this is we're we're churning we're stuck in a rut something like that and it's better to say okay let's step back let's look at what we really want to get done let's reassess some of these things and maybe some of these things are a scope creep let's just define them say okay we've hacking on this thing for the last three sc sprints. Let's step back. Let's actually figure out what this needs to be or pause it for a while. Go move to something else while somebody else researches it so we can get something that is is much more stable. Um, in a short bit here because I don't want to go too long because this go really long. Stories from the trenches. Share real examples from your experience or listeners that one project that never ended or we rebuilt the same feature three times. The we rebuilt the same feature three times I'm going to say is something I have run into multiple times and it is a a warning that I have and this uh I've seen this in many types of projects the ones that happen a lot anything that requires mapping or integration that there is this danger that includes scraping projects that also recruits anything that's a an ERP, uh, a CRM. And the the problems with these projects that are scope creep kinds of things. Too often I found a customer comes in and they're really not ready for that tool yet. And when the implementation begins, the right questions are not asked and those don't surface until it's later in the project. And now you have to change things and sometimes rewrite things. I will just because this was a specific one. I'm going to I will talk about a specific project that was like this. We went in uh it should have been a very straightforward project should have been this is what it should have been done in three four weeks something like that. The whole point was the customer knew what their data was. There was a vendor that knew where that data needed to go. All we needed to do was pull the qu pull the data and then use the mappings that the vendor said we were going to use. Well, it turns out that the vendor really didn't know what the heck they were talking about. And they were counting on us to tell them where the data is supposed to go when it was like, "No, you're supposed to tell us. We don't know that system. We don't know your system. We're you're supposed to know this. You're the expert." That 3 to four week project. Um I wrapped up on it I think nine months later something like that. We were still going through things. We had ended up changing multiple times how we approached it because the integration that we had built we were assured that this was going to work and then we found out that no actually that that the target product did not support that and then and it goes actually to a report as well. there was a certain report that they needed. They're like, "Sure, we're going to give you that, but they weren't giving it to them in the way that it was needed." And so, you ended up with all of these like, "We changed the mappings, we changed the approach, we changed the format, we changed the structure, we changed stuff over and over and over again." And it was one of these things that should have been a oneanddone, and we ended up doing it over and over and over again. And really it wasn't so I mean it was scope creep but the real problem was is that the scope never really got defined properly. Everybody was thinking somebody else is going to take care of it and it didn't. And so that is a warning. I will say that as a cautionary tale to any of these bigger kind of projects and integration kind of projects where there is the where you hear the word mapping involved then make sure that the people that are involved on the source and the destination of those mappings understand what they're doing. They're clear on who owns what and how that needs to go because that process doing the mapping often is the biggest time sync the biggest part of the development effort. The rest of it is actually pretty straightforward. is getting those mapping rights and any translations between the two uh in roughly 60 seconds or less. I guess I'll give you a little bit of time. So what's one give a if you can give a quick example from your experience. >> So it wasn't so much scope creep but illdefined expectations from a manager. Uh I had built a modulebased application. This was before containers and all this, but I basically built a containerized application that the manager likes so much instead of using the model and building on it. It was copy and paste the project here, spin up another project here, copy paste, do this. We did that six times and then when one feature that was common to all of them had to change, we had to go through every application essentially redo it multiple times instead of having one common application. It it was the worst. I don't want to say it was self-imposed scope creep by a management decision because if your software isn't built to scale or it's if you try to treat it like a cookie cutter, you could run into a situation where you get into those uh situations where the project never ends because one feature change based that they think is a easy requirement is not. It is something that really should apply. If you have six applications and it's a feature in all six, you need to take that and multiply it by six because it may not be a simple change. That is boy that is that is its own little problem there is that the idea of a simple change. Um too often I have seen that as you know oh this is something really and developers do it just as well where it's like oh yeah it's a simple and then it's not because it gets underestimated and it really is probably related to scope creep. Uh what is not scope creep is you sending us an email at info developneur.com. We have had that requirement forever. That is like that goes way way back. That goes back dozens maybe hundreds of episodes. Love to hear from you. Give us your feedback. What do you think? What do you like? What do you dislike? Uh and obviously with any of these, what are some examples you'd like to throw out there? Because the real world stuff is always very useful to us. And even though it may be, you know, we may be on to a different topic, it is uh we always can find time if we need to. If you have something interesting, we will swing back around and just bring that up and say, "Hey, by the way, here's a flashback or we can use it as bonus material for the YouTube side." So those of you that are on the a out on the audio version listening to podcast, we also have the we have our YouTube channel developing our channel and we have all the stuff out there. We always have uh pre and post show stuff including every show we end with bonus material basically unless we started with a ton of bonus material then we don't double up too much. You can also reach us at X uh there's developer developer.com is the best place to go out on that site. You've got access to all of our content, all of our past episodes, all of our if you want to go out to YouTube and look at it there. Uh all of our presentations, just tons and tons and tons and tons of content. It is amazing how much stuff is out there. I look at it sometimes, I'm like, "Oh my gosh, we have I've forgotten more stuff than we have, you know, than I can think of that we've put out there." So, check that out. Uh Facebook, we have a developer page. Wherever you find our all of the fine podcast products, you can find uh developing our podcast. If you find somewhere and you're not getting it, let us know. We'll make sure we get hooked up there. That being said, we do appreciate you and your time. Go out there and have yourself a great day, a great week, and we will talk to you next time. Bonus material. Uh I am going to go do like a super fast read through these because we didn't get really far at all. Uh, so four and I and then just pick one whatever and you got in front of you. So you can pick something where you want to go after I read through this and I'll see what I want to do. How to recognize scope creep early subtle warning signs. Can we just add one more thing? Frequent changes without updated timelines. No clear acceptance criteria or documentation. How to put push back without burning bridges. Soft skills for saying no constructively. How to involve project managers or product owners when and how to renegotiate timelines or budgets. Process and tools to prevent it. Define scope up front. Clear user stories. Definition of done. Agile board. Sprint planning. Change control. Versioning. Milestone check-ins and backlog management. Documenting assumptions. Mindset shift. Treat scope creep as a symptom. What is the client client really trying to say? Use it to improve product vision or communication. Good scope change is not the same as bad scope creep. Developer tips. Personal tactics at work. How to manage energy and focus in evolving projects. Keep a change log or scope journal. Estimate with buffers. Create your own guard rails as a developer. Uh there's a lead magnet called action ideas. And we will go with oh bonus segment ideas. Roleplay. Clients asked to change scope midsprint. How do you respond? Q&A. Take listener questions about real life scope chaos or tool highlight tools like notion linear or jira that help. So what do you want to throw out there for your bonus? >> Uh where was it? Um yeah. So, I like the process uh where is it? Process tools six. There it is. Process and tools to to prevent it. Which kind of goes with the bonus thing, you know, agile boards like Miro, um Atlassian, uh Jira, Trello. Use boards, use storyboards, write up, you know, kind of brainstorm. Don't just go into writing tickets sometimes. Sometimes it takes walking through the idea. Um, a lot of times when I'm working with managers or customers, I will pull out a sheet of paper. I'll pull out my iPad. You know, you bring up some type of drawing tool, notepad, whatever, and you just start kind of flowing through your ideas. You draw it out, or you just kind of walk through scenarios and situations on how the application's going to work. So, you can kind of flush out the direction or the feature that you're trying to build. So, there's a lot of things out there. find what works for you, but sometimes pen and paper work great or just simple like notes or notepad and just start kind of typing out your thoughts or just um if you use ASKI docs or markdown, throw up a little markdown script as you're writing out u kind of the requirements and then translate that into a wiki that you have for your notes for your developers. Yeah, I think I want to those are those are all great and I think I want to sort of that leads well into what I want to talk about which is not specifically mentioned but is a clickable demo. Uh, I have found that this is a great way for you to get stuff in front of your customers much like, you know, drawing a picture and things like that, but it's also a way to get it in front of them and and make it real. Yes, it's nice to use uh Figma and all those kinds of stuff and build these things out and do them pretty and sometimes you can do that and put enough information into it to give them a good clickable demo. But what I like about one that is a what I'll call a evolving or a true clickable demo, one that we often use is that we actually build the demo. And this is a framework going forward. So what they're going to see is they're going to see the evolution, especially in agile, this works great is they're going to see the evolution of the solution of the application and you're going to be able to put it in front of them. You're going be able to get them a feel for what is it? What is it like to sit there with this application? What is the navigation like? what is some of the get some sample data in there so it starts looking real to them because those are the things that then they're going to say well wait a minute I don't see this or that value is never going to look like that or that could never be exist with that over there those things are invaluable to avoiding scope creep or at least getting the scope creep covered sooner rather than later so I think highly recommend it if you have not done it, then give it a shot. Uh, it's a lot of people are big on the whole MVP thing and and stuff like that. That's really not that far off from the idea of a clickable demo. Um, as always, if you want to if you if you wonder how that will look, shoot me an email at info developer.com or like, you know, hit me up on the RB-SNS site, schedule a call. I I have no problem spending 30 minutes sitting down with somebody and just saying like, here's some things you can do. here's some questions you want to ask. Here's how you want to approach a clickable demo because you're not necessarily going to spend you're not going to get everything done at once. And there's definitely concerns in there about like having something that's too ugly or too pretty or not complete enough or too complete. And there's there's a lot of caveats on in that. But happy to try to get more people to do this and get better at it. Uh because also I think it'd be nice for customers to have more of a feel like what to expect in a clickable demo, which is one of the key things you have to do is set those expectations up front. Just like we try to set expectations to have like a certain amount of length for our episodes, and we're not terribly good at that. I mean, I guess we're within 15 to 45 minutes an episode over the all of these. So, we have some reasonable faximile of of a standard, even though we do move them around a lot. But we appreciate your time whether we go a little short or a little long. We are going to wrap this one up and we will be back before you know it to run into our next episode where we're going to continue learning more about how to build a better developer with AI. Well, really just some AI input on our thoughts, but you know how it goes. As always, appreciate your time. All that you have done to just like hang out with us. Feedback is awesome. Love you guys. Have a good one and we will talk to you next time. [Music]
Transcript Segments
[Music]
He's loud.
And we are back and we are
uh let me go where did I put
too many screens too many okay so this
one we're going to do mastering scope
creep navigating the hidden challenges
in software development and this is
going to be
our AI version of this hidden challenges
so this will be interesting I thought we
had talked about scope creep a little
bit before but I Guess that was maybe
that season. So, we'll see what it says.
Um, it looks like Oh, good. I'm back to
my uh Let me do it this way. Let me do
it so I can read a little better because
this is a little bright. Oh, actually,
it is brighter. But let me do it this
way. If I brighten this up.
No, I like this monitor better. Sorry.
Sorry, folks. Because now I'm going to
be looking over here a little bit and I
don't want to move on. I guess I No, I
don't want to do that. Um,
so it starts with great podcast topics.
This is we're back to one of those. It's
in it's in a good mood today. So we'll
see how it goes. Um, let's just dive
right in. Go. Oops. We're going to start
with three this too. Oh, we're going to
go back. Those
uno. Ola. We are back again. This is
building better developers, the
developer podcast where we well for one
word are multilingual and not very well.
I am Rob Redhead, one of the founders of
developing building better developers.
Also the founder of RB Consulting where
we help you do business better. We do it
by helping you leverage technology for
your business. Now, there's a lot of
companies out there, don't want to throw
shade, but they're going to just
give you a solution. They're going to
say, "Here's our stack. Here's our
solution. Here's our vendors. Here's our
products." Or they're going to be a
vendor that's like, "Here, buy our
stuff." And what we do is we we've
played around with all of that. We've
worked with that for big and small
companies and through simplification,
integration, automation, innovation,
we're going to work with you to find a
way to craft your own specific recipe
for success, help you build a product, a
technology roadmap, maybe even a product
road map and either hand that to you for
you guys to take it and run or we can
stand beside you, work with you, we can
help you build a team. However that
needs to be implemented, we have the
resources to do that. So, we're going to
help you leverage technology better, and
we want to do it in a way that allows
you to move forward with the best ROI on
one of these most expensive pieces of
your business. Good thing, bad thing.
Literally, uh those of you that are
watching, uh those of you are not, shame
on you. Um you can watch us on the on
YouTube. Those are watching will know
that I have a little monitor, little
side monitor. Well, played around with
these for a while as part of my being a
remote developer. And uh for my laptop,
I worked with a couple things.
Initially, I had a nice big like thing
that you can mount on a laptop. I've got
two extra screens. It was pretty cool.
Only problem is I want to travel a lot
and those were heavy. So, I went to a a
lighter monitor. And in doing so,
I have now like got my got one cuz one
for my wife cuz it it worked out. Uh her
laptop only supported one monitor
anyways. So I got that, went back and
got the other one. So good thing is I
got my other monitor today. Uh a good
bad thing as part of this is the first
one I got was when these were first
coming out and it wasn't that long ago.
They were first being released and they
were 200 bucks a piece. Well, a little
less than 200 bucks a piece. When I went
to get the second one, they're like 65
bucks a piece. So, if I had waited a
month and a half or whatever it is, I
would have saved myself money. But the
good news is the good part is I did save
myself some money. And what's also good
is I still have for my own little laptop
a slightly better highly, you know, more
geek cred than Michael has for his
laptop thing that he carries around at
least last I checked. But he's going to
let us know about that. But more
importantly, let us know about him as he
introduces himself.
Hey everyone, my name is Michael
Malashsh. I'm one of the co-founders of
developer building better developers.
I'm also the owner of Envision QA. We
help startups and growing companies
build better software faster and with
fewer problems. Our software covers
software development, quality assurance,
test automation, and release support.
Companies come to us when they want to
avoid delays, reduce bugs, and launch
with confidence. Whether you're building
your first MVP or scheduling a live
product, we make sure your software is
reliable, efficient, and ready for
growth. Check us out at envisionqa.com.
Oh, good thing, bad thing. Well,
actually, first I'll take get a little
throw out there. So, I have two uh 48 in
ultrawide curve monitors for my desktop
slashie laptop for my workstation. And
when I do have my laptop, it is just my
laptop. I don't carry the other things
with me because if I do need the
screens, I'll just go home and plug in
and basically have this big humongous
wall of screens. U anyway, digress. Good
thing, bad thing. Uh kind of the same.
Uh allin-one today. Uh wife came out to
the river yesterday, turned on the
water, had everything set up. We were
going to spend the week out since the
weather's nice and enjoy the river. And
our water pressure dropped within an
hour to nothing. We thought they turned
the water off because we didn't pay the
bill. Nope. paid the bill. Come to find
out, we had a broken pipe in the middle
of the yard. Took uh the plumber 48
hours to get out here to look at it.
Good news is they finally found it after
3 hours of digging around. Uh patched it
and I have water again after let's see,
I've been at this location. So, I've
been here for over 9 hours with no water
today. So, it it's been an interesting
day.
Well, the day is going to get more
interesting because we're going to go
back to uh sorry if I do dove right into
this, but this is our season where we
are taking a past season and we're going
to do it with AI. So, we take a topic,
throw it out to Chat GPT and say, "Hey,
what would you do if you were going to
create a podcast like this?" And uh we
start going. So, this time the title
we're going back to is Mastering Scope
creep, navigating the hidden challenges
in software development. And this is
back to the responses that's given in
the past where it's saying great podcast
topic that taps into a very real
pain point for developers, managers, and
even clients. It's also a perfect match
for your podcast theme of building
better developers below our ideas for
structuring the episode suggested
segments and discussion angles that
could engage your audience. So,
uh, they add a couple of podcast episode
title ideas, but let's just dive right
into the structure itself.
Item one, and I think this is back to
going to give us eight. So, we'll see
how far we get through this. What is
scope creep and why it happens? Define
it in plain terms with real world
examples. Differentiate scope creep
versus iteration or agile flexibility.
stakeholders. Who introduces creep?
Clients, developers, or managers?
Oh, wow. Scope creep.
I think I want to tackle the scope creep
versus iteration or agile flexibility
because
this is where I think a lot of people
get lost. Scope creep is when and and
this is my term. So if you look it up in
Wikipedia or something like that, if
it's exactly like my term, then let me
know because I need to charge them money
or something like that. But this is my
thoughts on it.
Scope creep is when we have defined
requirements
and we agree to the requirements and we
start working on the requirements and
now the requirements change. Scope creep
is essentially changing requirements.
Now this is different from uh iteration
which is where we go through with a
requirement. We complete it essentially
we review it we iterate and now we have
a new or a evolved requirement. So that
would be more the iteration side and
then on the uh agile flexibility side is
where in there when you get into ads
where we have requirements
from the from the start we'll say and
then as we go into a sprint we have
requirements the requirements that we
have at the start may evolve so that by
the time we get into a sprint and we're
actually working on that requirement it
may have evolved may changed may have
even you know disappeared it may be
brand new things like that scope creep
in that sense is not so agile
flexibility means that as we're going
through we can create new requirements
as we're going we can evolve what we are
building as we are working down that
agile path that's not the same as scope
creep scope creep and agile would be
that we set a uh requirement we say it's
done essentially and then we move or as
we get almost to done we move the
goalpost
So the easiest way to think of scope
creep is moving the goalpost. Scope
creep is more about changing what done
is essentially or what completing that
requirement is or what that requirement
entails as opposed to going back and
saying all right we're going to we're
rewriting the requirement and sort of a
little bit of it's not starting from
scratch but if you get that idea it's
sort of the idea of instead of changing
the requirement when you're almost done
change the requirement before you step
into it and it is very much a a squishy
you know type of area, but I think it's
something that we do want to make sure
that we understand when there's there's
a difference between being flexible or
saying that, hey, this is a bad
requirement and rewriting the
requirements versus scope creep, which
is really like stretching that
requirement out and making it into
something that wasn't originally
intended to be. Like I said, this is lot
of places we can go here, so I'll be
interested to hear what are your
thoughts on this.
Yeah. So,
it's interesting with scope creep
because scope creep
can to me I've also heard feature creep
and feature creep to me is different
than scope creep but they're kind of the
same. Um,
and there are also you mentioned
requirements. So as like you gave a good
explanation about scope creep but with
scope creep as you're working on the
project as you're working on features
you can run into issues where a feature
that was agreed upon for the
requirements
if that was 6 months ago depending upon
where you're at in the development cycle
that feature might not be there anymore.
So you could even run into a place where
hey you're actually building something
that is not that meant to be there
anymore. So you've run into a
requirement change and you are
essentially
it's not necessarily scope creep but
you've kind of diverged. You've gone
down a path a rabbit hole doing a
feature that was agreed to initially but
isn't there anymore and that's
it it it is it is similar to moving that
goalpost but it is not just moving the
goalpost away. You've kind of oh instead
of going in the straight line you've
kind of gone around the town. you're
building a bypass when you need to just
build the tunnel through the town. So
that's one of the things you got to be
careful of with scope creep and feature
creep is you have to make sure that you
do regular checkpoints. Rob talks about
agile and scrum all the time and is
perfect for this. But a lot of companies
even though they're trying to do scrum
or maybe they're not even doing scrum or
agile, they run into situations where we
talk about this once
right up to tickets and then just go off
and expect the developers to do it. And
if you don't do regular checkpoints to
make sure that hey, are we on track? Are
these requirements still fresh or have
they gone stale? And you could
essentially end up with a different type
of scope creep being meaning that you're
working on a project that really doesn't
exist anymore or has changed so
drastically that your scope is you're
working on features that are outdated
and that sometimes is the case is that
you end up in a situation where you are
you're building to the wrong you're
building to the wrong target. Um, that's
where I do I I very much agree that it
is important to do those regular
check-ins to make sure that are we
agreed that we're working on the same
path. For example, if you think of of
driving on the road going from point A
to point B, it may be that there are,
you know, that along that road, it makes
sense to follow that road. Those are
the, you know, that is the features
essentially that you're going. The creep
may be somewhere along the way that
you're like, hey, we need to, you know,
take a bathroom break or something like
that. that is not really as much of a
feature creep as more of like, hey,
we're gonna go take three days and we're
going to go have a vacation somewhere
else is really the the effect of a a
feature creep or a scope creep. The next
one, how scope creep affects developers,
burnout from
uh burnout from endless changes,
confusion about goals and ownership,
missed deadlines and technical debt,
loss of confidence in estimates and
planning.
Oh boy, that is those are all actually
really good uh issues. I think I want to
go with the estimate side because I
think this is a
this is an area where it is it almost
becomes I mean I hate to say it this way
but it almost becomes the equivalent of
a self-fulfilling prophecy. I have been
in situations where you've got a
customer that is uh whoever the customer
is, it could be internal, it could be
external, however it is, they are
driving the product that we're building
software for this customer and they're
sometimes it's they're not totally sold
on it in the first place because they
think it's going to run over or it's
going to be late or it's going to slip
or all the politics that can happen. And
what ends up happening is in some of
these is you have people that are this
customer doesn't really know where
they're going. They don't really
understand what they want to do
and then they start feature creeping is
they basically scope creep says they're
say hey we need um you know it's like we
need this report. This is so often this
where it starts. We need this report. We
need these five items and we need them
displayed this way. Cool. All right, we
have it and now we're going to push that
out there. And they see it and they say,
"Oh, wait. We need this other piece of
data. Oh, can we summarize that data?
Can we add totals? Can we uh we want to
be able to sort stuff? We want to be
able to filter. We want to be able to
run this for certain criteria that
initially were not included. You know,
initially it was like we just want to
run it for dates." And they're like,
"No, we want to run it for dates, but we
also want to run it for specific
customer or only specific employees or
specific blah, you know, all of that
kind of stuff." And next thing you know,
this little ritty report that should
have taken 3 hours and maybe did
initially now has taken 3 weeks because
the goal keeps changing. Everything
keeps moving and now everybody's
complaining. It's like, hey, this should
have been done a long time ago. Yes, it
actually was done a long time ago, but
then everything changed and those
changes make they cost more to change
than it would have had they been there
initially. because now this stuff that
you built for you built the solution for
one thing and now there's all this extra
stuff that's gets added on and the next
thing you know you're in a a death march
because of a you know a report or
something like that. So I think those
are where it gets really frustrating on
both sides because the developers get
frustrated because their estimates are
crap because as soon as they put it out
there they're held to the estimate but
now the requirement they estimated
against is different and so they know
that they're going to lose. they know
that they, you know, or if they change
it, then it's like, why do you keep
changing it? Well, because the goalpost
keeps moving. And on the customer side,
they're sitting there going, "Why do we
even ask for estimates?" Because we
never get an estimate that means
anything. They estimated 3 hours and now
it's 3 weeks later. And so, you end up
with this like everybody's pointing
fingers and stuff like that. And so,
scope creep can be very devastating in
that kind of sense as far as just the
trust, the estimation, the the planning,
the milestones. Uh I'm I don't know how
many projects I've been in that were,
you know, failing or failures that you
can point to changing requirements. And
before I pass it to Michael, I will give
the like the the epitome of bad like
this is going to go bad in that kind of
sense of bad requirements are these
kinds of projects where somebody is
like, hey, I need you to make eBay but
for dog food, you know, or something
like that where they they're like, well,
just take this this thing and I just
want to make it, but I want to make it
slightly differently and that's the
requirements or just use the existing
app as a requirement. ments and just
make something else that looks like that
but only better. You know, there's
there's too much wiggle room in there.
There's too little definition. And so,
whatever you're initially going to look
at, whatever you're initially going to
estimate, you're pro unless you're
really really good at like mocking that
thing up and spending a lot of time in
that estimation phase and basically
halfway building the solution or more,
then you're going to miss it because
you're going to have a different picture
in your head. So that being said, where
do you want to go on this one?
>> Well, you kind of touched on three of
the four bullet points, so I will go
with the one you didn't touch on, which
was burnout from endless changes.
Because literally everything you laid
out, you know, talking about the
confusion about goals and ownership and
missing deadlines and technical debt and
the loss of confidence in estimating and
planning, all those things lead to
burnout. You know, from developers
perspective, we've talked about being in
firefighting mode. This is not
firefighting mode. this is
I am working on a ticket and you know
I've agreed to the requirements of this
ticket and it's only going to take me a
day to get it done and next thing you
know you are 4 days into it 6 days into
it two weeks into it is like a
neverending death march when the hell is
this going to get done when are you
going to quit changing the requirements
of this ticket so that I can actually
complete something which goes back to
before you commit to a ticket. Make sure
that your tickets or the requirements
have a clear definition of done. What is
it that they want? If it changes at that
point, the ticket needs to close. Write
up a new ticket and define what
specifically it is that the new change
wants. Trying to cram it all into one
ticket is so much scope creep that you
don't you basically start out with
apples and you end up with oranges. You
the ticket never is what it was at the
beginning. Sometimes it is. Sometimes it
is simply okay what we thought this
change was going to be. You run into a
blocker or a situation where you can't
implement what it was or the way the
ticket was written up. You can't
actually implement it that way.
Sometimes that requires a pivot and an
update to the requirements of the
ticket. Sometimes that happens. That's
not necessarily scope creep. that is,
oh, this should have been a discovery
ticket because we found something that
wasn't there. So, in a sense, you could
keep that ticket open, re-update the
requirements to what it needs to be, or
really close that ticket, create a new
ticket based on your findings as to what
it is you need to do, and then focus on
that reestimate on the new requirements.
So, if you don't do this, you run into
again those situations where you're just
on that death march. You it's like
you're working on it. You think you're
done. Oh, you're told it's not done.
Well, why is it not done? Well, because
it needs this, this, or this. Well, that
wasn't in the ticket. Well, it needs to
be done. And you get into those loop
back scenarios where you just can't get
done. And burnout. I it it just is so
prevalent that it it these are the types
of tickets that will cause burnout. If
you find yourself running into like low
energy or, hey, I don't really want to
do this anymore or, man, I've been
really at this for a couple days, take a
time out, take a step back, revisit the
requirements of the ticket, and maybe
have a quick conversation with your
manager of like, hey, we need to reset
this ticket. Either close this ticket
and create a new one or really redefine
what it needs to be done and get it
done.
>> Yeah. Sometimes that's the when you
catch yourself in this situation that is
the best thing is to just like take a
deep breath step back and I' I've been
in projects where we've done that as a
group as a project group and said this
is we're we're churning we're stuck in a
rut something like that and it's better
to say okay let's step back let's look
at what we really want to get done let's
reassess some of these things and maybe
some of these things are a scope creep
let's just define them say okay we've
hacking on this thing for the last three
sc sprints. Let's step back. Let's
actually figure out what this needs to
be or pause it for a while. Go move to
something else while somebody else
researches it so we can get something
that is is much more stable. Um, in a
short bit here because I don't want to
go too long because this go really long.
Stories from the trenches. Share real
examples from your experience or
listeners that one project that never
ended or we rebuilt the same feature
three times. The we rebuilt the same
feature three times I'm going to say is
something I have run into multiple times
and it is a a warning that I have and
this uh I've seen this in many types of
projects the ones that happen a lot
anything that requires mapping or
integration
that there is this danger that includes
scraping projects that also recruits
anything that's a an ERP, uh, a CRM.
And the the problems with these projects
that are scope creep kinds of things.
Too often I found a customer comes in
and they're really not ready for that
tool yet. And when the implementation
begins, the right questions are not
asked and those don't surface until it's
later in the project. And now you have
to change things and sometimes rewrite
things. I will just because this was a
specific one. I'm going to I will talk
about a specific project that was like
this. We went in uh it should have been
a very straightforward project should
have been this is what it should have
been done in three four weeks something
like that. The whole point was the
customer knew what their data was. There
was a vendor that knew where that data
needed to go. All we needed to do was
pull the qu pull the data and then use
the mappings that the vendor said we
were going to use. Well, it turns out
that the vendor really didn't know what
the heck they were talking about. And
they were counting on us to tell them
where the data is supposed to go when it
was like, "No, you're supposed to tell
us. We don't know that system. We don't
know your system. We're you're supposed
to know this. You're the expert." That 3
to four week project. Um I wrapped up on
it I think nine months later something
like that. We were still going through
things. We had ended up changing
multiple times how we approached it
because the integration that we had
built we were assured that this was
going to work and then we found out that
no actually that that the target product
did not support that and then and it
goes actually to a report as well. there
was a certain report that they needed.
They're like, "Sure, we're going to give
you that, but they weren't giving it to
them in the way that it was needed." And
so, you ended up with all of these like,
"We changed the mappings, we changed the
approach, we changed the format, we
changed the structure, we changed stuff
over and over and over again." And it
was one of these things that should have
been a oneanddone, and we ended up doing
it over and over and over again. And
really it wasn't so I mean it was scope
creep but the real problem was is that
the scope never really got defined
properly. Everybody was thinking
somebody else is going to take care of
it and it didn't. And so that is a
warning. I will say that as a cautionary
tale to any of these bigger kind of
projects and integration kind of
projects where there is the where you
hear the word mapping involved then make
sure that the people that are involved
on the source and the destination of
those mappings understand what they're
doing. They're clear on who owns what
and how that needs to go because that
process doing the mapping often is the
biggest time sync the biggest part of
the development effort. The rest of it
is actually pretty straightforward. is
getting those mapping rights and any
translations between the two
uh in roughly 60 seconds or less. I
guess I'll give you a little bit of
time. So what's one give a if you can
give a quick example from your
experience.
>> So it wasn't so much scope creep but
illdefined expectations from a manager.
Uh I had built a modulebased
application. This was before containers
and all this, but I basically built a
containerized application that the
manager likes so much instead of using
the model and building on it. It was
copy and paste the project here, spin up
another project here, copy paste, do
this. We did that six times and then
when one feature that was common to all
of them had to change, we had to go
through every application essentially
redo it multiple times instead of having
one common application. It it was the
worst. I don't want to say it was
self-imposed scope creep by a management
decision because if your software isn't
built to scale or it's if you try to
treat it like a cookie cutter, you could
run into a situation where you get into
those uh situations where the project
never ends because one feature change
based that they think is a easy
requirement is not. It is something that
really should apply. If you have six
applications and it's a feature in all
six, you need to take that and multiply
it by six because it may not be a simple
change.
That is boy that is that is its own
little problem there is that the idea of
a simple change. Um too often I have
seen that as you know oh this is
something really and developers do it
just as well where it's like oh yeah
it's a simple and then it's not because
it gets underestimated and it really is
probably related to scope creep. Uh what
is not scope creep is you sending us an
email at info developneur.com. We have
had that requirement forever. That is
like that goes way way back. That goes
back dozens maybe hundreds of episodes.
Love to hear from you. Give us your
feedback. What do you think? What do you
like? What do you dislike? Uh and
obviously with any of these, what are
some examples you'd like to throw out
there? Because the real world stuff is
always very useful to us. And even
though it may be, you know, we may be on
to a different topic, it is uh we always
can find time if we need to. If you have
something interesting, we will swing
back around and just bring that up and
say, "Hey, by the way, here's a
flashback or we can use it as bonus
material for the YouTube side." So those
of you that are on the a out on the
audio version listening to podcast, we
also have the we have our YouTube
channel developing our channel and we
have all the stuff out there. We always
have uh pre and post show stuff
including every show we end with bonus
material basically unless we started
with a ton of bonus material then we
don't double up too much. You can also
reach us at X uh there's developer
developer.com is the best place to go
out on that site. You've got access to
all of our content, all of our past
episodes, all of our if you want to go
out to YouTube and look at it there. Uh
all of our presentations, just tons and
tons and tons and tons of content. It is
amazing how much stuff is out there. I
look at it sometimes, I'm like, "Oh my
gosh, we have I've forgotten more stuff
than we have, you know, than I can think
of that we've put out there." So, check
that out. Uh Facebook, we have a
developer page. Wherever you find our
all of the fine podcast products, you
can find uh developing our podcast. If
you find somewhere and you're not
getting it, let us know. We'll make sure
we get hooked up there. That being said,
we do appreciate you and your time. Go
out there and have yourself a great day,
a great week, and we will talk to you
next time.
Bonus material. Uh I am going to go do
like a super fast read through these
because we didn't get really far at all.
Uh, so four and I and then just pick one
whatever and you got in front of you. So
you can pick something where you want to
go after I read through this and I'll
see what I want to do. How to recognize
scope creep early subtle warning signs.
Can we just add one more thing? Frequent
changes without updated timelines. No
clear acceptance criteria or
documentation. How to put push back
without burning bridges. Soft skills for
saying no constructively. How to involve
project managers or product owners when
and how to renegotiate timelines or
budgets. Process and tools to prevent
it. Define scope up front. Clear user
stories. Definition of done. Agile
board. Sprint planning. Change control.
Versioning. Milestone check-ins and
backlog management. Documenting
assumptions. Mindset shift. Treat scope
creep as a symptom. What is the client
client really trying to say? Use it to
improve product vision or communication.
Good scope change is not the same as bad
scope creep. Developer tips. Personal
tactics at work. How to manage energy
and focus in evolving projects. Keep a
change log or scope journal. Estimate
with buffers. Create your own guard
rails as a developer. Uh there's a lead
magnet called action ideas. And we will
go with oh bonus segment ideas.
Roleplay. Clients asked to change scope
midsprint. How do you respond? Q&A. Take
listener questions about real life scope
chaos or tool highlight tools like
notion linear or jira that help. So what
do you want to throw out there for your
bonus?
>> Uh where was it? Um yeah. So, I like the
process uh where is it? Process tools
six. There it is. Process and tools to
to prevent it. Which kind of goes with
the bonus thing, you know, agile boards
like Miro, um Atlassian, uh Jira,
Trello. Use boards, use storyboards,
write up, you know, kind of brainstorm.
Don't just go into writing tickets
sometimes. Sometimes it takes walking
through the idea. Um, a lot of times
when I'm working with managers or
customers, I will pull out a sheet of
paper. I'll pull out my iPad. You know,
you bring up some type of drawing tool,
notepad, whatever, and you just start
kind of flowing through your ideas. You
draw it out, or you just kind of walk
through scenarios and situations on how
the application's going to work. So, you
can kind of flush out the direction or
the feature that you're trying to build.
So, there's a lot of things out there.
find what works for you, but sometimes
pen and paper work great or just simple
like notes or notepad and just start
kind of typing out your thoughts or just
um if you use ASKI docs or markdown,
throw up a little markdown script as
you're writing out u kind of the
requirements and then translate that
into a wiki that you have for your notes
for your developers.
Yeah, I think I want to those are those
are all great and I think I want to sort
of that leads well into what I want to
talk about which is not specifically
mentioned but is a clickable demo. Uh, I
have found that this is a great way for
you to get stuff in front of your
customers much like, you know, drawing a
picture and things like that, but it's
also a way to get it in front of them
and and make it real. Yes, it's nice to
use uh Figma and all those kinds of
stuff and build these things out and do
them pretty and sometimes you can do
that and put enough information into it
to give them a good clickable demo. But
what I like about one that is a what
I'll call a
evolving or a true clickable demo, one
that we often use is that we actually
build the demo. And this is a framework
going forward. So what they're going to
see is they're going to see the
evolution, especially in agile, this
works great is they're going to see the
evolution of the solution of the
application and you're going to be able
to put it in front of them. You're going
be able to get them a feel for what is
it? What is it like to sit there with
this application? What is the navigation
like? what is some of the get some
sample data in there so it starts
looking real to them because those are
the things that then they're going to
say well wait a minute I don't see this
or that value is never going to look
like that or that could never be exist
with that over there
those things are invaluable to avoiding
scope creep or at least getting the
scope creep covered sooner rather than
later so I think highly recommend it if
you have not done it, then give it a
shot. Uh, it's a lot of people are big
on the whole MVP thing and and stuff
like that. That's really not that far
off from the idea of a clickable demo.
Um, as always, if you want to if you if
you wonder how that will look, shoot me
an email at info developer.com or like,
you know, hit me up on the RB-SNS site,
schedule a call. I I have no problem
spending 30 minutes sitting down with
somebody and just saying like, here's
some things you can do. here's some
questions you want to ask. Here's how
you want to approach a clickable demo
because you're not necessarily going to
spend you're not going to get everything
done at once. And there's definitely
concerns in there about like having
something that's too ugly or too pretty
or not complete enough or too complete.
And there's there's a lot of caveats on
in that. But happy to try to get more
people to do this and get better at it.
Uh because also I think it'd be nice for
customers to have more of a feel like
what to expect in a clickable demo,
which is one of the key things you have
to do is set those expectations up
front. Just like we try to set
expectations to have like a certain
amount of length for our episodes, and
we're not terribly good at that. I mean,
I guess we're within 15 to 45 minutes an
episode over the all of these. So, we
have some reasonable faximile of of a
standard, even though we do move them
around a lot. But we appreciate your
time whether we go a little short or a
little long. We are going to wrap this
one up and we will be back before you
know it to run into our next episode
where we're going to continue learning
more about how to build a better
developer with AI. Well, really just
some AI input on our thoughts, but you
know how it goes. As always, appreciate
your time. All that you have done to
just like hang out with us. Feedback is
awesome. Love you guys. Have a good one
and we will talk to you next time.
[Music]