Agile manifesto and Agile approaches to software

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 are continuing our season where we're looking at the Agile manifesto and Agile approaches to software. We are working our way through the principles to start it out. There are 12 principles they lay out, starting with, just as a reminder, the most important one, our highest priority, is to satisfy the customer. And the next one we're going to look at is, I'm going to dive right into it, so starting here, quote, Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely, end quote. Now this one is sort of the, almost the silver bullet of software development. If you've spent any time in the IT world and in software development in particular, there is often a rise and fall to activity and productivity. You may even call it a roller coaster ride. And sometimes it is. Sometimes it is very high periods of activity and some very low periods of activity. That is not good. I'd say that is not the most beneficial way to go about it. One, because we have potential burnout when we have those high period of activity, things that will blow beyond our normal week and start cutting into our non-work life On the flip side, it's almost the same. When we get low periods of activity, then one, we're not being productive. We're not essentially carrying our weight. But two, that's a detriment in itself. Think about a finely trained, high performing athlete. They work out and work on their skills and their physical things, traits, on probably a daily basis. If they stop, for example, if you see somebody, they're doing really good and they get injured, and they're out for a while where they aren't able to pursue those physical things that they normally would do, they'll drop off. You get out of shape. But if you keep at a regular pace, then you'll stay in shape. That's similar to what we run into in our technology skills, in our mental skills even. If we're doing this stuff on a regular basis, then it becomes almost like a habit. There's a muscle memory that goes into things, that goes into getting these tasks done. If we fall away from them for a while, there's a mental switch that we have to turn on to get that back in gear, to get moving forward again, to get, dare I say, momentum. Really, the key to the best performing, the most efficient team is one that is on a steady, flat, that contribute 100% all the time, or maybe 90% all the time, because you want to make sure that people have that, that they're not running themselves ragged on a regular basis. Just like anything about a processor or an engine or anything like that, if you run it 100%, it's going to end up wearing down and overheating or things like that. Bad things happen. Usually, there's something below 100%. Maybe it's 80%, maybe it's 90%, maybe it's 95%. But you can run at that pace, really essentially forever. You can do that indefinitely. Obviously, you have to fill the gas tank and stuff like that. But you can run things at a certain rate, and you're fine. You're going to be able to do that. People are the same way. Whether it's you or some other people, we can push ourselves or others at a level that can be maintained throughout whatever the amount of time is we need. This, again, goes to something physical. When you think of a runner, if somebody's running long distance, they're not sprinting that whole distance. They set a pace that allows them to run that whole distance. Usually, they run a pace that allows them to run that whole distance and still be able to push that last bit and do a sprint for the last 100 yards, 200 yards, or whatever it is. But they could do that for – these people, good runners can do it for a couple of miles, or they can maintain that sprint for 15 miles. That's just nature. We have that as well with our – it's not restricted to physical skills. This goes into mental, which is most of what IT is, unless you're doing it wrong. If you have a lot of physical stuff involved in IT, then you're probably doing stuff a little differently, or your conversations are getting a little too aggressive. This is very, very important. It's actually sort of interesting that they did not move this principle further up. Now, granted, unlike – you start off, highest priority is satisfying the customer. The interesting thing – and maybe it is because these other principles point back to satisfying the customer. This is about – this principle is really about being, as I said, the most efficient team that you can be. This basically says the things we're talking about, the agile processes that we are talking about, promote sustainable development. These things contribute to us flattening the up and downs of normal IT into something that can be – actually, there's a lot of benefits. It can be easily measured. It can be easily maintained. Even it can be easily adjusted to some extent. If you think of a team that is running at a certain rate, certain pace, and they can do that indefinitely, then it allows you to explore things like, what happens if I remove a member, if I add a member? What happens if I move some roles around? There's things like that. It gives you this burn rate, or however it is you want to look at it, however you want to measure it, that is consistent, that is steady, and that allows you to move parts around and see how it actually affects your efficiency, your productivity. So, agile processes become – this is where they're really promising a lot. They're saying that the things that we have struggled with – and I think we still do, but they definitely did. You go back 10 and 20 years, there are a lot of challenges that were – I don't want to say extreme. I don't want to overhype them, but there were substantial challenges that everybody faced. It was compounded by the environment and the types of applications and the lack of experience in some of those areas. Some of those things still exist, but essentially – I'm going to cut to the chase, I guess, or spoiler alert. Agile takes these big projects, the idea of eating an elephant, and instead of eating it in one bite, you do it in little bits and pieces. That's what agile does to software development. This is where they say, we're giving you a big payoff by considering agile processes, because they actually give you sustainable development. They give you something where you don't have to throw all these bonuses and cancel vacations and all this kind of stuff to get people to work late, work through the weekends, cram it all in so you can hit a deadline. It also wipes out those periods of time when you know people are not really pushing themselves, where they're not being as productive as they could be. Their workload is just not what it should be to keep them fully engaged. That's not a surprise. I think we all know it, and our managers, our bosses, everybody pretty much knows after a little bit of time. That there are good weeks and bad weeks, as we call it. There will be times where a team or even individuals are very productive, get a lot done, and there's others where they don't. Part of that is you've got to mix in things like burnout and stress and other things that impact your overall efficiency as a team. This goes back to the sustainable development thing. This is keeping a steady pace and morale and attitude and motivation and amount of work in front of you so that you can move forward, that you're not waiting on somebody else. There's a lot that goes into this. Of course, this is that 1A and 1.2. This is the right hook, left kind of thing where they say, hey, this promotes sustainable development, but then they follow it with the sponsors, developers, and users should be able to maintain a constant pace indefinitely. They end up essentially doubling down on this because it's one thing to say that we've got an approach that allows the developers to flatten that roller coaster curve and be able to move forward in an ongoing way at a steady pace. This says not only developers. This also impacts the sponsors, the users, and says that we can keep this pace. We can set this pace and do it indefinitely. Now, from a logical point of view, it almost makes sense, I think. There's anything that we can do for the most part, we can find a way to set a pace that allows you roughly to do it indefinitely. Yes, there's going to be periods of rest and some stuff like that, but for the timeframe that we're looking at, that can be done. This constant pace, it assumes things that they don't state, things like, hey, there's going to be vacations and stuff like that. But actually, if you do it right, all of that stuff is baked into it in a way that that's how you set your pace. You've got things set up where, and this isn't a key thing that you probably run into if you're in a smaller company. If you've got a key person that takes a week off, sometimes that slows everything down because that key person is required for so much. But what Agile does is it says we're not going to, and it's one of the other things we'll talk about, is we're not going to load people up so that there are key man. You think about insurance where there's this key man insurance where it's somebody that's a critical member of a team or an organization that if something happens to them, it dramatically impacts the team. You think about a team that's got a superstar on it or something like this, something like that. This allows them to continue forward. And it's key. It's one thing to work at a high pace and be very effective when you've got all of your, all the stars are aligned and all of your superstar players on your team are working well and working together and they're healthy and all that good stuff. It's another thing when you have to deal with life, when you have to deal with, you know, maybe they're not as healthy or maybe they're not as motivated or maybe they're banging their head against something, you know, essentially writer's block or coder's block, however you want to look at it. What we're looking at here are processes that allow us to determine what the pace should be and to align ourselves so that we do that. Now that's not to say that this does not, and we've seen this with the other principles, this does not say that there's going to be a steady stream of work and interaction and things like that. There's going to be changes. We've already talked about that where we actually welcome, ideally, the Agile Manifesto, we welcome changing requirements even late in development. So this says, yeah, we're going to accept that those exist. We're going to embrace those. And we are going to factor those into this pace that we set. And these agile processes are going to allow us to do that. They're going to allow us to build in the right level of effort, the right amount of cushion or wiggle room in our plans and our schedules to be able to take those things in stride and then just keep on going. This is huge. It doesn't, in my experience, okay, so this may be anecdotal kind of stuff, but in my experience, we do not see quite the level of burnout as we did 20 and 30 years ago in software. That's not to mean that it doesn't exist, particularly if you stumble into the startup world. It seems to be the drawing card, as it were, of that type of business or endeavor, as everybody is just all kinds of pumped to get things done. And you've got you're all going to you're going to rule the world and you've got the greatest product ever. And that drives you and pushes you and puts together a pace that is very high end. But that is not something that can be maintained indefinitely. So this is not to say, I think it probably is worth mentioning, this is not to say that bursts that are not maintainable indefinitely are somehow a bad thing or incorrect or an improper approach. This is to say that if you do this, if you take these steps, you can maintain a constant pace indefinitely. Now, whether that sponsors, developers, users, whatever, they can push the pace. But it this this really goes back to, I think, a very key thing and was actually talking about this to somebody the other day, a key thing that has improved the way software is built is an understanding at all ends for all of the people involved, whether it is the sponsors, the customers, the users, the developers, the management. Project managers, all of that. There is a better understanding in general of how what goes into software, of how software is created, of the challenges involved, the the the in inaccuracies or the research parts of it, you know, versus the things that are well defined and easy to reproduce. All of those factor into getting something done, getting it done properly with high quality in a maintainable, scalable, great user experience that satisfies the customer. So this is this is a principle that is a rather interesting one to put into it to list in the 12 because this really is the selling point to some extent. I mean, all of these do all of these point to being successful, how success is defined, what you should be looking for, what you should focus on. But we get to this principle. We're saying that not only are you going to be able to put together a good product if you follow this, you're going to be able to reproduce that. And that is a huge step forward when they put this out. There were and there still are. You can find retrospectives and stories about all kinds of software development projects and how they went right and how they went wrong and how they overcame obstacles or how they were crushed by them. It is all kinds of stories out there. And what they got when they put together the Agile Manifesto was a bunch of people that had gone through this stuff. They probably all had successes and failures. And they essentially got together and said, what worked, what didn't. And as they put these pieces together, they started to, I think, draw some commonalities out of it to say these are things that we need to address, that we need to provide, that we need to do in order to truly be the best team that we can be, the best software development group that we can be. And one of the things that came out of that is constant pace that you can maintain indefinitely because it does look at software as a marathon, not a sprint. And I think that was that was really important to look at it that way because so often it became a sprint. It became this we're going to sit around, we're going to mill around, we're not going to get that much done. We're going to work at a lower pace than we need to for a while. And then we're going to just blow it all out and work at 110% until we collapse. And then, of course, we collapse and we have to go at a lower rate for a while. And if we don't achieve our objective before we collapse, then we hit failure. This says, you know, we don't have to and it's important when you look at some of these other issues in there, we don't have to hope that we get this done before we all are exhausted. Instead, we say, here's what we can do. And if this thing extends out, that's OK, because we can maintain this pace as long as we need to. We can keep doing this. If you think of the boxer and ring example, we don't have to win in the first round. We set this up so we can go all 10 rounds and be comfortable doing so. We aren't going to sort of bet the farm on winning in the first one or two rounds. And then if we don't, we're going, oh, crud, what do we do now? Or, you know, we lose. You don't want to be in a situation where you say, hey, if you can't win in the first round, you're going to lose. This says, hey, we're going to hope we can, hey, maybe we can win in the first round. But that doesn't happen that much. So we're going to go ahead and push it and try to go all 10 rounds. That is a pace we're going to build. Because if you look at software, it is almost never going back to that boxing analogy of, you know, a one round. You knock them out in the first round. Software always is just this. It's a longer, heavier marathon kind of process. We just don't do sprints. We do in the actual world. But we don't, you do not, you know, have a sprint to the end and then boom, you're done. And you have a successful project. You have multiple sprints that you're going to get there, which is where we build that up to a marathon. Because although we use the term sprint and we focus at these short periods of time, what we're really doing is we're maintaining that pace so that from a real world sprint, you would be, you know, tired. You run a sprint and then you're done. You rest. In this, you are running from point A to point B, then point B to C, C to D, and you're maintaining that pace all the way through. And if somebody adds on a point E or point F or point G, then we can do that because we've set that pace. So now I'm going to kick you out into the real world and hopefully you are at that comfortable pace. That your day is just another one of a long standing series that you can continue forever and you will continue to be productive. And get some things done, get to the end of the day and feel like you haven't killed yourself just getting to the end of the day. But as always, whether you're at a good pace or not, go out there and have yourself a great day, a great week. And we will talk to you next time. This is developer.com. Just a step forward today 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 Developineur. One is the book, The Source Code of Happiness. You can find links to it on our page out on the Developineur site. You can also find it on Amazon, search for Rob Brodhead 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 Developineur.com if you would like more information.