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. Hello and welcome back. Welcome to a new season. We are going to look at the Agile Manifesto this time around. We are going to spend some time digging into some of the key points that they make. There is a 12-point manifesto basically, depending on how you look at it. We are going to look at each of those points in detail and why we do those. How those will maybe impact for the better, or maybe for the worst if we do them wrong, software creation. Now, this episode I want to just focus on the sort of the high level. We are not going to dig into a specific point yet, but just sort of talk about it as a whole. The Agile Manifesto came about a couple of decades ago now and was written to basically make some adjustments in how software is being made. At that time, most software was a very heavily documented process. There were a lot of those requirements and design and details and all these other things that ended up adding up to a lot of documentation. The thought was that there were better things to do than just simply build documentation. Now, documentation is not in itself evil or anything like that or a bad thing to do, but it is something that sometimes a process gets in the way of getting things done. The nub of what they came to actually is covered in their introduction where they say, quote, End quote. That's from the Agile Manifesto, which you can take a look at it. AgileManifesto.org. And it's not like a deep, heavy document. Well, thought was there may be some deep ideas there, but definitely not something that takes you more than a minute or two to read. It may take you many years to really absorb it and embrace it. The key to the Agile Manifesto, as we're going to look at, and the Agile approach to software development is not that it throws out everything that's gone on before, simply that it focuses on certain things while allowing other things to be secondary considerations. You think about it, working software over comprehensive documentation. Really, what would you want if you've got a piece of software? Would you rather have a really good user manual or software that works? Ideally, you get both. You have software that works. You have really good documentation. But sometimes, really, if it comes down to it, if you're going to give up one, which one are you going to give up? Most people would say the comprehensive documentation, because it doesn't matter how good the documentation is if the software doesn't work right. That may seem obvious, but because of how the process flowed, that was not always the case, or at least that was not the case in reality. A lot of documentation was more or less front-loaded into the process. That would allow it to get done, because early on, you figure, hey, if we slip a little, that's okay. We're going to get the job done right. As you get closer to the finish line, then that's where it's more likely that you're going to eject some of the things so that you can get across the line in time. We've looked at the opposite side of that on the end portion of software development, where testing tends to live. We've talked about how that's part of why testing tends to get pushed off, because they just wait until the end. When you get to the end and you've got to push something out the door, if you're going to cut a corner, the only corner you have left to cut at that point is testing. Agile makes some changes. In the Agile world, we have a focus on implementation, essentially, first. That doesn't mean that there's no design, but that implementation starts earlier and in some sense would probably even end earlier. Then you worry about documentation. You can put together, you can build documents as you go, but the comprehensive side of it, the heavy details, those are left to later in the project instead of earlier on. With Agile, what we do is we really don't, in a sense, don't really change the value we put on the various artifacts that come out of software development. Instead, we change the order saying that, hey, if we're going to cut a corner, if we're going to have to cut scope, if we're going to have to reduce what we deliver, let's reduce the things that have less value. Documentation would be one of those. Think of the extreme case. If you had a well-documented product that didn't work or a product that had zero documentation and worked flawlessly, what has more value? Obviously, the working product. Documentation really doesn't do you enough good. That's all that is. I think that's a common misconception is that Agile and Scrum and the related processes throw out things like planning and design and requirements and the documentation of all of those. It does not. It just shifts the focus. At the end of the day, at the end of your project, when you complete it, you should have still a working product, obviously, I think, but then also a proper level of documentation. The nice thing when you go to the Agile approach and things like a sprint, a sprint-based approach, then you may have documentation sprints at the end, or you may have some along the way, just as you have technical debt sprints sometimes and things like that. Or maybe you work a system where technical debt gets worked into each given sprint. There's a little bit of a time that's focused on addressing technical debt. Well, documentation is technical debt in a lot of cases. While, yes, those backlogs can build and build and build, and sometimes we don't go back and address them properly, that's not Agile's fault. That's our fault. Agile says you should get to that stuff. If you put those in the backlog, you should end up getting to those at some point unless the design changes in such a way that those become non-items, that those no longer apply to the solution you're building. We'll bring a lot of these ideas up as we dig deeper into the precepts of the Agile manifesto. Since it's a game changer, and I don't know when it first started, so maybe it was not as rare as I thought it was before, but is the idea of customer collaboration. I've definitely been in projects where there is almost an us versus them. You have a vendor, you have a customer, and they're both working to get what they need. They're not really working together to do it. They're working to win for themselves. They're not working on a win-win situation. But when you switch that and you go into a situation where your goal is a win-win, particularly if both parties are looking for that, then you're far more likely to have a successful project. You're going to have all of the side effects of happier people. Nobody thinks they're getting screwed over. People are focusing on getting the tasks done as opposed to finding a way to CYA or anything like that, or even build good arguments for whatever their case is. Instead, you're just working on the solution. You take blame and things like that out of the equation. You get happier people. You get something that's more productive. But even those side effects, throw those out and think about just the primary things of now you're trying to find a way within the requirements and within the constraints to get the best possible solution for everybody involved. If you do it any other way, then you may get something that ends up being actually ineffective for one or sometimes even both parties because you end up in such a struggle negotiating and trying to position that you don't actually get the work done. So these are very big statements to make as far as their impact. When you focus correctly, which is what Hatchell Manifesto is trying to get us to do, then you can make it very far more productive, far more likely to be successful than when your focus is in the wrong place. And that's not unique to software, which is part of where the Agile Manifesto comes from. I think you essentially had a bunch of people that had done this many times. That's their starting point. We are uncovering better ways of developing software by doing it and helping others do it. And so these are people that have experience. They had built software. They'd done it multiple times. They had talked to other people that had. So they had their personal experience and viewpoints. And they looked at other people's experience and their viewpoints and put those together and said, OK, here's what makes sense when we step into a software project. And they probably used experience outside of the software world as well. Most of these concepts and ideas are maybe they're unique to software because how software is done. But I don't know that that's true. I think and we'll explore that more as we go into them. But I think most of these are somewhat generally applicable. You may have to adjust what you call the various items. Maybe the idea of working software over comprehensive documentation. OK, that's obviously software. It's in the wording. So that's going to have something to do software. But working products you can generalize that a working product is has more value than comprehensive documentation. You could think about I don't know why, but these jumped is the idea of video games. There are some video games that were well documented. Over history and were horribly received were miserable failures because the game itself either didn't work or wasn't wasn't playable or didn't make sense or wasn't enjoyable or however you want to whatever the problem was, whatever its fatal flaws were. But then there's also some that were had really non existent, very sparse documentation and yet they turned out to be very good. Now we will talk about things like blending those two where you're you're building documentation into the software itself. You know with help and wizards and guides and things like that. Sometimes you can you can essentially kill two birds with one stone. And that's not. It's not exactly getting something for free because it's going to take you extra work to to build a comprehensive help system or to build a you know a wizard or a flow or something that is foolproof you know or is very user friendly. And that's what manifesto the agile manifesto looks at is looks at the stuff where we can get the job done focusing on the things with most value but also not forgetting about the things that have little value. So you don't get one without the other. They don't just say here's the 10 things you need to do. It's more like they say here's 10 things you need you have to have or that have the most value that will be your biggest bang for the buck. And by the way here's 10 more that need to be in there but maybe they're not you don't get the same return on investment with those. They may not bring the same value to it. And think about a software development team and then you have to have some sort of a leader architect or something like that. Otherwise people are just going to not quite code randomly but definitely not work as a cohesive team. However and having that you know the right manager leader architect designer those kinds of roles those are very valuable. Those are critical. You got to have the right person you know somebody that can do that in order to be successful. However just because you say there's more value than that in that than there are the coders you know the pure implementers without the pure implementers you don't get a product. So as we go into this and I know we're going to beat this drum a lot but the focus is not one versus the other. It's just a setting of priorities and trying to make sure that your priorities are in proper alignment to bring about successful software. And this isn't coming you know as I said this is not coming from people that just sort of looked at some software and said or looked at it theoretically and said well here's roughly how things should go. These are people that did it. This is you know they have blood sweat and tears that have gone into products and projects and talked to people that have the same kind of an investment. And then looked at it to say OK how can we take what we've done learn from our both our successes and our failures and find a way to do this better to improve the way that we get these things done. And that is how the Agile Manifesto came to be. It was a community it was a software community stepping into their processes and their projects and saying OK we've we've been the doers. Now how can we do better. You know how can we make this easier on us and more likely to be successful because even then there was there was software products were not the most were not as successful as often as they should. The average issues that came up and success rates and things like that were not where people wanted to be. I mean obviously we wanted to be 100 percent but they weren't 99 percent either. And I don't know what the numbers were then. I haven't gone back and I don't know that they it would be an apples to apples comparison anyways because of the way software is done how it was what its focus was the kind of problems it was solving and all that kinds of stuff. Very different from today. But you should see in theory you should see a steady improvement. So if you had pick a number 50 percent success rate when you first started people's first started building software that should steadily rise particularly because of how software is built. We build on what we've we build on problems we've already solved. When you haven't solved any problems you've got a lot of work to do that is research or very open ended. If you've already solved some of those problems those are those are all pretty buttoned up. Those should be really easy to estimate and to get them done with you know with minimal risk. And that's what we reached a point as you get into the 70s 80s and the 90s. There's a lot of software that been built lots of code had been written. And so you got to a point where people people have at that point a career's worth of experience. And now they're reflecting back on it and saying what can we do to make this better. And the interesting thing is is that they looked at a lot of what was done and said no we we need to have all of those things. I think they basically said well if you look at what we do we're doing things that we have to do. And for the most part we're not doing things that have no value. So when you end up in that situation where you have you know 10 tasks that need to be done then the next step you can do is prioritize those is put them in an order of priority or importance or getting them done. Always with the idea that or at least in here idea that you know if you get nine of the ten done that you want to make sure that the one that you didn't get done is the one that brings the least value. Or if you have you know a couple that get partially done you want those to be low priority items versus the higher priority items that you want 110 percent done. You want them done and with quality. That is going to be our focus for this season. We're going to look at ways to build software and some of it's even just to solve problems but it includes as as a team to work as a team with it within our team as developers but also with our customers our user base management everybody that is part of this. And you know look at what they require what are their needs in order for something to be successful and trying to help everybody get their needs met and a product out the door and as fast efficiently and as with as much quality as possible. So yeah maybe we're going to take on a big chunk but I think you'll find out as we go through this that this is not this is not as complicated as it seems when you really start breaking things down that the actual manifesto becomes almost common sense really. Really it's not a and it's not a big stick or a bludgeon to use against somebody to say hey this way you do stuff is is wrong. It's a way to say hey you know what you're doing if you make some adjustments to it you can be more successful you'll be able to do it better. And that is where we're going to stop the summary will jump into the next episode and we'll actually start diving into some of the key concepts that brings us to the challenge of the week which is take a look out at agile manifesto read it. It's not I guess it takes like a minute or two I think to read it depending on how fast or slow you can read and maybe download times but it's it's just a good little couple of page simple website go to agile manifesto agilemanifesto.org and check it out. And you know let's have that stuff start you know percolating on the backburners of your mind and you know maybe even before you start into the season you start making some adjustments to make yourself a better developer. That's almost the first line of the agile manifesto we're covering better ways of developing software that is so close to here's how we think you can become a better developer. That's something to think on. But we'll cover this more in the next episode and the ones after that. So until then go out there and have yourself a great day a great week and we'll talk to you. Thank you for listening to building better developers the developer podcast for more episodes like this one you can find us on apple podcast stitcher Amazon and other podcast venues or visit our site at developer.com Just a step forward a day is still progress. So let's keep moving forward together. One more thing before you go the developer podcast and site are a labor of love. We enjoy whatever we do try to help developers become better. But if you've gotten some value out of this and you'd like to help us be great if you go out to developer.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.