Welcome Changing Requirements, Even Late in Development

This is Building Better Developers, the Develop-a-Noor 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 where we're looking at the Agile Manifesto. And in this portion, we are looking at the principles, the 12 principles that they laid out all those years ago in the Agile Manifesto. We have hit number one, and now in this episode, we're going to just go in top to bottom. We're going to look at principle two, and that is, quote, welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage, end quote. Now, even before we start into this particular item, remember from the first episode, our highest priority is to satisfy the customer. Keep that in mind as we go through each of these items. So now, looking at this principle, welcome changing requirements, even late in development. That is a game changer. There has been so many instances where changing requirements, particularly late in development, are not welcome, are frustrating, are sometimes almost devastating. I have seen requirements change that are big, that dramatically change the approach, the focus, sometimes even the architecture of the solution. Now, you can argue that you should have gotten done a better job when you initially got your requirements or you architected the design. You should have known that was going to happen, but that's not always the case. This goes back to when we're doing requirements gathering and architecture design. One of the questions we probably will ask somewhere along the way is along the lines of, is this something that would ever change? Is this something that is set in stone? Do you need to support potentially a greater scope ever than what you're laying out here? A simple example would be, do you ever need to have users that are also grouped in some way, part of an organization or something like that? Or is a user always going to be a standalone user? I see this all the time, particularly if you look at e-commerce. There's a lot of situations where there is a e-commerce user, whether it's B2B, B2C, whatever it is. This could be an end user or an administrative user. But even an end user is very simple. Are you selling to, really, is this B2C? Are you selling to consumers? Are you selling where every invoice or transaction is tied to a single account? Or is there going to be a situation where you have to support a business or an organization where there is some sort of a link or roll up of invoices and transactions through individual accounts and eventually into some, you know, to some master or organizational account? These are sometimes very critical architectural decisions to make because you're going to, that's going to impact the relationships of data. And yes, you probably should, when you can, avoid coding yourself into a corner. So if there is a potential that you would need to have some hooks to get into a certain way or to store stuff in a different, different relationships, then if you can do so. But there's also a cost in doing that a lot. The more general you make your solution, usually the more costly it's going to be. And there are benefits. There are benefits. There are performance increases you can get when you can make assumptions instead of having to cover situations maybe that never occur. So changing requirements can be difficult. But this is where we go back to. Our highest priority is to satisfy the customer. So if there's a change to the requirements, it most likely and should come from the customer. Which means if we started out with a set of requirements that they said, you do this and this is going to satisfy us, we will be satisfied. We will like this, be happy with this solution. And towards the end, they change their mind and go, oh, wait, we need to change some of these requirements. And it may not be as simple as a change in their minds. There may be some sort of governmental requirements or restrictions, industry standards, laws and compliance and all kinds of other things that could force requirements to be changed. And maybe platform stuff. Maybe they start out with a desktop application. But by the time they get towards the end, they realize that none of their users are using desktops anymore. They've all, in the last 12 months while we were writing software, they've all their customer bases converted over to phones, mobile, something like that. So sometimes these can be dramatic requirements changes. But this is interesting. And you start with we welcome those even late in development. This attitude is huge and difficult to push to customers. I found even in consulting situations where they are directly paying me for my time to do work for them. I have come across situations and a lot of them where there is a hesitancy to change requirements. Now, sometimes it's due to cost where they say, if we change this, you know, is this going to cost a certain amount that's going to be a blower budget or something like that. But sometimes it is just, I guess it's a human thing that people feel like they've, you know, even though they're paying you, they've asked for these things and now they don't want to change what they've asked for. And then, you know, change the scope of things, even though you're going to get paid for it. It's sort of like it's putting you out. And that's on us as developers at times as well, because I know that all of us, including myself, but I never leave NFC. I've seen this with others as well, where even though you're getting paid and it's essentially a benefit to you to make those changes and to go back and do the work. There's this frustration because, and it sometimes shows because you're not, you thought you were going to be done and you're not. That's probably the easiest way to put it. And probably the most often mental attitude that triggers that. It's like, oh, we're almost done. And then the requirements change. It's like a team that scores the go ahead score late in the game. And then the other team turns around and ties it back up or goes ahead. And now they thought they were going to be able to cruise to victory. It's like, oh, no, we got to get back to work. Same kind of thing. But the welcome change of requirements is an is an attitudinal thing that it will benefit us as developers to to embrace. We should always be looking to satisfy the customer. We should always be happy to discuss with them adjustments, even down to the requirements that will make them a winner, that will make them happy, that will satisfy them, that will solve the problem in the way it needs to be solved for them. So not just a system or process that accepts changing requirements, but one that almost asks for them that we definitely welcome. And we should because the changing requirements, even late in development, if we reject them, that doesn't mean that those requirements don't exist. That just means that we are most likely taking away from our ability to satisfy the customer. Almost by definition, because now they have slightly different requirements and we're not meeting those. So we need to embrace change, even in the requirements. And now that doesn't mean that we just like, oh, yay, we've got to rewrite everything. But it does mean that we look at it and we say, OK, this is a this is a small change, maybe, or this is a large change. But if it's a if it's small change, we can usually just roll with it. If it's a large change and maybe we talk to the customer and say, OK, this is a substantial shift in what we were doing. So this is what we're going to need to do to make sure we incorporate it. I don't think it should ever be something where it's, if you really want to do it, this is what it's going to take. If it's a true requirement. Now, this is different from, let's say, pushing. I hate to say it this way, but pushing to the next release. There's definitely a lot of situations where that is the right approach. It not quite is the same as an MVP. But is the same kind of mindset saying that, OK, we're this goes back to actually the first one early and continuous delivery of valuable software. So if the requirements change, can we deliver something valuable and then handle the requirements change? Whatever that whatever's needed to implement that or do the requirements? Did the requirements change in a way that what we thought we were going to deliver that would provide value now technically doesn't or doesn't provide as much value as we need to do a release. Maybe it provides minimal value based on what we've already provided. But we want our attitude to be one that promotes the communication of that. This is this is something I've struggled with over the years and trying to make sure that I cross the board. Have situations and environments that essentially draw out requirements from customers. Because they're not always quick to do it. And like I said, sometimes it's not necessarily your attitude towards them. It's them trying to keep something on time and on budget. But I very frequently will say, you know, is there anything else doing? Is there something we can do here? If I get a sense that there's maybe a requirement adjustment, then I'll dig a little deeper into that. And, you know, we'll often say, look, some things, there are some changes we can make that are not going to really impact the budget or the timeline. Yes, there are big things, but a lot of times they're not that big. And so I try to draw that out of customers first and say, well, just let me know what the changes are or your requests. And then we'll take a look at them and then figure out if they're big or small, because some things that customers think are very big are actually very small and vice versa. So you just get it all in front of them and say, here, here's what we've got. Here's what we put out in front of you. Give us a feedback or let us know where you're the requirements that we talked about maybe need to change. And then we'll put together an approach, recommend an approach to get this done. And you guys can say, yes, you guys, the customer can say, yes, that's valuable enough. Let's do it or not. Or let's get this thing done, part A done, and then we'll come back and address these changing requirements in part B. But the goal is always satisfy the customer. If they have changing requirements, we need to know about them and we need to have an environment that makes them comfortable and understanding that requirements are welcome and that we are teaming up with them. We're partnering with them to get something built that will provide value to them. The second part of this one, agile processes harness change for the customer's competitive advantage. This is where we need to be. This goes back to that first part, really welcome changing requirements. And this is where we need to be an advocate for the customer to not only understand their problem definition, but understand the environment that that problem lives in. It is not enough to just read the customer's requirements. We need to really understand why those requirements are. Now, we don't have to go be a CPA or legal specialist or something like that, depending on what the customer is. But we do need to understand their environment, their why for those requirements. Because when we know what their why is, that allows us to team up with them and consider ways that we can make some adjustments and make things better. Now, in the agile world, since we are doing that early and continuous delivery of software, presumably, let's hope that we're doing that, of valuable software, that means that we are getting feedback throughout our software development process. We've delivered something early that's valued, that has value. The users are, the customer is using it, and now they're giving us feedback. And so with that feedback, we should be seeing from them, most likely, there's going to be, I don't know if it's full blown changes to requirements, but we're probably at least going to see adjustments, particularly in prioritization and things like that. But we also see, may see very new requirements or dramatically changed requirements that deal with user experience and things like that, but also maybe gaps in knowledge. Maybe sometimes you end up in a situation where you don't really understand the solution until you start working on it, until you start actually implementing. It's one thing to say, here's a saw, go cut that tree down. It's another thing to actually go spend the time with a manual saw cutting a tree down if it's got a very, very thick trunk. It's, you know, there's things that are, you know, oh, on paper, okay, that's no big deal. And maybe even on paper, if you say you're going to take this on, it's going to take you 45 minutes to cut that tree down. Okay, I'm going to go spend 45 minutes. Well, you know, 30 minutes into manually sawing your way through a tree, it's going to be very painful probably. Unless you're some muscle bound Goliath, you're going to be sore. You're going to be tired. Yeah, so there's things like that. It's, there are things that we don't really comprehend or really understand completely until we do them. You know, something on paper is not the same as real life. And so getting this product out in front of people in front of our customers and getting feedback should be an opportunity for us to not only provide them what they wanted, but actually add value. So not only are they satisfied, but they are more satisfied that we've provided a greater value to them. And that is, again, as an attitude that a better developer can take to their job, whatever their role is, is to always be hungry to find ways to satisfy the customer, to find ways to add value. Even if it's an adjustment of requirements or your approach, you say, hey, look, you know, we looked at this as it being this type of solution. But with a little work or maybe even a little forethought, we can make it this bigger solution or this more valuable solution. Goes back to that earlier example. You know, you can have a single user, but it wouldn't take much for us to add in the design the ability for users to be grouped under organizations. And there to be some sort of relationship between users. And there's all kinds of different ways those relationships may work out. And maybe initially they say, no, we don't need that at all. But as you get further into the process, you see ways that you can make some changes that would bring a lot of value, maybe even open up a whole other market for your customer. Those are the kinds of changes we should be looking for. We should not be. This really goes back to the heart of being a better developer. We should not be a coder. We should not just look at requirements and write code and that's it. Almost that can be automated. There's definitely code generators out there to some extent. We as better developers should be looking for ways to thoroughly understand a problem and provide even better solutions than our customer would put together. And this doesn't mean that customers don't know how to code so we can just we can write code and they can't. This is even from the user experience side of things because customers can put together some of them can definitely put together and envision screens and buttons and flows and things like that. This is helping them even beyond that. You know how to build something that is fast, that's reliable, that's scalable, that's easy to maintain. A lot of things that a user customer typically is probably not going to think about too much until it becomes a problem. Performance is not an issue until your application is too slow for your customer. Then it's a problem. Otherwise, you may never even think about it. If you've got a web application that delivers pages in under a second to everybody, you're not going to hear about anything. And so if you go from under a second to under half a second, nobody's probably nobody's going to care. But if it takes you 20 seconds to deliver a page and you cut it down to 10 seconds, that alone is going to be an improvement. But you're also going to hear about it because they're going to want it to be faster than 10 seconds probably. So that is our second principle. Again, we welcome changing requirements even late in development. Agile processes harness change for the customer's competitive advantage. Again, even though they didn't mention our highest priority is satisfied customer, notice that once again, they focus on the customer's competitive advantage. We go back time and again in this season. We're going to look at why at the bottom line, the most general sense, why do we build software for the customer? Challenge of the week. When was the last time that you had to struggle with that you were presented with, we'll say, changing requirements? How did you react in that situation? Did you react in a way that would promote that customer, whoever that was that you were working with, to change requirements in the future? Or you did it in a way that maybe would make them a little hesitant to do so? Something to think about because your attitude, your response may be one of the ways, one of the quick things you can change even, to help your customers do better. Change to provide a competitive advantage to your customer. And that being said, time to get back to our day, time to get back to work. But as always, get out there and have yourself a great day, a great week. We will talk to you next time. Thank you for listening to Building Better Developers, the Developer North 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 developer.com. Just a step forward today is still progress. So let's keep moving forward together. Hi, this is Rob from Building Better Developers, the Developer North podcast. We're excited to be on Alexa now. You can enable us by simply saying, Alexa, enable Building Better Developers. And we will be there ready for you every time you want to listen to your now favorite podcast. Whether we are your favorite podcast or not, we would love to hear from you. So please leave a review on Amazon.