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're continuing our season where we're looking at the Agile Manifesto. We're going to dive a little deeper into it and looking at how we can take the principles and the thoughts behind this now sort of aging document, I guess. This chunk of wisdom from the past and see how we can become better developers from it, how we can improve our odds for success when we create our software solutions. We have cranked through or actually over the hump and looking at number seven principle today. And this is going to be so short, but very we'll find a way to drag this out. Definitely into a full episode because there is some some key things to discuss here. So right going right into it. The principle is, quote, working software is the primary measure of progress, end quote. Very simple, very short, very direct. Working software, primary measure of success of progress. Now we have talked about this to some extent. Some of the other principles we talked about the idea of delivering working software frequently. That was in the third principle. And all of this actually goes back to our highest priority is to satisfy the customer. What is the number one thing that we deliver to a customer that is going to be how they measure satisfaction? It's the product. It is the working software. We can design the greatest thing ever, but if we don't deliver it, then it's useless. This goes back to an old idea of inventions and starting businesses and things like that where you can have the greatest idea in the world. But if you don't implement it, then it's never going to it has zero success. That's a guaranteed failure. And this is, you know, although we're not talking about necessarily having an idea and saying, oh, well, I'm not going to bother with it, which is where those other quotes and thoughts go. This is saying, hey, we're going to get this done. But the way we measure our progress towards the goal of in quotes done of delivering that product is some sort of working software along the way. We've got pieces that we need to build that should work. Maybe not in a vacuum, but our completed code tasks. So even to the level, if you want to go all the way down to the level of, you know, let's start with unit tests, you should be, as you are progressing, able to write unit tests that work. That's if you can't if you if you write your whole thing and you can't write a single unit test that will pass until you're done with implementation. You're doing many things wrong. That's you need to step back. Instead of becoming a better developer, you may need to just become a developer at that point. We know this and it's not and this isn't to be a flippant or a dig against people that don't do unit tests. But I mean, from a functional point of view, there's codes you write that should work to some extent. There should be some way that it works. There's a function that you write that if something calls it should return reasonable values. Everything doesn't just fall into place at the last second when everything's implemented. I don't even know if I don't even know if that's possible. There has to be things that work along the way. And you build on top of those. It doesn't all just magically complete at the same time. Even if it even if major features sort of need to be need that last push across the finish line to get them all to connect, they still should have to some extent standalone functionality. And that's not I'm not saying you write these as components or anything like that, but just from a theoretical point of view. So looking at that, there should be pieces and there almost has to be by definition, I think, pieces of software that work along the way that are not, you know, they're not the final, the end solution, the completed product. But they are working pieces that are moving us towards that goal of that overall working product. Now, there's there can be arguments for the idea of working software being time consuming, because sometimes to do working software, there's there's approaches you need to take or deployments that you need to do or things like that. That and this this also talks a little bit about it goes back to the idea of that deliver working software frequently. But there are there are arguments that there is a cost to delivering working software along the way or to have working software along the way, because there are it implies usually and sometimes almost requires a little we'll call it finishing touch or something like that. Or maybe even an additional bit of infrastructure to be able to validate the working software. Because it's we can say it's working, but we still need to actually do it. We need to do even if it's the most basic of smoke tests, there's something we want to do to say, yes, that's working software. And of course, working software would talk, you know, go back to that focus on the customer. That means it has to be something that we can give to the customer and they can get some value out of it. And so there may be some things that we do that are in some cases even sort of like a throw away framework or infrastructure that allows them access to that working software before the whole solution is available. This is just part of the equation in this. The primary measure of progress is the I think the key to this. This principle is how what really matters. Yeah, we go back. Okay. Our highest priority satisfy the customer. All right, so let's take a step from that. How do we do that? We give them working software. So what we give them at any given time, the more it works, the closer it is to our end result. What our primary goal is, our ultimate goal is for the project. Now, this may seem, I don't know, obvious or something like that. It may seem like common sense. But it really is something that we shortcut, I think, a lot. Now, it is getting better because as we push agile and some of the other processes and procedures and software development lifecycle approaches that we take, we've gotten more and more to accept small cyclical advances towards some sort of final product. Periodic small incremental releases versus something big. And software as a service probably is the best example of this, the best platform for this kind of an approach. Because really with software as a service, if you look at most providers, they started with something simple. And maybe it's like a login, an account profile management, and a very core, simple is probably overstating it, but not overly complex or hard to create set of features. Now, maybe not some places, you know, they wait to the actual release before some of that stuff gets out. But for the most part, there's there was probably some beta testers or internal testing or somebody that started working on that platform before it was version one or however you want to look at that. We see this with smaller applications. It's easier to do. And if you're just building a little calculator app, then working software, it sort of defines itself. You're going to have something if it's just a calculator app, then maybe the first thing is you've got some some sort of functions that do addition, subtraction, multiplication, division. And then maybe your next step is you've got an interface to it and then you get your final product or something like that. It's something you could turn around quick. So working software, it's almost done before it starts. You can if you have a quicker product or a quicker cycle. So if you've got something where you can knock it out in a few weeks or a month, then you may say, OK, well, we've got a working product. But there's even in that case, there should be working software along the way. If you're writing code, if you've got a team working on something for four weeks, there should easily be some milestones along the way that would be essentially working software that you can look at it and say, can this does this exist? Does the bit or bits of code that solve this problem exist and do they work? Not are they production ready? Not are they ready to be deployed necessarily even to a customer? That's a different principle. This is we want something that we can say. Essentially, I think of it as we want things that we consider to be done. And if you've been on any team or if you're a leader or manager, I mean, that's sort of comes down to this is where that common sense kind of thing sort of settles in. If you've got a manager that says, how are you doing? Here's your sign, these five tasks. Where are we at? And you say, well, I'm working on them all. But that doesn't work. Usually, you know, there's going to be some. OK, what are you working on? What's the primary one you're working on? Is it done? Is it working software? Is it complete? And then complete has connotations of finished and stuff like that. But working software still it does have connotations of maybe verifiable or it's been tested or something to that extent. And that is a primary measure of progress. If that piece isn't working, then you're not done with it. You still have to go back to it. And if you if you look from a very. Almost a very simplistic point of view on how do you get from nothing to an end product? There are pieces that you build. There are things that go into that end solution. And so to know how far along you are, if certain of those pieces are done, if they are working, then you know that you've progressed at least past that that step, that unit of work or series of units of work. What this doesn't say is very key as well. I've sort of beaten this working software horse to death a little bit. But what it doesn't say is design documents, unit test scripts or unit tests or test scripts, communication templates, burn charts and things like that. There's a lot of stuff that is project management that is administrative stuff that goes into software development to help us figure out where we at, how are we going, are we at the right direction, things like that. This is to ground us on what the really what the why, what the focus of our project should be. Working software. There's a question you can ask yourself that productivity people will talk about as it's, am I busy or am I being productive? It's the idea that busy work is not productive work. The idea that just because we're busy does not mean we're actually productive, that we're doing something meaningful. I can be very busy doing something that is absolutely is a total waste of time. And so that's what this brings us back to. In the grand scheme of things, everything should be pointing to creating working software. If you want to work on a very lean and mean and clean process for software development, every task that you do, you should be able to link to creating working software. And then it should be as short and direct a link as possible. This can be offset by politics and things like that that go in administrative things and management styles and all that kind of stuff. But if you want to create a software development process that is as efficient as possible, then every task that you have people working on is focused on getting to working software. It doesn't mean that everybody's writing code. It doesn't mean that you don't document, that you don't design. It doesn't mean that you don't architect. Because those tasks are critical in creating working software. We have to have requirements and we have to communicate those to the development team. Otherwise, they have no idea what they're building. Design is a way to get us to working software faster. And architect, designing and architecting a solution keeps us from flailing around when we get to the writing code portion of implementation. So we're not saying that those things are unneeded. But we are saying, well, whatever task we're working on, it should be moving the needle towards working software. If we start doing stuff that isn't, then it's a waste of time. And this also, even in implementation, this is still important because there are things like bells and whistles. There are other things that we may go as technologists, as implementers, that we may go off on a little bit of a side trail to put something into the system that is, in quotes, you know, cool or neat or the latest tech or whatever it is. If that is not directly helping us create working software, then it probably needs to be jettisoned. This is in a general and in a general backlog grooming approach, putting together requirements and features and things like that. This is from start to finish. This is a sort of a why. The ultimate why, just to beat that drum again, ultimate why is satisfy the customer. But then this, you know, the YA and YB working software is what the customer wants. That's how you satisfy the customer. So as we are building out features and requirements and plans and the architecture, the design, all of that stuff should point us towards creating working software. Every step we take that is not directly in that direction is not as efficient as it could be. So that there is going to be a, this gives us like a metric. This gives us something that we can measure our plans and requirements and features against. And features and requirements are key. I use this thought process a lot when I'm talking with customers about, particularly when it's a pretty much a wide open project. This happens a lot when you've got people that are creating their new, they've got a great idea and they're creating their first software product of some sort. And so it's sort of the sky's the limit. Well, a lot of this comes back to, okay, what do you want to build? What's your audience? Who are your end users? And from a high level point of view, what does this do? And so from there, then we drill down into things like what needs to be a part of this solution in order for it to work. What is required for this to be working software? And focusing on that. Now, that doesn't mean that we don't drift into things like discussions of user experience things. Maybe that's not, but even that, it's not necessarily working software, but it does take that next step, which would be usable software. So you can make an argument that there are some things that are not required for working software, but are nice to haves. But the thing is, or nice to haves a little bit, that are want to haves. But the key here is when push comes to shove, if you're going to eject a feature, the one that is needed for it to become working software, you're going to have to keep the one that is an improvement on user experience has the opportunity for you to get rid of it. And this is a challenge, and this is the balance that we use in those discussions. It may be that they have maybe a fixed resources of some sort. Either there's a certain time frame or a budget, monetary or time budget or resources available, whatever it is, that basically says, OK, we have to squeeze X amount of stuff in this box, whether it's a budget box, a time box or whatever it is. And so you go first towards the working software items. And then you get all of those, you put those into the bucket or the box, and you say, OK, well, this is stuff we've got to get done. This is what it's going to take to get there. Here's what time or budget we may have left. So here's some things that we can work into it. And it may be very difficult. There are times where it gets down to, OK, you really, really want this, but it really, really doesn't have to be there. So we could make this work without it. Or do you adjust the time frame? Do you adjust the budget? Do we find another resource? Whatever it is, so that we can get that thing in that you want. And it's something that I think is key to communicate to the customer in that situation is to say, look, this is not required for working software, even though I see where it would be very valuable or maybe a competitive advantage or something like that. So I think there's a lot to let it percolate in the back of your mind for a while. It's just thinking about it's very simple working software as a primary measure of progress. And think about that as you go forward and how you plan your approach, your week, your solutions. I'm going to let you just ruminate on that for a little bit, use a couple of big words and get back to your day. So 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. Hi, this is Rob from Building Better Developers, the Developer Noor podcast. We're excited to be on Alexa now. You can enable us by simply saying, Alexa, enable Building Better Developers. And we will be there ready for you every time you want to listen to your now favorite podcast. Whether we are your favorite podcast or not, we would love to hear from you. So please leave a review on Amazon.