Wrapping up Season on Agile Manifesto

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 and wrapping up our season on the Agile Manifesto. Let's look back at what we've talked about. We've covered in these last 30-some-odd episodes. We start out with the Agile Manifesto. We looked at the 12 principles and the four essentially pairs of values and how those, the things that we valued in column A more than column B. That was, that's really the foundation for everything else that we've talked about. And really, it is the foundation for modern Agile software development. If you go out to AgileManifesto.org.org, then you're going to see what those principles are. You're going to see what those values are. And those are key even when we talk about things like Scrum and Sprint and stream programming, all of these things that have sort of come out of, that are Agile, that have sort of come out of the Agile Manifesto. We go back to those things that are key. Those are the things that are the why that we do all of these different things and goals that are, I think as we walk through them, pretty, they make sense. It's common sense that those are, as you think about them, things that we really want to do. I want to return to that Manifesto a little bit one more time as part of this wrapping up the season. We have talked many, many times now, that primary principle, our highest priority is to satisfy the customer right there, full stop. That is what we should be focusing on when we're creating software. It's easy to get sidetracked into so many other things, but the bottom line is that we need to satisfy the customer. And I think in that first principle, it follows up through early and continuous delivery of valuable software. Now though, we talked about it within the context of a project, of getting software out before the project is done, before the complete solution is available, but getting something out there for them to review, hopefully working software that they can adjust to review so that when the full product is there, they're ready to hit the round and go. But if you even take it outside of that context, the whole reason we do this is we're solving problems. We are removing pain points from people. And it makes perfect logical sense that if there's something painful, the best thing to do is remove it as soon as possible, remove that pain. And that is the overarching thing that we haven't really talked about, is that Agile is aimed at finding a way to get the best or let's say a complete solution to the customer in the shortest amount of time. Now we did talk about situations where maybe with small projects and things like that, Agile just doesn't make sense because it's just that you don't need to iterate. You just know what it is. You don't, you pretty much, you have a solid idea of what you're building and so you don't have to worry about the Agile approach of being flexible and being able to handle changes and requirements and pivots and things like that. says if we don't know exactly what we're aiming for, we will get there faster through this approach than we will the traditional approaches. And hopefully we've set some examples up that you at least acknowledge that if you don't, even if you don't 100% agree with it, is that you can see where that would be the case. And that's I think something I want to leave you with as we wrap this up is that Agile is not a silver bullet. It is an acceptance of reality for a lot of projects that we aren't real good at setting requirements. We aren't real good at designing for change. And I think we've seen that if you've spent time with many projects at all, you'll see that that'll come up. I don't know how many times I've run into those kinds of situations where I talk to a customer or a product representative, product owner, and what you end up with is a question somewhere along the way of will you, is this something you will always do or is this something you will never do? Or is this something we need to support that is sometimes a very critical step in the design? We're walking through the requirements, we're looking at things, we have questions, we being the development team, the design team. And we need to know certain things from a business perspective to make sure that we design them properly so that we don't design ourselves into a corner, but also that we don't design something, that we don't over design it. We don't over architect this thing that's super flexible and scalable if it doesn't need to be in certain areas. There's always going to be tradeoffs that we're talking about. And Avdol says, hey, we don't always know what the, I guess the end value is, for lack of a better term, so that we can properly decide whether something needs to be designed for or not. You know, whether there's going to be decisions that just too often things will change and we will end up having to adjust to those changes. And so anything that has a decent amount of time, and by decent amount I'm saying probably or longer project and probably a little more than that. Maybe a month and a half to two months would be your low end. If you're within that kind of a project, you can probably get away without agile. Well, you can definitely get away without using agile, but there's definitely that point where agile starts to become more and more likely to be a high value approach to take. If you're talking short projects, just the amount of time from start to finish is going to be short enough that you probably won't have significant changes. And if it's not a, again, it's not a huge project, you're talking a month or two of work, then most likely, then you're more likely that you're going to be able to do maybe traditional waterfall or something like that, some other approach that you may not need agile. Now there's a lot of other things that, and that's what the principles when you talk about actually delivering software. When you go into the values though, that's where you start seeing, I think agile becoming more likely, more attractive as an approach because of what it does, of what its focus is. I think a lot of the other processes, in my experience, both in, on paper, reading through these processes and also in reality being part of teams that are implementing these processes, the value, the goal of satisfying the customer is, gets lost because there's these other things that we have to do. There's these documents we have to produce. There's these steps we have to take. There's this administrative piece that we have to deal with for that process that doesn't directly point to providing software that satisfies a customer. Now you can argue that those things make it more likely that you will get there, which, it's better than nothing, definitely. There is definitely a method to the madness of these other processes. I don't want to denigrate them, but they have an approach to getting to the solution that is usually aimed at being essentially foolproof. It's not that you can't do them wrong, but the goal of these is to line up the tasks and define the things that need to be done to a level that most people are going to be able to look at and say, okay, this is what we need to do. And sort of dragging you along saying, okay, you need to do this, you need to do this, you need to do this. And there's nothing wrong with that. However, one of the key values and risks of Agile that we talked about is the team itself. These other processes are driving the team to do things a certain way because it's safe. It does not unleash the team to do stuff the way they, you know, to self-organize and do things in the way that is best, that the team is best suited to do. It says this is a way that you can go, and if you do this right, then you will be successful, but it ignores the team. And this is critical when you look at the skill, when you look at the skills and experience, when you look at what the team can do as a team together, when they work together, when they are focused, when they have the same goal, it becomes, the whole becomes greater than the sum of the parts. The team can do more than the individuals can. And that, I think, is where you see a lot of developers, developers, not coders. And you will see this. I think if you talk to developers versus coders, you'll see developers more likely to want to embrace Agile. Coders, the people that are just not as confident, they're going to struggle more. And partially because it's not, this has that loose, almost informal kind of structure, where if you're not confident in what you're doing, it's going to be sort of scary. You're going to want to have the comfort of a structure to get things done. But as you get further along, when you look at highly skilled and people with solid experience, things like that, that are part of a team, then you realize that you can leverage that and use the team and their interactions and their ability to drive a project, to do it much better than if you say, here's a format, here's a template you need to follow. And that's, I would think that makes complete sense. In any case of a template, a template says, do this, follow these steps, this is how you do this thing. It doesn't, templates don't allow, generally speaking, they don't allow for you to improve upon them, they don't allow you to change them. You just follow the template, plug this stuff into the template and you're off and running. When you have a team, when you have resources that are, I would say, better than average, probably even average, even if you're talking an average team, as far as skill and experience is concerned, if you allow them to use their specific skills and experiences and differing opinions and things like that to work together to get to a solution, you're going to get a better than average results. And of course you have a better than average team, it's even more so. Now there can be issues where the team is highly skilled and doesn't work together, we've talked about that. This all comes back to teamwork and that's what Agile really unleashes. And that's why you have people that I think typically you're going to find are higher skilled, higher experienced, have spent some time with this, this being software development, solving problems, and they'll have their own templates, they have their own methods, but those are not necessarily common. And when you mix those in within a team, all these different individuals with their different approaches, you get either more likely that one of those approaches is the best approach for a specific problem or a melding of those approaches creates something that is better than any of those other approaches by itself. I've seen that a lot even in templates where there's a process, there's a template, and then you use it for a while and you'll find examples where, well, this doesn't work quite the way I wanted it to. Let's add this thing, let's remove this, let's change that over there. And we don't have that ability in some of these other processes. That's really the value of Agile. When you think about it, probably the most important pieces of it that you need to take out of any examination of the Agile manifesto and the Agile approach to software is that first and foremost piece of we're here to satisfy the customer. We're not here to build our skill sets. We're not here to add to our resume. We're not here to make some political statement in internal politics, not governmental politics, but internal politics or anything like that. We're here to satisfy the customer. That needs to be the primary goal. If it's not, then you're probably not going to satisfy the customer. You're going to end up focused on whatever that other goal is. So satisfy the customer and then unleash the team to be the best team they can be. When you've got people riding a horse, they talk about it and I'm not a horseman by any stretch, so this is just what I understand. It's that you have the bitten bridle and stuff like that in the horse's mouth and typically riders will use that to guide the horse and things like that. There's the idea of where you just let go. You let the horse have its head as it were and let the horse do what it needs to do best. Usually it's in a situation where it's like fleeing a bad situation or something like that. You just let the horse go and it's going to take off. It's going to go quick. It's not going to have to worry about thinking it's going to go one way and then you directed another or anything like that. You're going to get the most out of the horse. You're going to let the horse propel you, get to a location and as fast a time as possible. You get the same thing with an agile team or a team that's going to be the best team I think honestly with any team. If you let the team decide what works for them and there may be some rough patches here, but basically hash it out and decide their own identity, their own approach, then you're going to get the most out of them. You will get the best solution you can out of that team. There are teams that aren't going to work that way, but I think more often than not, even lower skilled, lower experienced teams I think will do better unless they really, really need to start, unless they just simply can't work as a team, unless they don't have enough experience to build some sort of structure, then either going to be better off deciding their own. Deciding their own, building a process that is the, from the inside out, that is the team's process that is the best fit for the team as opposed to trying to jam the team into a process that you've decided or somebody has decided is best for them. Let them be the best they can be and you'll get the most you can out of them. It may not be immediately. That's part of what, you know, iterate and refine and some of these other patterns that we talked about. That's what they point to. So we're not going to get it right the first time. They're not going to get it right the first time as a team, but guess what? If you are dictating to them how to work, you're probably not going to get it right the first time either, and almost definitely because you have to make adjustments. And I say this looking at it from both, I've been in the teams that have had that, that have been given their head and then also those that have been tightly constrained. And I've coached or led teams that have been tightly constrained and also those that are allowed to just go do their thing, be the best they can be. And on both sides, I've seen the best, I've seen teams exceed expectations when I've allowed them to go do what they want to do. And when I've been part of a team that's been allowed to be the best they can be, I've always had, there's been a greater job satisfaction across the board. It's not just me. Unless everybody lied to me on the team, they also would talk about, yeah, there wasn't talk about griping about the management or something like that. It was just a, it ended up being a team that wanted to satisfy the customer, wanted to create the project, build the product, solve the problem. There's really not much more you can, you know, what more can you ask for of a team if their goal is to satisfy the customer, is to solve the problem in a way that is usable and create satisfaction, then why not let them do that? They're going to use every ounce of their ability. They're going to be probably more likely because of the ownership to want to be able to, they're going to go that extra mile. They know they have this ownership, they have this accountability, they know they were part of it. It wasn't dictated to them. They don't, they don't, it does sort of take away the blame kind of thing. Because then if you're a self-organizing team, the only person you have to complain about or to blame about any issues is yourself. And that, I think those are the keys I want to pass on. Agile is not anti-documentation. It is not, there's just so many things it's not that are the negatives. And some of the people that think of it as a silver bullet, it's not that either. It is an acceptance that we are here to solve problems, that our solution has to satisfy the customer and that we work best when we customize the approach to those doing it. When we allow the team to self-organize and pretty much drive towards that solution and trust them, the team will, they will come through. If you can trust the team, I guarantee you they will make you, they'll make you proud. And as part of, if you're part of a team, embrace that. You're not always going to have a situation where you are trusted to go be the best you can be. So when you get these opportunities, take advantage of them, be the best you can be. Make sure that you, you make whoever it is, proud or, or that they look successful. Make them look like the smartest person ever because they allow you to be the best team you could be. Challenge of the season as it were, what have we talked about that maybe, particularly going back to the principles and the values, what of those has maybe lost its shine with you? Maybe there's some area, there's an area there that you're a little weak on. Have you ever really thought about it, that that's something that's gotten maybe lost in the shuffle or maybe just something you haven't even thought of ever? Is there a principle or a value in actual that you need to take a look at and maybe see if you can work that into your, your daily grind to your work, to your schedule? Try to walk out of, the goal with this is try to walk out of this with an action item for yourself to do agile a little bit better. And if you haven't done agile at all in the past, then maybe take your first step, dip a toe in and try something that's one of these agile principles. See if you can make some adjustments and embrace that and see how it works out for you. And that being said, I will wish you a, give you a farewell for this season. We'll do a little, we're going to do a little intermix in between seasons, do a couple one-off topics, and then we will come back at some point with the next episode or the next season. We'll sort of see where that goes. So filling out what we want to do next. But until then, have yourself a great day, a great week, and we will talk to you next time.