The Agile Manifesto - 12 principles, focusing on the 5th principle: 'Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.'

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 are looking at the Agile Manifesto. Particularly right now, we are focused on the 12 principles that they lay out. Looking at each of these in an episode and dig a little deeper into what it says for us, how we can apply it, and how it's often applied in the real world today. This time, we are looking at the fifth principle. There is no priority. I just want to go back and highlight that again. There's no real priority to these principles. There's no order to them. It's just as they laid them out. Other than maybe where it says specifically, our highest priority is to, yes, if you've been following this season so far, you probably remember by now, highest priority is to set a goal. And that goal is to satisfy the customer. So that fifth principle we're going to talk about today is, quote, build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done, end quote. That is a world of meaning in that there's so much that goes into that particular principle that we may even go a second episode just on this one. That first part, build projects around motivated individuals. To some extent, you may say, OK, yeah, we get it. A motivated team is a better team. But this is not just the team. This is not just leadership or managers or something like that. Although they can definitely impact that. You can be a positive or negative impact on morale and general motivation. These are people that are invested in the project to some extent. That may be because they want to do something self-centered, selfish, I guess, like advance their career or something like that. Maybe there's an altruistic reason. Maybe they have some axe to grind with the universe that their specific set of problems that they want to solve. But all of those are motivational reasons and factors. And when you've got a project that has people motivated to get it done, it's more likely to get done. I think that is almost obvious or at least common sense. If people don't really care about it, they're not going to put in the work. The interesting thing here is it's built around motivated individuals. It didn't say that you have a motivated development team or a motivated customer base or something like that. This is everybody. Since it's built around these motivated individuals, then that means every piece, every area, we should have some motivated individuals, at least one and probably more. And of course, this is built around motivated individuals. That means that not everybody on the team has to be driven to get this thing done. But you do have to have some that are motivated to get the solution done correctly. And they need to be motivated enough that that spills over into the team, that they can drive things forward when it needs to be. There's always going to be, and I think this may be part of the seeds of this particular principle. There are always going to be points in a project where it is undefined as probably a strong term, but it has the opportunity to drift. There is a need for somebody to step up and either make a decision or take on a task that otherwise could be just sort of left behind. A good example of this would be testing. You can go all the way through a project and shove it out the door. And as we used to say, you can skip the testing and pass the savings on to the customer, noting that there are no savings involved there, just maybe in your time. But that means that the customers are going to have to face the headaches of most likely buggy code. This is something that can be skipped to some extent. But if it is, it's going to cost you. That is not going to be a quality product of any sort. And there are other areas. There are lots of little things as well as some big things that we need to get them done. That's part of crossing the T's and dotting the I's, as they would say, or the finishing steps that make it a professional project or result, as opposed to something that just a bunch of people got together and kicked out the door. You've got to have those motivated individuals that are almost, well, they're essentially advocates for the project itself. These are the people that will stand up and say, hey, this is what we have to do. Or, hey, we're starting to drift away from either our core principles or maybe our timeline, our milestones. And it's something that we see even in personal stuff. We talk about this all the time where you maybe set up a to-do list or some goals for a day or a week or a quarter. And if you don't have accountability, then if you miss one, if it doesn't quite work, you're going to have to go back and do it again. But if you've got somebody there, whether it's yourself or somebody else, that sort of prods you or nudges you and says, hey, this is something you said you're going to get done, maybe you should go take a look at that and try to get that thing done. You need people that are going to hold the team accountable to get the job done in the way that it should be done. And this is the kind of thing that we see in personal stuff. And this is really key to getting things moving forward. And you probably, depending on how long you've been around the professional world, you probably have seen some projects that have essentially floundered and maybe eventually just sunk into nothingness because they didn't have the right somebody that owned it or somebody that was motivated enough to get it done. And this can be sometimes very big things. Documentation projects are famous for this in the IT world. We have people that say, yeah, we need to document this stuff. We've got to build this thing out. And it never gets done because there's other things that can be done. This is why we have the idea in the sprint world of technical debt. It actually exists elsewhere, but other places. But this is something that we use on a regular basis. There are things that we said we were going to do that we haven't gotten done yet. I'm summarizing, but that's roughly what we're falling into in that case. Situations where there's things that should be done and we're at least keeping track of them to say, yeah, we should do that. Now it may take those motivated individuals to go pull those things off the back burner, out of the backlog, and say, okay, this has been wasting away back on the backlog for way too long. We need to get it done. You need to have champions within your team, within your team, within your team. The fast all the facets of a project in order to make sure that everything works. If you just let stuff coast, it isn't going to work out right. You're going to have issues. You're going to have things that fall between the cracks. And you're not going to have anybody that cares if you don't have the right motivated individuals to do that. These are the people that will carry you. When you get to that last 20%, that is the most difficult 80% of a project. These are the people that say, yeah, we need to go into that area. We can't just go with the easy 80% and be done. Because there are going to be opportunities to quit. These are the people that say, no, we're not going to do that. And it can range from developers to the product owner, the product manager. It helps to have a sense of what's going on in the community. And it can range from developers to the product owner, the product manager. It helps to have someone or some people whose job responsibilities and roles are to be those motivated individuals, to push stuff forward. Because if it's your job, if you get paid to do it, that may be motivation enough. I would say it helps to have people that are motivated by more than that. Because there's a certain point where money just isn't enough of a motivating factor. There needs to be something else in there. And it doesn't have to be, it could be something very simple like being proud of the work you've done and things like that. Some people are motivated, whatever project they're on, they're motivated to do it the best they can. Others are rarely or maybe never motivated. And then most people I think fall in between. There's some things that we are drawn to or enjoy that we're going to be more motivated to do than the things that we don't enjoy. The next little piece of this one, give them the environment and support they need. This is often a challenge in the IT world. I think that even though we have a lot of technology tools, it is not uncommon to run into situations where there's budget issues or things like that. That restrain a whoever it is that's building out an environment from building out the environment they need to build. This is, this could be a big challenge. It's not only going to slow things down. Sometimes it can make them downright likely to fail. A good example would be somebody, by somebody, some organization that or faceless individual, however we want to look at it, that is setting up the budget for a project and helping to drive the environment of doing that project. And they decide or it's decided that in order to save money, we will buy a nice big production server and that's what we're going to work on. That's it. We'll just go ahead and do our coding and testing and everything on the server because it'll be nice and big and it can support what it needs to support as far as user base and stuff like that. And then of course, you know, they may even say, and we're going to save deployment and stuff like that because we'll never have to worry about deploying code because we'll just do it there. Do it live on the production server. That is a recipe for disaster. You aren't giving the team the environment they need to do the things they need to do. They don't just need to implement. They don't just need to code. They need to be able to do some testing and validation and acceptance and demos and things like that. If you don't have an environment that supports that, then those functions, those roles are either limited or eliminated. And this includes things like, it goes all the way down to the machines, the environment that developers and developers are using to do the things they need to do. If you've got somebody that's that doesn't have modern office software and stuff like that, so they're sitting there having to write, you know, project managers having to keep track of everything and notepad or on pencil and paper and then having to find some way to do that. Maybe they're not. Maybe it's a situation where an integrated development environment would be a vast improvement from what, you know, from just writing the code and then having to do the things that they need to do. This definitely reminds me of a manager I had many, many moons ago that brought me to the computer. I had a manager that I had a lot of trouble with. I had a lot of problems with. I had a lot of problems with the computer. Well, if you don't give them, if you don't provide that, then there's going to be struggles. This definitely reminds me of a manager I had many, many moons ago that part of his signing on to take the role as development manager for this software company was that the development team was going to have the essentially the latest, greatest machines and access to the latest and greatest machines and operating systems and stuff like that. And this goes back more than a few years. So this is where you had Windows 3.1 that most places use, but Windows NT was coming out, some things like that that made for a little bit better development workstations, in some cases much better. And it was simple stuff then where it was things like, you know, it had to have a CD. People will, this is weird that even think about it these days, but had to have a CD-ROM attachment so that we could install stuff quickly. It had to have the, they had the maximum memory they could support, which I think was like 16 meg, not gig, but meg. Maybe we could go to 32, I can't even remember, but you know, you had just, you did what you could as that development manager. He did what he could to set up an environment where the developers would be comfortable and have the tools they needed so that those were not a detriment to getting the job done. And this goes actually back to the first point. Motivated individuals, one of the things, you know, you can increase or decrease that motivation. You can be a plus or a minus to morale. And if you have a difficult environment to work in, then that's going to be a negative to morale. That's going to be a demotivator. People are going to come in and say, gosh, I have to go sit at an uncomfortable desk where I can't, you know, spend half my time scrolling around on the screen because it's so small that I'm trying to read what I'm doing. And it's just too painful. Or I have to connect to a network that half the time doesn't exist. It keeps dropping connections or I work for a while and things get lost because my machine falls apart or, you know, I have to reboot or, you know, there's all kinds of complaints that we can have. And those things are going to slow you down and they're going to leave a bad taste in the mouth of the team members that have to deal with it. It is an expense to put together the right environment. But I have found that in every case where that expense was embraced and an environment was built to do what needs to be done, to get the job done, to make people, provide people the tools they need and an environment that is conducive to getting the job done, to doing the work that they want to do. That is going to raise general morale and motivation. So you give them a place to work that they enjoy working in and that's going to help motivate them. Now I do want to push this a little bit to the idea of side hustles and doing your own home office, particularly at a time as we're getting more and more into a, you know, at least a season, if not longer, where people are doing a lot of work from home. They are working remote far more often than they used to. If you're doing that or if you are pursuing that, think about that. Think about that environment that you have that you either have built or are creating for yourself to work. There's a lot of things that go into having that kind of environment and you don't have to get them all right from day one. But I think these are things that you should consider and put them on your to-do list to find ways to address those things. And some of these are things we take for granted if we've been in an office environment for a long time. Simple things like a desk that allows us to do our work in the way we need to do it. Not some small little corner of a table, but something where maybe we can read our notes and take notes and talk on the phone in an uninterrupted way. And there's not a lot of background noise or background distractions where we can actually focus or maybe even shut a door or something like that so that we can shut the world out and focus on the work that needs to be done. A comfortable chair. If you're going to be sitting in that chair or sitting at work for many hours a day, that gamer chair maybe that you have may not be very useful for that. Particularly if you're trying to set your laptop on your knees or something like that. Or laying in bed all day with your laptop on your lap may not be, definitely is not the ergonomic recommended way to go about it. So we have a lot of little things that we can do to make ourselves comfortable. And I think you need to do that and think about it. And it is one of the things that I think it will come up over time. So it's maybe a good idea to take notes. So maybe you need to get some better lighting or a comfortable chair or a desk or set aside a place, some location that works for you getting, being productive. That may help motivate you so that whatever your side hustle is, you can help feed that motivation because you have the environment that you need. Now, as I alluded to, there's a lot to this one. So I think this one we're going to we're going to actually spill over into the next episode and visit this one again, because there are a lot of there's a lot that comes out of these. You know, this little three lines that they have of this principle on the Agile Manifesto. But for now, before I go too much further into this, I think I'm going to cut you loose and let you start your day. So 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 Nord 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 Nord 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.