Continuing Agile Manifesto - Part 2

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're continuing our season and we're looking at the Agile Manifesto. We're doing a deep dive into it. And we're starting out with the 12 principles. Now you may, if you're following along at home, we've worked our way through the first one, which is, this is key. We're going to come back to this again and again. Starts out our highest priority is to satisfy the customer. So we went into that one, the second, the third, the fourth, and then we got into the fifth principle. And that 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. Now, last episode, we only got through the first sentence. We only talked about building projects around motivated individuals. That was an episode to itself. So we're going to continue on that. Focusing first on give them the environment and support they need. And maybe we'll talk about trusting them to get the job done. So give them the environment and support they need. What, what does that mean? Now we've talked about it to some extent. And we've, we touched on that in the, in the last episode where we talked about a situation where you, you've got to have the right tools. You want to have stuff that helps you be productive. And that may be a technology tools. It could be, and this is really gets into sort of the support side of this, but it could be having a, um, for example, a frontline tech support group so that your developers are not getting hammered with technical support questions all the time that somebody else could, could easily handle. Uh, the support is also really, this is more of a, you know, a bigger thing is essentially getting obstacles out of the way so that people can get their job done. And there are definitely many managerial, uh, books and processes and things like that, recommendations that essentially say the same thing as a manager, they, they set it up that your job is to clear the way for the people beneath you that work for you to get their jobs done. And if that works, if everybody does that in an organization, then when you get down to the, you know, whatever you want to call them, the worker bees are the people that really, you know, that are actually implementing things and creating things, then they are as productive as possible. And ideally that's what the, you know, the management and leadership do. You, that's why you're there. That's the administrative side of stuff is getting things out of the way. So the people that are, we'll call it doing the work can get the job done, can get that work done. And now the support, I think ties very much into trusting them to get the job done. This isn't, this is really a, in some cases, it's a flip from what some people would think about when you think of a very heavy handed micromanaging, make sure that everybody clocks in and validate what they're, you know, make sure that they're doing the work they're supposed to do. And particularly if you start adding, you know, reports and time sheets and all this kind of stuff, it becomes a burden and it's going to slow down the process. Now, again, this doesn't mean that you don't track any of that stuff. This is more about, you know, trusting them to get the job done is. Push it and getting away from micromanaging as a manager in particular. This is a, a thing I've run into more than a few times as a manager of a technical team, you may not know enough about what they're doing, about what they're working on, there's going to come a point unless you are the developer or whoever that is, the tester or whatever it is, unless you're that person, unless you're really digging in with what they're doing, you're going to have to trust them. You're not going to be able to understand that what, maybe what bugs are, that they're the bugs that they're being challenged by or the, the design that they're, they're working through or the time that's spent crafting that design or approaching the problem. So instead of, you know, maybe harassing them or second guessing them, you let them go and get the job done. And that can be very difficult. And like I said, this is a, this was definitely a change. And I think it's still something that we struggle with a lot, because if you're a, a leader or a manager who more or less, you know, you're, you're on the hot seat for the people that work for you. You want them to get stuff done because if they don't, then you're going to hear about it. And it's not, you know, it's more complicated than that, but that's, you know, to simplify it, you want to make sure they're getting the job done. Well, if you're, you know, constantly second guessing them, if you're trying to dig into stuff and trying to understand things to the level that they do so that you can, you know, effectively be in a situation where you, you know, you know, you can answer every question about it, or you could, you know, almost effectively step in and help them out to some level. Then you're, you're going the opposite direction. You're not scaling yourself and your ability to view the project and direct resources. Instead, you're getting sucked back down into the weeds. And that doesn't help anybody. It hurts you as a leader because you're going to be sidetracked by all these things that you don't need to be worried about, or at least shouldn't need to be worried about. And it's not going to help them because then they're going to end up constantly going back over and essentially defending what they did. And that it kills morale and is not productive because you're going to end up doing everything at least twice because you're going to do it. And then you're going to have to go out, go back and essentially explain how you did it and why you did it or where you're at. And it just becomes too much of this, too much feedback. So the support and trust, I think do go hand in hand. This is, but the support, the environment is set them up to succeed. Support is while they are doing things, work with them to make sure that you're helping clear the way for the obstacles that may be there for them in a timely manner. And this is going to be some sort, there's got to be some sort of a rapport there so that they have a way to notify or highlight issues that need to be addressed. And so then as a leader or a manager, whatever that person, that manager can address getting those obstacles out of the way. And of course, trusting them is once you get the obstacles out of the way, let them go, let them run. They don't have to do it necessarily the way you would do it as a manager, as a leader. And they just need to get the job done. And if you don't have that, if you don't have that trust, if you don't have that support, if you make them feel like they're having to work extra, then you're not going to get that project done, particularly as you get a large project done. Because people end up leaving or they'll get frustrated in their productivity or reduce whether they want it to or not. They'll be sidetracked with these other things and thoughts in their head or arguments in their head or whatever about, well, shoot, we got this done. It should be good enough or whatever, the grousing that can suck away productivity. And this goes back actually, this whole thing really does go tie back once again into actually several of the principles, but that highest priority is satisfy the customer. When you trust them to get the job done, that's your team, that's the team. When the team is trusted to get the job done, one of the things that disappears is barriers to communication with the customer. I think this was a huge issue before and it's gotten better. But if you go back to the 60s, 70s, 80s, 90s, probably, tech people were considered, and a lot of places, they were considered almost unable to talk to the customer or talk to the business. This is a wide brush, but I think most people would say that some large percentage, 70, 80, 90% of the people that were doing the implementation were not able to have a useful conversation with the customer. So they had all of these, you had this hierarchy of project managers and leaders and managers and all that kind of stuff that kept that direct communication from happening. This is where the people that did put together Agile Manifesto looked at that and said, look, that's not helpful. If you can't trust them to get the job done, then do something to alleviate that, get them training. Or if it's a personal thing, you just don't trust them, then hire people that you can trust. Yeah, it may seem sort of cold-hearted or whatever, but the bottom line is, trust is a two-way street. So if you can't trust anybody, then you're not going to get a project done. But if it's the team, if there's something about the team that breaks that trust, then you need to address that, and probably as a team. Because this is not just the leader or the manager, although that's very important. But part of that is that that trust has to go both ways. That has to trickle down into the organization. Because it's not just managers and leaders that may end up second-guessing. You have customers do it. I've seen this, the customer technology trust, be an issue way too many times as well. Where you have something proposed by the technical team, the implementation team, and the business ends up getting into the technical side of stuff and says, well, couldn't you do it better in this or that? The kiss of death to a project to me is when you have a customer that's trying to figure out, especially a non-technical customer, is trying to figure out what programming language the development team should use, particularly without the implementation team's input. And say, that's a decision you should need to make. And vice versa, which is much more common, I think, is where you get the technical... It's gotten better. I don't want to paint too dark a picture. But where the technical, the implementation team will decide that we need to do these things this way, which are business decisions. That we need to change this process. And then just say, well, the process you use isn't very effective, so we cleaned it up. Well, if that's not done with the business, trusting the business that they know what they're doing, then you could end up in... You could do stuff. You could create a process. It's really cool, but absolutely useless because it doesn't take into account things that the business side knows. So you could look at this. This is an excellent principle that you could use as a stick against somebody basically and say, hey, you're not giving the right environment. You're not providing the support that's needed. You're not trusting us to get the job done. Well, that has to go both ways. That environment is not just the implementation environment. The implementation team has to work with the customer, with the business representatives. There has to be an environment where support or tools or however you look at it, where there can be conversations around decisions that need to be made. Where the business side, the customer can report issues and provide enough details for the implementation team to correct those. It can be as simple as things like there needs to be some sort of bug reporting mechanism and some process to be able to track how's the work on the bug going? Has this been validated as a bug? Are we working on it? What release is it going to be in? Things like that. In all of this, hopefully as you start reading through these, I think you'll start seeing where a lot of the modern software, hot topics or hot approaches to software become needed. The Scrum approach, the daily stand-up, these things where we're basically, and this is sort of getting to a core of how Agile works, is you start replacing documentation with in-person. It can be a problem sometimes because you do want to have some sort of history of documentation of decisions and preferably why those decisions were made or what was thrown out for consideration as part of that decision. Sometimes you don't need that. Sometimes you just need the group to get together, make a decision and move forward. You don't need documentation of it. While documentation might be nice, it's not as important as getting people together and solving the problem, getting the job done. When you look at that, when you look at get the job done as a primary goal, a primary objective, then things like creating a productive environment, getting support for those that are doing work so that you are removing obstacles as much as you can to allow them to focus on the work instead of them having to do administrative stuff and things like that. Now, I want to swing back around to that because there is value in estimation. There is value in tracking how we did. This does not mean that you don't provide estimates, that you don't track hours, especially because sometimes you have to. Part of a project is you've got to build the right hours to the right place. You need to assign the right hours to the right place so that you can do a retrospective or review or some sort of measurement of how you did because you're not going to get better if you don't know how you did. Or if you do, it's only going to be blind luck because if you can't look at how you're doing and analyze that and look for potential issues, then you're not going to be able to move forward better. This is where maybe the project itself, a single project in a vacuum, maybe it doesn't need to worry about estimation and stuff like that as much because you just do it and you're done. You're not going to try to reproduce anything out of that. But that's, I think, very rare. Even in, and we've talked about this, even inside hustle where you're just doing your little individual projects, it is helpful for individually to get a better understanding of how you estimate work and how you get stuff done. And if you're going to be able to look at how you got it done and see if there's adjustments that need to be made, are there things that you need to change priority wise? Is there a schedule change that will help you? Some of it's simple stuff like do you work better in the morning or at night? Or is it work well for you to do a big batch of time? Or is it something where you can sort of pick at it and do a little bit of daily progress versus maybe weekly progress or even monthly progress? Maybe your best way to do stuff is to take one weekend a month and just go heads down and make some progress. And of course, that's assuming that that's even feasible for you, but maybe not. Maybe it's better for you to sort of, for whatever project, and this could vary as well, for you to do a little work and then let it sit on a back burner in your mind for a while, then come back and do a little work. That's part of the environment that you're going to try to define for yourself to be as productive as you can to get the job done and get from point A to point B in the shortest possible route. So giving the environment support and trust is something that was, again, I think a change because you have to realize that when you're building software, the people that are the team, the people that make up that team are people, they're individuals. They have roles and they have responsibilities. They have skills. They have experience. And if you treat them as a commodity, as just another cog in this process, then you're not going to get as much out of them as you are when you allow them to utilize their skills to the best of their ability. Allow them to bring in their specific experiences, their opinions and ideas, and allow them to help contribute to the project. You will find, you will get a better end result out of that. One, because you may get some incredible ideas out of people that you, you know, sources you never thought. And two, it's going to make everybody feel more valuable. And it gets to the idea of being that first part motivated. They may not be the motivated individuals, but it's going to help increase the motivation of the entire team. You get everybody working, everybody pulling together. I think that's easily, you know, you can think of the old thing you've probably seen several times where people tug a war versus, if they're not tugging in the same direction for tug of war. So I think that's good. We are going to be able to knock this principle out in a mere two episodes. And it's, I think this is very key though, because this is attitudinal. It can be some other stuff. Some of it's a process and the tools and things like that, but this really gets to the heart of your attitude as you go into a project. I mean, obviously, motivated individuals would be an attitude, but environment support and trust are so key. And I can spend a season probably just going through experiences where having an environment and having support and having trust has been huge and being successful and not having those were very big obstacles to overcome. And I'm sure if you've been out there in the world more than a year or two, and maybe not, I mean, you may almost get that immediately. It's just one of those things that I think we all know it, and this is maybe where a lot of these principles are. We all sort of know this to some extent. It's just they put it in words to help communicate that. And I think for us, we can say, yeah, that makes a lot of sense. And it's something that I think we can look for if we are looking at opportunities or if we're going to go do a side hustle or if we're changing jobs or something like that is maybe that's a good question to ask. Am I going into somewhere where there is going to be an environment and support and trust or not? Because if it's the or not option, then maybe you can shuffle along to the next one. And this is a red flag too. If you get into a project and you find that it's not there, then you may want to get your way out of that, find your way out of that as fast as possible. Because I've seen that as well, and often that does not end well. Even in some cases when the product, the solution gets done and is delivered and all of that, it still ends up being a failure to some extent because of the lack of trust and people keep trying to go back to a well that shouldn't be. They shouldn't. So it's one of those where you keep trying to push for more as opposed to saying, okay, we crossed the finish line. But that is for another episode. For now, I'm going to let you get out there and free up for the rest of the day. And hopefully you go out and have a great time in an environment that is productive for you where you've got a really supportive team and people trust you to get the job done. And of course, since people trust you, don't let them down. Get out there, work hard, be that motivated individual, and you'll find that you will be better as well as perceived much better because people like a motivated employee or coworker. But however it is, 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 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 a day is still progress. So let's keep moving forward together. There are two things I want to mention to help you get a little further along in your embracing of the content of Developer Noor. One is the book, The Source Code of Happiness. You can find links to it on our page out on the Developer Noor site. You can also find it on Amazon, search for Rob Broadhead or Source Code of Happiness. You can get it on Kindle. If you're an Amazon Prime member, you can read it free. A lot of good information there. That'll be a lot easier than trying to dig through all of our past blog posts. The other thing is our mastermind slash mentor group. We meet roughly every other week, and this is an opportunity to meet with some other people from a lot of different areas of IT. We have a presentation every time. We talk about some cool tools and features and things that we've come across, things that we've learned, things that you can use to advance your career today. Just shoot us an email at info at developernoor.com if you would like more information. Now go out there and have yourself a great one.