The Bright Side of Scope Creep

This is Building Better Developers, the Develop-a-newer podcast. We will accomplish our goals through sharing experience, improving tech skills, increasing business knowledge, and embracing life. Let's dive into the next episode. Well, hello and welcome back. We are continuing our season with happy thoughts. Looking at the positive of some of the things that challenge us on a, we'll say a regular basis, maybe daily, maybe weekly, and maybe you don't run into it that often, but when you do, you know it. This episode, we're going to look at the bright side of scope creep. Scope creep in itself can be one of the most frustrating things to deal with. We think we're there and essentially the goal line gets moved. We've got a good plan. We've got some requirements. We've got a product or project that we're working on and then the scope changes. And I say creep and I guess because of experience, it now, scope creep seems to have a, we'll call it a, an implied increase. And really it's implied because I don't know that I've ever had scope creep down. Usually we have to fight as much as we can to keep stuff scoped to the original level if you can do that. Sometimes in sprints, if you do the agile approach, you will occasionally see that where And I don't know, it depends on the way you guys approach it, where your team approaches it. Is it sometimes it will be, you know, let's say a goal of, you know, 10 or 15 tickets to get done. And because of the way the sprints run, instead of the 10, you get nine done or instead of 15, you get 12 done, something like that. In that case, scope creep, I guess, you know, actually may actually creep down. But when you look at it, the whole point of agile is to work with scope creep, that your initial requirements are going to change. And so, you know, it's one of those that you could probably look at it glass half full, glass half empty. The one I want to focus on more though is the, the bigger picture scope creep, where you've got a product or project and you start with one set of requirements. But as you go, they change, they grow, there's more things that get put in there. I want to look at some of the positives. The first one is really focused more on, it really happens when you have smaller items, the things that are not huge. And it is scope creep. And it can be a situation where you effectively nickel and dime yourself to death because it's, you know, oh, it's a quick thing here. Oh, it's a little ad there. And the next thing you know, you're weeks into this thing and there may be no end in sight. You may almost be on your way to a death march of death by a thousand cuts basically, where you have all these just, you know, this little thing here, this little thing there. And it's really hard to say no, because it's just such a small amount of work to get it done. Say, oh, we can take a few minutes and we can add that on. That kind of scope creep. Now, it can get very bad as I've just laid out, but on the upside, when you think of the old example of somebody's, say you're filling a bucket, then you start with these big huge rocks and it's full. And then somebody gives you smaller rocks and you realize you can fit the smaller rocks in and then they give you smaller rocks and you can feel it fits some of those in. And then eventually you can fit, you know, you put sand in there and then you can put water in there before you finally get it full. It's the same thing with some scope creep. It actually, for lack of a better term, makes sense. I mean, it always does to some point because there's a, there's either a business case or there's some reason that the scope is creeping. There's something behind it. It's probably not, I don't know if it ever is really, if you look at it, just because somebody wants to throw some extra stuff in there. Now maybe they want to squeeze stuff into this release instead of the next release, but there's, there's still, there's a reason for that. There is some method to that madness if you want to look at it that way. The nice thing about small incremental scope creep is that we can actually do it sometimes without impacting the final deadline. That we can put some finishing touches, a little tweak here, a little tweak there. And because it's such a small amount of work and it doesn't have, maybe doesn't have, either has zero or a very small testing impact, that it doesn't actually change your initial target dates and deadlines. It changes the effort a little bit. By definition, this is a small piece of work. So yes, there's going to be a little bit more work you're going to have to do. But ideally, we're talking about the situations where this is, you come back from lunch five minutes early or wait five or 10 minutes before you go on lunch one day or you come in a tad early, stay a tad late, and then you're done. You've got this new feature in. So in that situation, it is a great way to fill out your time. Ideally it's back to the example. Ideally you have these big block items and then you essentially have these scope creep items that start filling in those gaps so that you can actually put a little bit more into the bucket of that release. So that is an upside, is that scope creep can be a way to get more out of what you've already set up as far as your plan is concerned, your project timeline and milestones. You can get a couple extra features in there. Another thing with scope creep is that it keeps us from putting something out that's Basically to setting a course and then ending up essentially regretting it. It's a way to avoid regrets. I don't know how many times I've been involved in a project where we start out moving in one direction and there's more or less a vision of what this thing is going to be, this solution is going to be. And then as you progress, and this actually is why the Agile approach often is pointed to as being so effective, as you start moving forward and you progress and you actually have at least a straw man, you have wireframes, you have some functionality and you have a situation where people are starting to not really use but at least be exposed to what you're going to end up with, what that final solution is. When they start getting taste of the user experience, there are all kinds of things that we learn in those situations. Sometimes we learn that the problem we want to solve was not exactly the problem that we wanted to solve, that there was something else, that there's a, we thought it was one problem but it was another one. We may also sometimes have been in situations where the solution ends up being essentially more problematic than the original problem. And so you look at it and you say, oh, well, this is what we thought would work but because of maybe how many times we have to do it, then we've actually got to build a couple other features into this to really make it usable. A good example from a, this isn't really scope creep, but an example that we'll see a lot if you think about it would be, let's say a website and you put together a website and it's got some data entry and it's got some reports and a couple of features that people use on a regular basis. And once you start putting data into it, once you start actually using it to scale with the amount of data and the kind of timeframes that would be expected in production, you end up in a situation where it's just, it's too slow. Maybe the reports take hours to run or the data entry is maybe a little clunky or maybe when you hit save, it's slow enough that you can go make yourself a cup of coffee and come back and it's just then completing the save. The things like that that we see that are more or less performance kinds of issues, but they are the things that will show up as you get further into an application, into a solution and having that scope creep of saying, well, wait a minute. At first we thought we'd be good just providing a solution, but as we've gotten further into it, we realized that the solution needs a couple of other features in order to make it real, to make it worthwhile. This is a, the positive of this is actually quite a bit. If you had no scope creep, if you lock it down completely, then you end up in a situation where you have to put something out that may not be as useful and then you have to come back around in another release, another version, and then pick up those features that make it usable. In doing so, you're forcing potentially forcing a whole nother round of testing and regression and the costs of that extra version, that extra release can be sometimes substantial. Scope creep, which is again, goes back to an argument of why we have it at times. Sometimes scope creep allows us to get stuff done in a manner that is less expensive or less resource intensive than it would be if we instead said, nope, we're going to get to the end of this product and then we're going to make some changes. Then we're going to add onto it. You know, if we can kick it into the, kick it down the road and pick it up in the next release. Another thing that scope creep gets, gives us it's a positive is typically it comes from feedback. As we've talked about in the other positives, people start not using it as probably strong, but they start having an exposure to our solution, to the user experience, to how it works. To how it scales. And what you get from scope creep is you get a, it's a basically a quick feedback mechanism, a very short feedback loop where you go out, you do some stuff, people are using it and before you've actually released it, they say, wait a minute, here's some extra things we need. So they're pointing out effectively where usually there are weaknesses in your solution. Now it may be things where it's, you know, you've got a minimally viable product, everything's good, it does solve the problem. And now people see where it can be extended, let's say into other lines of business or for other usages. That scope creep, it's a little different, although it still does as a positive, that still is a feedback response. People have looked at what you've got and it's lacking. That's why there's that scope creep. But the more important ones, the bigger positives are the ones where the scope creep comes back and it points out where maybe there's some critical flaws or some major weaknesses. And actually just the process, even if you don't actually add that scope creep items into your product, into your solution, the product of people making those requests or that process of them making that request gives you an idea of where your strengths and where your weaknesses are within your application. If your solution is super awesome, then they're not going to have any, there are no scope creep requests. If your solution is lacking, then you're going to have a lot of requests and you're going to have a bigger, we'll say a bigger fight, a bigger challenge in not getting those, you know, doing those things, adding those things into your requirements and getting those into this release versus the next release. And that's a, we've mentioned this before, feedback, especially good, solid, honest feedback, particularly as in scope creep where there's a, it's not just a, this doesn't work or this doesn't work good enough. It's a, here's some things that we think will make it work good or better. Those are huge. Wouldn't we love that if every time we had to do technical support, it wasn't somebody saying, well, this is broke and that's it. They were saying, this is broke. Essentially this is how it's broke and this is where we think the solution needs to be. Now, of course, if we could do that, I'm not sure how often they'd even call us, call technical support because they'd already know what the solution is or have some good ideas at it. And that's what scope creeps get creep and gives us is essentially they've gone out, they've used it, they liked it to some extent. And it's basically saying I like it, but I would like it more if we did this, whatever that happens to be in the, the irony of ironies, I guess. Also, I think the last thing from a positive view that I want to mention of scope creep is that it allows us to do more stuff with the solution. Sometimes it is frustrating and it does cause slippages and it causes us to adjust our schedule and we've got to make some changes and we may have to put more work or effort in than we were going to originally. It can be frustrating as well when you think you're almost done. You're like, hey, by the end of this week, we're going to have this thing done and be able to ship it and then scope creep. And now you're working on this thing a week from now, two weeks from now, a month from now. That can be disheartening. But on the upside, looking at it as we are, we're people that like to build solutions. I think it gives us a two for one because it gives us something we can whine about if we want to. If we feel like we want to complain, we can complain about the scope creep. But if we want to look on the bright side, we get to put more stuff into the software, which I think most of us would rather do. We would, if we were given three options, put less stuff in, put just the right amount stuff in or put more stuff in more requirements into a solution. Most of us are going to pick the more requirements and it's not because we want more, we want to build more hours or we think that it's going to help us in some way financially or anything like that. It's just to us, I think most of us, it's just cooler to do work where you've got a lot more features. We like to show off our products, our solutions. And the more bells and whistles you have, the more things you have to show off. So scope creep itself, while getting there, the work may be annoying, you know, maybe a nuisance, the payoff at the end of it, I think often is worth it for us. I think we're much happier to have something that's got more features that is, let's say, closer to a viable solution and maybe a maximum viable solution or something along those lines, as opposed to an MVP, a minimally viable solution, you know, minimally viable product. Rather than put the smallest amount of effort in, we'd rather put more in. And, you know, usually unless there's some reason we need to, you know, paycheck or something like that, we're okay if that deadline slips out, if we can put a little bit more in and build something better, which is one of the challenges we have. Sometimes we get close to the end and we are the ones that say, wow, we're almost there. So it's a good time for us to sneak a couple more things in because we're practically done anyways and the next thing you know, we're the ones moving the goal line. So I guess it's a little bit of perspective there. It depends on who's looking at whether it's an positive or a negative when we're dealing with scope creep. And of course, it's what is the functionality or the requirement that's being scope crept. Is it something that's coming in? Is it something that we want to do? Or is it something that the customer or the business wants to do and we don't, you know, we don't want to, maybe it's something that's a headache for us or a piece of technology we really don't want to deal with. I think it comes back to taking a step back and take a look at, you know, what do we really think? Is it really the scope creep or is it really just that task alone? We don't care if it was in scope or not. We just would be unhappy with it. Challenge of the week. Think back to your last project and was there scope creep in like the question one and question one B who caused it? Was it scope creep that essentially you caused or the development team caused by bringing up some points and pushing that, Hey, here's some features we need. Or was it the customer that did that? I can send a resting look at those kinds of situations. Sometimes that gets lost as you get further down the road. But looking back, you realize that, Oh, this was actually something that we did or actually something that the customer did or however it works out. But however it works out, as always, we got to get back to work and get out there and have yourself a great day, a great week. And we will talk to you next. Thank you for listening to Building Better Developers, the Developer Noor podcast. For more episodes like this one, you can find us on Apple Podcasts, Stitcher, Amazon and other podcast venues or visit our site at developernoor.com. Just a step forward today is still progress. So let's keep moving forward together.