Agile manifesto and principles, avoiding getting caught up in details

This is Building Better Developers, the Develop-a-newer 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 where we're looking at the agile manifesto and the principles, the core values, and some ways that we can apply it. Before we go any further into the season, we've set up a really good foundation, a nice baseline at this point. We've talked about the principles. We've talked about what we value more, although we value several, there are several key things that we value as part of software development, the agile approach. And then we've talked about some specific implementations. This episode, I want to talk about not getting caught up in the details. One of the challenges with agile in general is that it is often seen by, let's say it's seen in two different ways. And they are conflicting. And one is not really the right way to look at it. That one would be the one where it's seen as a framework, as a set of rules, as something that should be strictly followed. Now, while we have things that are needed, that are required, and these include somewhat the ceremonies, and in particular the roles, really that's probably the most critical thing is that we have somebody that is the role, that we have somebody that's a product owner, somebody's a scrum master, and then you've got a dev team. Now, the scrum master, the goal of that is somebody needs to have their job as a responsibility. They are the one that needs to be the coach, that needs to drive making the team get better. Because if you don't, if you don't have that assigned out to somebody, then it's easy for it to just fall through the cracks. Product owner is essentially the same thing. I don't, I really don't think that I've run into too many cases where there's not really a product owner. So that tends to be not an issue. Scrum master though, there have been times that it's maybe like a scrum master by committee, really there's not, everybody sort of does their contribution, and it's not one person that is really driving it. There's a couple of people, maybe it's a couple of senior developers, or maybe there's a development manager and a senior developer that sort of work together in that scrum master kind of role. But I think it's really important that you have one person that has that as a job responsibility is to make those scrums, make the sprints get better, make the team get better each time. Now, this is again, this is drifting a little bit into specific implementation of agile, but it is something that does go back to some of those principles. We are, we want this to be flexible. We want to be able to work with whatever kind of an environment we're in, whatever kind of solution we're developing. And there's a fairly big difference between a, like say a desktop application versus web application versus mobile application versus distributed applications or something that you've built in the cloud. The technologies change a lot, how we interact and what we have available to display to users and what their access is and all kinds of things like that. There's all these details that go into a solution and then go into a sprint into delivering a product. And so we need to address those details, but we also need to make sure we don't forget the core concepts. And even though it may be challenging at times to pay respect to those principles and those core concepts, it's important for us to do so, but not so important that we have to stick to it. So for example, one of the things that is a principle is the idea of regularly delivering working software. That helps us a lot, but there may be not only situations that are temporary, sometimes it's almost impossible to get something to the user until basically the end just because of the hardware involved or the setup or things like that. For example, like if you were building a maybe like ATM software and it had to work in a specific ATM, then it may be cost prohibitive to make that available, to have an ATM machine that the user could use. But you can probably find some sort of simulator or something like that. So when there is likely a problem like that, where there's some sort of a hardware problem or something like that, there probably is a way to get around it. That being said, there are going to be sprints, I think in almost every project, there are going to be sprints where it just doesn't necessarily, it may not be feasible or may not make sense to worry about delivering working software in that sprint. And so it's still, we've talked about this while we want it to be regular, we want it to be something that a customer can expect. I think it's okay for us to say, you know what, we're going to skip this release or we're going to shift this around or however you have to do it to get the job done and to be productive. Because although when we say we value X greater than Y, one of the things that is maybe understood when you look at those things that we value, we value getting the job done over saying that we properly followed the agile approach. It goes back to we value working software over well-documented stuff. Well-documented would include strict adherence to a process. And so while these things are helpful, they are not mandatory. And I think that's a challenge we run into at times because people that come from some of the other software development approaches have a much more, and depending on the size of company they've worked with and that, they may have a much more rigid view of how things are done. They may have a very tightly defined requirements document that they expect or a detailed design document or implementation approach or testing or deployment. There's all these different things that people may come at this project that you're working on with, I call it baggage, the way they've done stuff in the past. And they may want to fall back on that and say, well, we've got to do this. Agile says, no, you don't really. Agile is not a command. Agile is a suggestion. It's basically saying, look, here's what we did and here's some things that worked and here's some things that didn't. And out of that, here's how we think we should go forward to be better. And in a sense, you can take it or leave it. And while you may not be technically agile in the way you do it, you may not have a perfect sprint or your team may not be the perfect definition of a team. I think it goes back to the core concepts. It goes back to the manifesto itself. Don't worry so much about getting all of these things right that we talked about, as much as worry about the things that work for you and that help you become better. And this may even be the things that you are comfortable with or understand or I don't know if you need to master them, but feel like you can implement them. And we talked about in previous episodes, we talked about, for example, daily standups and sprint reviews and retrospectives. Maybe let's say sprint review, you're just not comfortable with that. You just don't feel, you don't have a warm and fuzzy feel about how something like that would work, how you would do that. It may be because you're a small team and everybody on the dev team is not into presenting. And so they're all very uncomfortable with it. Part of me would say, get over it. You need to work on that. You need to push yourself to present. But if you have that kind of dynamic, it could be very difficult to do a proper sprint review. If everybody is an introvert, it may be difficult for them to do a retrospective. And particularly, I think this is where it's okay to think outside of the box. So particularly the way that we've described, that we've discussed here, may not be the best way for you. Maybe it works for you to do a, for example, a sprint retrospective that's instead of a meeting where everybody gets in there and does their pros and cons, what we did right and what we can do better. Maybe instead it's an email that you send an email out to everybody and say, okay, give me, and maybe you force it a little bit, say, okay, everybody give me five things we did right and five things we need to improve on. And maybe then you have a shorter meeting and you discuss, okay, how can we improve? Or maybe you send an email back and say, okay, here's our list. Maybe give me, out of this list of things we did right and things we can improve on, give me three things that you think we can improve on and maybe a way to do that in the next sprint. It puts people on the hot seat a little bit, it puts them on the spot, but it's via email so that maybe they don't feel it as much and they may actually be more comfortable doing a deeper dive into something via an email than they would be in person. Or maybe you need to do it over a Zoom meeting or a phone call or there's other ways you can do this that gets at the key, which is finding ways to get better in the retrospective point of view or delivering something to the customer in the sprint review in that aspect, doing that ceremony of the sprint. There are other ways to do it. So if you really find yourself struggling, then maybe take a step back and see if there's a way that you can get the same end result but approach it in a different manner. I think that is, to me, that is the strength of truly embracing Agile and Sprintz and Scrum. Is it's, hey, we're going to pick periods of time, Sprintz, we're all going to work Scrum and we're going to find a way to get the job done. Number one, satisfy the customer. But along the way, we're going to look at ways to become better. And that's Agile if you want it in a nutshell. That's what it is. We're going to work together. No specific rules or anything, but we're just going to work together. We're going to try to get better. And since every team works together differently and is at a different point and has different things that they need to work on to get better, and even probably different priorities of what matters and what doesn't, and what needs to get better and what we can slide with for a while. Maybe we can stink at these couple of things for a while and it's not going to matter that much. And we'll come back around to them later. These other things, we got to figure them out quickly. And that is very common. Depending on your managers and management style and who your customers are and your deadlines and all of those kinds of things that may have nothing to do with, or not directly related to development, but are all about creating the product and getting it in front of people and making sure that it's high quality and getting reviews and all that kind of stuff. That's just a lot. And those things can impact what we want to do and how we approach software development, how we approach getting better. We may have some things we would really prefer to address at the end of a sprint and say, here's a couple of things that are driving, that are personal headaches, pain points that I want to relieve. However, the person that writes the check has a different set of pain points and so we need to get theirs figured out first. But it's a whole meaning of agile, is flexible, ability to move quickly. That is key. If you find yourself getting locked into something, whatever agile method you're using or agile approach you're taking or however you're customizing them to your specific needs, if you find them locking you into a certain way or restricting your ability to get things done, then you need to reassess it and say, maybe this is something that, maybe we get rid of it or remove it or we do something. Daily standups are a common, very common time thief in this sense. When they're not done right, daily standups can easily be 30, 45 minutes. You're doing that, some of them an hour. If you're doing that for your team five days a week, then that's a lot of time. That's several hours, a few hours I guess we'll say. At a half hour, that's two and a half hours a week that you're in a status meeting essentially. And really at this point, it is a status meeting. It's not a standup if you're spending 30 minutes. Maybe those are working sessions and that stuff that you needed, but probably not. Especially if you've got a team that's five, six, seven person dev team plus product owner plus Scrum Master, not all those people need to be spending that much time. You need to be aware of it. But that's something that sometimes maybe it makes sense to junk the meeting and say, three times a week instead of five times a week. Or to really tear apart the details of what you do and get it down to something very simple to not try to do what you think needs to be done in a standup, but instead find a way to make that time work for you. Maybe eject some of the details so that everybody's not spending as much time in a detailed manner describing what they're doing or what their plans are, however you're handling that sprint or that standup that makes it last that long. And like I said, maybe start by saying, OK, we're going to meet three times a week instead of five and see what happens. Or one time or twice a week or whatever it is. The bottom line is don't be afraid to, I will say, play around with how you approach Agile. Don't be afraid to make changes and adjustments and inclusions and exclusions to get to the thing that is the most comfortable fit for you and your team. That's it for this one. I just wanted to bring that in because we've put so many things, I think, into our heads as we've gone through this season so far. I want to make sure that we don't lose the original goal, satisfy the customer, getting a product built. But also that Agile is not intended to be restraints. It should be a comfortable coat. It should not be manacles or something like that. Or the locks or something like that. It shouldn't be handcuffed. It should not handcuff you. It should free you and help you get stuff better. It should be something that speeds you along and stuff slows you down. Challenge the weak. Take a look at what you do from your Agile approach and is there something that maybe some aspect of it that is maybe very broken? Maybe something that you look at and you say, oh, we do sprint reviews, but man, those never seem to go well. Or stand-ups, but gosh, I spend so much time dealing with my stand-up every day and I don't seem to be getting anything out of it. Whatever it is, and see, is there some glaring issue that you need to adjust that maybe it is something that you just say, let's just toss it out for a while? Whether you're a manager or a developer or whatever, maybe you bring that to the forefront and say, this thing seems horribly broken. Maybe we need to just ignore it for a while, not do it for a while. Or maybe we need to do something that halfway gets there, but obviously we need to learn it a little better and propose it or take a stab at doing that your next sprint around and see how that goes for you. But however it goes for you, I hope you 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 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 a day 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.