Responding to Change over Following a Plan

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. Hello and welcome back. We're continuing our season where we're looking at the Agile Manifesto. We have dug through the 12 principles. We're now looking at the four key points, the essentially pairings of values, and we have worked our way to the fourth of these. In each of these cases, the starting part is that we're uncovering better ways of developing software by doing it and helping others to do it. Through this work, we have come to value and we get to the point for this week, which is responding to change over following a plan. Now I do want to reiterate before we even dig into this, is that in each of these cases, both items have value. They specifically follow up and say that is while there is value in the items on the right, we value the items on the left more. So all of these things are important. It's just which is more important, which has potentially greater value, which is more likely to contribute to satisfying the customer. And so in this instance, we're going to look at responding to change over following a plan. This would be, I think to most people, a somewhat obvious statement as a couple others that we've already looked at. I think everybody knows, yes, following a plan, that's a good thing. But being able to adjust and responding to change is a better thing. The interesting thing that I found in all of this is that when you think about it, they had to state this. And when you think about it, you probably can see examples where following a plan was the primary focus. There's actually, and we do this a lot, I think. It's not just an organizational issue. It's even personal things. People aren't always happy about change because it requires change. They have to adjust their point of view, how they approach stuff. And sometimes plans that were developed and invested in have to get thrown out. Now that doesn't mean that planning is a waste of time, particularly when you add the, essentially the reality that things are going to change. There is going to be change in a project. It's almost inarguable. Now I think there are those that will say, hey, we can put together a plan. We can lay out all the requirements. We can spend enough time and enough investment into the process that we can put together. We can lay out a series of requirements and we'll get them fulfilled and we don't have to worry about it. But things change. It's not even in our control. You may have industry switches. You may have global events that change all of your plans. Considering that I'm in a post-COVID world of 2020 that changed a lot of stuff, I think that's probably a prime example. What you plan for a month from now, six months from now, a year from now, that's not necessarily going to be the world we live in. That's not going to be the environment you're working in, the market that you're competing in. And there are plenty of stories about this. If you look at or go back to listening to entrepreneurial stories and little businesses that became big businesses and success stories like that, there are a lot of cases where an organization started off in one direction and sort of stumbled into a different direction that became their flagship service or product. And so responding to change in those cases actually was the key to success. We've already talked about change as a competitive advantage. And this is something I wanted to spend a little time on this before we go over the point itself. Change as a competitive advantage. We sort of glossed over it before. And I think we maybe, most of us understand that to some level. But when you think about competition in most cases, and this is even true in the business world, there are the competitors. And for the most part, they are doing roughly the same thing. If you think about it in a race, well, let's say you've got multiple runners. So you've got maybe some that are trying to sprint as long as they can and then maybe arrest and then continue the sprinting. Or somebody that sets a certain pace, a high speed pace. Or maybe somebody that, another one, they set a pace, but then they want to have a really solid sprint at the end. Maybe some people even have some things, the style of running. So somebody maybe was running on their toes. Somebody else is more of a, I don't know, a heel to toe. And I'm trying to over analyze running. You can see where there are slightly different approaches. It's a different way, but they're all running the same race. Business, although there are more ways to vary your approach, it's still the same thing. If you've got two companies or multiple companies competing to create a word processor, there's certain things that all of the, every word processing application is going to have some of the same stuff. You're going to be able to type. You're going to be able to delete. You're going to probably be able to copy and paste. Simple, you're going to be able to set fonts and sizes and colors and things like that. But how that is done is going to help distinguish products from each other. And if you are in flight, if you are working with your competitors or not, with your, you're working against your competitors at the same time, sort of in parallel, trying to build the, you know, get the better product out the door, then your ability to respond to change is your ability to add on a feature or to incorporate an integration that suddenly could become an advantage to your product. I would say that, here's a good one, is there's been talk about a cashless society and a push towards more electronic transactions and things like that. Let's say you have a point of sale software and somewhere along the way, let's say cash becomes illegal in some of your markets or all of your markets. Or maybe you were building pieces, which is actually a good planning thing as well, because maybe you're building pieces to handle cash transactions. Well now you don't. And maybe now because of the conversion to cashless, there's some sort of a national or worldwide standard for how transactions are done, much like some of the medical transactions where you have HL7 and stuff like that. If you, with your product, can respond to that change, that's a new requirement, that's a different thing, then you're going to be ahead of that competition. If they aren't, they're going to go ahead and push their product out, they'll have this cash feature that isn't useful, and they're going to end up having to do another version. Meanwhile, you respond to change, you get out, maybe even if you get out a little bit later to market than they do, but you've incorporated that, then you suddenly have got the more full featured or we'll say appropriately featured product. So responding to change is key. And this is with big things, big features, but also with little features. And it's not even features, it's approaches, it's processes, it's communication. Because we have these different players, these different groups and individuals that are part of the team. There's going to be changes in understanding. There's going to be changes in desires and goals and approaches and things like that. Not on a big scale, but there, it may be, for example, you have to flip-flop one section that you were going to focus on with another one. Maybe you were going to do printing early on, but some printer drivers are missing, so now you have to do printing later on in the product. These are sometimes essentially minor changes, but minor is in the eye of the holder. It's minor if you can respond to the change quickly and without impacting your project. It's major if you can't. And so almost by definition, if you can respond to change, more change will be minor. If you're not good at responding to change, every change is going to be major. Now, following a plan is, I think in the software development world, I think it sometimes gets a bad rap, much like documentation in general. Because the itch is to implement. In a lot of cases, that's also the progress, the marker for progress that developers live under. How much code did you generate? What features did you get done? How many tickets did you complete? How many tasks have you coded? Things like that. So it has a implementation-heavy valuation. The thing about a plan is that it allows you to do the implementation faster. If you plan a trip, a physical trip from point A to point B, then part of your plan can include things like proper rest stops and refueling and food and things like that so that you can have a more pleasant journey. If you just skip the plan, then there may be things that you miss out on. Maybe you are hungry and you stop one exit before a place that has your absolute favorite place to eat and you end up eating at some dump just because you're hungry, as opposed to if you planned it out, you would have gone one more exit and been able to eat at a place you liked. Or I guess the worst case would be if you don't plan your refueling stops, you could run out of gas and end up on the side of the road. So there is a need for a plan. If you want the extreme case of it, there is an old saw that when you plan for war, as soon as the first shot is fired, the plans go out the window. They're worthless. You can plan all you want, but immediately once the game starts, basically once the battle starts, then things change. You may have planned for a lot of stuff, but now there's things that are going to be different and you have to react to them. So you have to respond to the change. But that doesn't mean that even though that plan may not be valuable or as valuable as soon as the shooting starts, it's still an important process because one of the things when we put together a plan is being proactive with things. We look at situations, we look at how stuff possibly will lay out, and we have certain situations that we're going to plan for, that we're going to address. This is how we do it. This is how we work through this. And it does allow us to avoid what we'll call rookie mistakes. And so following a plan gives us that stronger foundation to work on, which probably makes it more likely that we're going to be able to respond to change if we plan out some key things. And in this case, I'm thinking more along the lines of development processes and standards and procedures and things like that. When you put together that plan, the goal is to give yourselves enough momentum in habit-building tasks that even when you're responding to change, even when things are hectic and frantic, you're still doing some of the work, the tasks, documenting the things that need to be documented in a way that it doesn't look like a complete train wreck when you look back afterwards. You sort of take it in stride. You think about a boxing match. You get hit. That's what boxers do. They get hit at some point. And you'll see that they plan for that. They plan to get hit. So when they get hit, they sort of shrug it off. Now somebody lands a really heavy hit or it's a bigger hit than they expected or they get hit somewhere they didn't expect to get hit and things like that. They don't respond to that change maybe as much. But that's what the planning does. That's the value that putting together a plan and following it gives us. As we say, even if we get punched in the head and feel a little woozy, we have this plan. We have this goal. And so it's not just the procedures. It's the goal setting. It's the milestone setting. This is how we're going to do this. This is how we're going to proceed. And it gives us something to essentially funnel the changes into. So instead of a change dragging us off course and getting us to go in a completely different direction than we wanted to, to go address that change, instead we find ways to pull the change, to incorporate the change into our plan, if that makes sense. And I think if you think about it, it's just like draw a straight line, which is your plan. And that gets you from point A to point B. Straight line between the two. So that's the shortest path, right? Well, now some change comes in. So there's some data point off of that line that you drew. Now either you can change the direction of that line to go out to incorporate that point and then try to find a way to start changing the direction back to get where you were, back to the initial destination. Or you can do things to try to move that change point into or closer to the line that you planned out. It's maybe a subtle distinction, but it is definitely one that is very valuable in being successful. There's a difference between allowing that change to drag you off course and trying to drag that change into your course. And I think that's where we see responding to change vary from person to person or group to group and situation to situation. Sometimes the change is something that we think that we can just take in stride and it's not going to knock us off our planned path. And then sometimes that's the opposite. We see it as something that is going to derail us. It's something that's going to take us off of our path. And so now we're off the path and we've got to find a way to drag everything back onto the path. Or we may lose our path entirely and we just start going off in a slightly different direction and at some point decide that we have to make adjustments to get back to our original destination. So the plan is important. We want to draw that straight line from point A to point B. But responding to change is more valuable. How we handle those data points that are outside of that straight line that we drew and how we drag them into our path or I guess allow them to drag us away from our path is going to be a good measure of whether we're successful or not. So the challenge of the week. How do you handle responding to change? Do you take in stride and say, okay, we're going to find a way to make this work with the plans that we made or do you allow it to become too much of your focus and it actually takes you off of the path you were on? And this may be something that's probably worth considering whether it's personal things or any part of your life. Because I think if you can respond to change, if you can find ways to absorb change into the path you were going, the plans you had, the goals you had set and absorb that change in a way that doesn't take you off track, you're more likely to be successful. That is why we, I think, typically have sort of an admiration of people that can just cruise through big times of change is that they just, they take it in stride, they find a way to adjust and they move forward. So that's something we need to do in the software world as well. But more importantly, what's a greater value than all of these things we've talked about is for you to go 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 Noir 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 developernoir.com. Just a step forward today is still progress. So let's keep moving forward together. One more thing before you go, Developer Noir podcast and site are a labor of love. We enjoy whatever we do trying to help developers become better. But if you've gotten some value out of this and you'd like to help us, it'd be great if you go out to developernoir.com slash donate and donate whatever feels good for you. If you get a lot of value, a lot. If you don't get a lot of value, even a little would be awesome. In any case, we will thank you and maybe I'll make you feel just a little bit warmer as well. Now you can go back and have yourself a great day.