Mastering Scope Creep: Navigating the Hidden Challenges in Software Development

Welcome to Building Better Developers, the Developer Nord podcast, where we work on getting better step by step, professionally and personally. Let's get started. Hola, we are back again. This is Building Better Developers, the Developer Nord podcast, where we, well, for one word, are multilingual and not very well. I am Rob Redhead, one of the founders of Development Nord, 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'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 roadmap, 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 forwards with the best ROI on one of these most expensive pieces of your business. Good thing, bad thing. Literally, those of you that are watching, those of you who are not, shame on you, you can watch this on YouTube. Those watching will know that I have a little side monitor. I played around with these for a while as part of my being a remote developer. For my laptop, I worked with a couple of things. Initially, I had a nice big thing that you could mount on a laptop. I've got two extra screens and it's pretty cool. The only problem is I want to travel a lot and those were heavy, so I went to a wider monitor. In doing so, I have now got one for my wife because it worked out. 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. 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, 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 my money. 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, 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 Milosz. I'm one of the co-founders, 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 your little throw out there. So I have two 48 inch ultra-wide curved monitors for my desktop slash IE 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. Anyway, digress. Good thing, bad thing. Kind of the same, all in one today. Life came out to the river yesterday, turned on the water, had everything set up. We're going to spend the week out since the weather is 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 the plumber 48 hours to get out here to look at it. Good news is they finally found it after three hours of digging around, patched it, and I have water again after, let's say I've been at this location. So I've been here for over nine hours with no water today. So it's been an interesting day. Well, the day is going to get more interesting because we're going to go back to, sorry if I 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 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 it's given in the past. We're saying great podcast topic that taps into a very real, very common 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 they add a couple of podcast episode title ideas, but let's just dive right into the structure itself. I don't want, and I think this is back to, you know, we're 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. It's scope creep versus iteration or agile flexibility. Stakeholders, who introduces creep, clients, developers, or managers? Oh, wow. Scope creep. I think I'd 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 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. This is different from iteration, which is where we go through with the 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 agile flexibility side is where, in there, when you get into agile, we have requirements 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 have changed, may have even 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 in agile would be that we set a 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 rewrite the requirement. 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, changing the requirement before you step into it. It is very much a squishy type of area, but I think it's something that we do want to make sure that we understand when 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. This is a 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. And there are also, you mentioned requirements, so as like you give 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 six 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 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 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 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 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 target. And that's where I do, 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 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 the 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 is more of like, hey, we're going to go take three days and we're going to go have a vacation somewhere else is really the effect of a feature creep or a scope creep. The next one, how scope creep affects developers. Burnout from, 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 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 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, whoever the customer is, it could be internal, it could be external, however it is, they are driving the product. So 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. 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 as a basically a scope creep. So they're going to say, hey, we need, you know, we need this report. This is so often 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, 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 days and they're like, no, we want to run it for dates and we also want to run it for a specific customer or only specific employees or specific blog, you know, all of that kind of stuff. The next thing you know, this little reading report that should have taken three hours and maybe did initially now has taken three weeks because the goals keeps changing. Everything keeps moving and everybody's complaining. That's like, Hey, this should have been done a longer 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've 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 get gets added on. And the next thing you know, you're in a death march because of 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? 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 three hours and now it's three 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 planning, the milestones. 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 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 or something like that? Or they're like, well, just take 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 and just make something else that looks like that, but only better. 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, 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 four days into it, six days into it, two weeks into it. It is like a never ending 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 right 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, OK, 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 re-estimate 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. 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 loopback scenarios where you just can't get done and burnout, it just is so prevalent that 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 of days. Take a timeout, 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've been in projects where we've done that as a group, as a project group and said, this is, 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 been packing on this thing for the last three sprints, let's step back. Let's actually figure out what this needs to be or pause it for a while and go move to something else while somebody else researches it so we can get something that is much more stable. In a short bit here, because I 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 in this. Uh, I've seen this in many types of projects. The ones that happen, anything that requires mapping or integration, there is this danger that includes scraping projects that also recruits anything that's a, an ERP, a CRM and 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, 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 where you're supposed to know this. You're the expert that three 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's a cert 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 up over and over and over again. And it was one of these things that should have been a one and done. 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. It's getting those mapping rights and any translations between the two. Uh, and roughly 60 seconds or less. I guess I'll give you a little bit of time. So what's, what, give it, if you can give a quick example from your experience. So it wasn't so much scope creep, but ill-defined expectations from a manager. Uh, I had built a module based 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. 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 it one common application. 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 simple change. That is what that is. It, that is its own little problem. There is the idea of a simple change. Um, too often I have seen that as, you know, Oh, this is something really quick. And developers do it just as well where it's like, Oh yeah, it's a simpler. 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 and info to philipanduor.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? Cause the real world stuff is always very useful to us. And even though it may be, you know, we may be onto 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 art on the audio version, listening to podcasts, we also have the, we have our YouTube channel, developing our channel, and we have all the stuff out there. We always have a pre and post show stuff, including every show we end with bonus material, basically, unless we started with a ton of bonus material that we don't double up too much. You can also reach us at X, uh, there's at 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 fine podcast products. You can find 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. Thank you for listening to building better developers, the developer nor podcast, you can subscribe on Apple podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember just a little bit of effort every day ends up adding into great momentum and great success.