Making Agile Work: Exploring the 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 or maybe even just starting our season where we're getting into the Agile Manifesto. We're going to talk about making Agile work, looking at the core concepts, the precepts that they put together that said, hey, we need to take a look at how we build software and do it differently. And then how can we do so? Where can we make some improvements? The initial focus here is going to be there are 12 principles that are laid out. Each episode for the next couple, next dozen episodes, we're going to look at one of these principles and talk about how it applies to software development, particularly modern software development. Some of these thoughts and ideas and approaches actually come from a class that I did on Agile, general Agile approach to software development and trying to explain it to non-software developers, people that did not have a lot of experience in it. Some of that was maybe a little over their heads in a sense because they just didn't have the experience to be able to relate to it. I'm hoping that for this audience, we've got people that have a little more, have some sort of experience. So these things will hopefully ring true to you and give you some ideas on where to maybe make some adjustments in your own processes and procedures. First one we're going to look at, and we're just going to take them in order. So the first concept principle that we're going to look at is, quote, our highest priority is to satisfy the customer through early and continuous delivery of valuable software, unquote. There is a lot of value in this principle. I think it starts with something that's almost you could consider a throwaway. Our highest priority is to satisfy the customer. Stop right there. That is key. Now it goes on and provides some information, but when all is said and done, when we are delivering our software to the customer, whoever that happens to be, if they are not satisfied, then we did not succeed. This goes back to the old idea that the customer is always right. This is essentially rephrasing that, but it's something that often gets lost in software development. It's amazing how many times been in a project and there's been complaints about the customer just doesn't understand or, well, hey, we've got this thing we can do now and this is what they're really going to like. Sometimes it's not even, there's some of these features that have nothing to do with the customer. I don't know how many times I've, it's particularly in newer developers where they want to, I guess it's sort of show off their skills or, hey, there's this cool technical thing we can do that really serves no purpose to the user, but they want to do it. Then sometimes it ends up being very essentially detrimental. A good example out of many, that's a nice simple one, is that there was a developer I worked with that was big into JavaScript stuff, some of the coolest, latest, all of that in quotes, JavaScript things you can do. One of the things he stumbled across was the ability to fade out something. He thought that was just the neatest effect, that you could go push a message to the screen, display it to the user, and then over whatever it is, three seconds, five seconds, 10 seconds, that thing would just sort of fade away, which is probably useful. Well, not probably. I know there's situations where that's useful, where it's good to see sort of a work that just sort of fades away. We see that on desktop notifications all the time. That's how most of them work these days, is you get something that pops up and then it goes away. Your email client probably does this. You may see this on your phone. There may be certain apps that will essentially display something, but then eventually the screen goes dark again. The thing is, that's not very useful when it's an error message. If somebody has an error, they need to know that they had an error. There needs to be probably some acknowledgement by the user that they have seen the message that says they got an error. Otherwise, if they click send or save or something like that, and the error message pops up and they're not paying attention to the screen, and then the error message fades away, they may think that all was well. That ended up being quite the negative. This developer went in and coded this and we got to testing. It wasn't a feature or anything that anybody listens. That developer wanted to do that. We got to our first round of testing outside of unit testing. It's like, wait a minute, what the heck is this? It was a bug. We decided it was a bug. He said, no, no, that's a feature, which that's its own little argument and discussion for another episode. He said, oh no, that's cool. That way it doesn't stay in their face and bother them. That's actually a bug because we need them to see that it's an error. Otherwise they may not know. They may not have that information. In particular errors when you've got additional information about the error that you're going to share with support or somebody like that, if that message goes away, that means they have to somehow regenerate that message again to be able to copy down the information they need. So a very simple kind of effect, but something that's a good example of not focusing on the customer. It's probably a little cheesy, but back in the, I don't know how far back it was now, maybe it was the late 80s or the 90s, something like that. There was a big, one of the things was to wear these little bracelets that said WWJD, what would Jesus do? That's, like I said, it's a little cheesy, but maybe that's, you should think about what would the customer do? What would the customer want when you put together features and you're tweaking things and adjusting them? Now if it's requirements, then those are, for lack of a better term, those are the customer saying this is what we want. If you give us this, we will be satisfied. Should be the contract that is system requirements that you got in front of customers, you discussed what was, or customer representatives, however it works out, discussed what was needed, how it should be done, and then that's how you got your requirements. So technically following the requirements should satisfy the customer. Again, there's another episode or maybe season of stuff on dealing with that and doing that correctly and understanding that sometimes a customer asks for something that really isn't going to satisfy them. But in general, when we're adding features or implementing something, our first thought should be is this for the customer? Is this going to satisfy the customer? Is their usage going to be a better experience because of this feature? So we get out of the gates when we're talking about Agile. First thing, highest priority is to satisfy the customer. Now as we go through the other principles, we still need to keep that in mind because it's almost like you could say with every principle. Our highest priority is to satisfy the customer. Although this one specifically states it and tells us how or one way to do so, that's really what we're doing all the way through this approach, this process. And this again is something that I think had gotten lost a little bit. We're building software just to build software, just to see what kinds of problems we could solve. And there were some impressive, big, complex problems that were solved, but they were not always done in a way that satisfied the customer. There was almost a us versus them approach to some of that software. And I think in some cases still is where it almost feels like the software creators, the developers, are telling the customers what they need, what they should do, how they should approach to work, as opposed to how it should be, which is the customer saying, this is how we work. We need something to help us. If you're forcing them to change, then you may be helping them if they're doing things wrong, but maybe they're not. Maybe they're just doing things in a certain way and you need to help them do things in that way instead of change their entire approach. I'm not saying that either that both of those are not valid, but I'm saying that you need to keep the customer in mind throughout those sort of decisions and discussions to make sure that what you're doing is something that is actually useful to them, that will satisfy them. Now, the second part of this principle, through early and continuous delivery of valuable software. This again, there's a lot to this. Early and continuous delivery of valuable software. Valuable software would be something that brings value, to beat a dead horse maybe or state the obvious, that brings value to the customer. If you don't give them something, then it definitely does not have value. If you cannot deliver a product, the customer is not going to get any value from that until you do deliver the product, which goes to the first part of this. Early and continuous delivery. As you hear those words, we're now 20 years later or so and continuous delivery, continuous integration, those things are moderately common in the software development world. We're seeing that that is the way that we want to approach stuff, but that is an agile concept that definitely was not a part of some of the earlier processes, like the waterfall model. If you use the waterfall approach to software development, you're not going to get something in front of the customer technically, or you don't have to, until you're done. You complete the whole thing and then you put it in front of the customer. Agile says, you know what? We want to start getting feedback as soon as possible and more importantly, we want to take these big projects that take months or years to get done and find a way to do them so that we can get an earlier subset delivered to the customer and provide value to them. We see this now embraced in a lot of software where you get a version one that comes out. It's not necessarily that version one is as buggy, although it still very well may be because it just hasn't been through its paces. The key usually with the version one of software, those first releases, is they're very limited features and then you build on them. Software as a service in many, many cases uses this model in a highly successful way. You start off with something that is small, that provides some value. You can even charge customers so you can get a revenue stream going. Then you have that feedback loop of putting something in front of the customers and the customers tell you what they like or what they don't like. They tell you if this is useful or not. You can look at usage statistics in a lot of cases and see what do they use, how do they use it, are there things that maybe are frustrating to them or hard to find. You can make some adjustments and then you do the next version release and you get more feedback and in some cases that allows you to continue to add features, which means you can continue to bump up the cost, the price, the charge for that service, that software. You start revenue early but you continually get to build that revenue stream based on users and how they use it. You get this bootstrap approach, this feedback mechanism where you put something in front of them. You get some money for it, you get to use that money, push it back into development, create more features. But the key to all of that is getting something in front of the customer early. This is also very same concept, same idea to a minimally viable product. So an MVP may not be an agile approach. It may be, you could even do a waterfall approach, but what you're doing still is saying we need to get something in front of the customer that provides value as soon as we can. It does not help to delay and build features so that they'll have a bigger value in the future. We're better off getting them some lesser value today. So we want to get something in front of users as fast as possible that provides value. This isn't just to throw something out there and say, hey, look at this. It's something that would be useful to them that provides some value and then to be able to build on that on a regular basis. So it's not just get something out there and say, here you go. It's get something out there and then add features, add value, get that next version out, add value, get the next version out, add value, get the next version out. going so that the customers see value early on and they see a steady stream of new value that is being added to that system, to that solution. If you spent any reasonable amount of time in software development, you have probably seen this bear out in the real world many, many times. There are a lot of IT departments that that is almost their mantra, but definitely one of their major goals is to get stuff in front of users that they like and to steadily do that, to steadily add to what you're putting out in front of them. It leaves you as an IT department. It puts you in a situation where you are seen as being successful and having a stream, a steady schedule of successes, of things that are valuable to the customer. And that alone goes back to the primary point there of satisfying the customer in many cases, is saying, hey, we can't give you everything today, but here's something that you can use that brings value. Then you come back a week and a month later, whatever it is, you say, hey, here's some more stuff that adds more value. And then you just get on that path. If that's the trend, then how can anybody not like that? If I'm getting value today and I'm comfortable that that provider is going to continue to give more value in the future, that's awesome. I'm happy. I'm going to stick with that person. The only way somebody would beat out that situation would be if they were steadily providing even more value on a shorter time period or something like that. But it's essentially a case of more or better of the same as opposed to a different approach. Then when you think about getting in front of a customer early and continuous delivery, this is also a long held situation in the world of products and marketing and branding and selling. First to market. You get out there, you get there and get people using stuff, and then you're building recognition. You're building a brand. You're building brand loyalty. That is what you want to do in every piece of software. It's not necessarily first to market, but it is if you are competing against yourself, it would be trying to hit that first to market. Trying to be the person or the group that gets that software out there earlier than you otherwise would have. First to market compared to your other processes. When I did this class, this was one of the things that we highlighted. We looked at a made up situation of software development using Waterfall and a different one using Agile, using a Scrum, using Sprints and doing regular early and regular releases. That was one of the things we looked at is how you could get things like user comfort training and knowledge of a system built in earlier because they can use it earlier. You can actually give value. You have users that are actually making changes and utilizing some of those early releases. But then that also is a feedback mechanism for you to build some of those later things better. Sometimes even change course a little bit when you say, oh, we thought this was the way it was all going to work and the customer agreed, but they realized that that didn't work in the real world. It looked good on paper, but in reality it wasn't quite right. You get to build that in and at the end build something that is better because it's been tweaked or adjusted along the way. That's the first principle. Just go back to it. Our highest priority is to satisfy the customer. Number one, that is the thing we need to keep in mind all the time. Then through early and continuous delivery of valuable software, which just loops right back. Valuable software is software that satisfies the customer. If it's not valuable, it's probably not going to satisfy them. Challenge of the week. Take a look at what you're working on, whatever your current project is. Spend a few minutes. If you look at the key features, particularly if you're in a specific building, a specific section of the application or something like that, whatever your scope is, take a look at that. Are you building it to satisfy the customer? Maybe even build yourself a little list of if this gets done the way I plan on doing it. These are the arguments that it will satisfy the customer. It's a little exercise just to make sure that you are on the right track doing something that is going to bring value. One B to that, if you're building something where you could deliver something with value earlier, is that feasible? Maybe you try to get something with value earlier rather than maybe a greater value later. See how that works out for you. That being said, we're going to have to get back to the real world anyways and get to work. Of course, next episode, we will take a little another look into the world of Agile and how that manifesto is something that we can use on a daily basis to become better developers. Until then, as always, 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. There are two things I want to mention to help you get a little further along in your embracing of the content of Developer Noor. One is the book, The Source Code of Happiness. You can find links to it on our page out on the Developer Noor 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. Shoot us an email at info at developernoor.com if you would like more information. Now go out there and have yourself a great one.