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 have spent the first part of the season looking at the 12 principles. We're not going to belabor the point anymore on those, although we probably will refer back to them as we move forward in this season. The next thing I want to do is basically take a step back or maybe high up, depending on how you look at it, and look at the actual manifesto itself. It's a very simple manifesto, and these things lead to those 12 principles. But there are some very important things that I want to discuss that are on this, that are part of this main part of the manifesto, I guess the overarching manifesto itself. The principles are great. They help us figure out how to implement things. We learn quite a bit as we've walked through those. Now let's step back and take a look at the overall one. I'll start by actually going through the full manifesto. You can get this at AgileManifesto.org. Here it is. Quote, we are uncovering better ways of developing software by doing it and helping others do it. Through this work, we've come to value individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more. This episode, I want to focus on that first of the four things that they have come to value and that one being individuals and interactions over processes and tools. This is a very important concept. I think that we overlook way too often. There is a method to solving problems that we use and we more or less fall into it. It becomes a habit. That is essentially where processes and tools come from. We have this way and it's not necessarily when you're starting out, you haven't really learned much, but as you get further into software development, it is not uncommon for us to have an approach, a way that we do stuff, tools that we use, that that's it. In some cases, this has actually gotten worse. There are more than a few developers out there that are, while they're helped by frameworks and libraries, they are also hindered because they don't actually know how the underlying pieces work. If you ask them to do something without those libraries or without those frameworks, without those tools, they're simply not able to do it. When you think about, for example, code generator type tools, that would make sense. I guess it makes sense to some extent. That being that maybe that's the purpose of that tool, is that you don't need to know the underlying code that's generated or how to create something other than through the generator. Think about an access, Microsoft Access application. The goal for an access application or FileMaker or something like that, similar kinds of tools, is that you come in, you essentially define your data items, and then Bob's your uncle, you've got an application, you can edit your data, you can browse it, you can search, things like that. There are situations where the tool is all-encompassing as far as the solution is concerned, but it's a little too easy for us to use those as a crutch. As an example, even from way back when I started, we built a framework, a library that lived on top of another development environment. We ran into people that, it wasn't a ton, but there were people that they used our framework and that was basically the only way they could do things. There's certain tasks that the only way they could get them done is if they had our framework, because it took the tough stuff out of it. Think about, for example, connecting to, like sending email. Probably you have not had to build an email sending tool in your language of choice from scratch, maybe ever. If so, probably not in a long time, because there's libraries and frameworks and add-ons and tools and things like that that allow us to do that without writing a bunch of code, and then we're off and running. We don't have to think about it. We don't have to worry about it. There is a value in that, as I think I just explained. The idea that we can jump in, we don't have to reinvent the wheel, and we can solve real problems. However, it's easy for us to become essentially a slave to our processes and our tools where we have this approach, we'll say, to problem solving, to creating a solution, to working with a team, to communicating with our customers. If somebody doesn't fit that niche or doesn't work with our processes and our tools, we can struggle quite a bit with them. Not only that, sometimes we become almost blind. It's essentially a blind spot that some of these tools and processes are not built to do everything. If they don't do it well, suddenly we have to solve a problem that's not in the, as they say, in the wheelhouse for that technology. If it's not a strength of what we're using, then we really struggle or maybe say it can't be done, which is maybe true, but probably is not. It's probably we can't do it with the tool that we're using, with the processes that we're using. Sometimes those things can be, well, they can be helpful. They can also be a hindrance. If you've ever worked in an enterprise software development group where they've got multiple teams or silos or groups and everybody does their own stuff. You've got, for example, front end developers and middle tier and back end and you've got DevOps and QA and all these different groups. You've got all these processes so that code can be written and then committed into essentially a stream of stuff that eventually gets deployed and tested. Of course, you've probably got processes that if you're a front end developer and you need a data field, then you've got to go somehow submit something so somebody on the back end side will actually create those things for you so that your data can be stored. Maybe there's a middle tier person that has to write the code to interact with the back end that's got to be created and then eventually so that you can make a call on the front end to do what you want it to do. You can be ponderous and that's not to say that that's wrong because it's not. There are some cases where you really need that audit trail, where you don't want people just slinging code around, where you want to do, you put a lot of checks and balances and verifications and reviews and things like that. But that's where this point comes to the forefront. We value individuals and interactions over processes and tools. So this says we value what the team does, their specific communications and skills and approach over trying to get the team to follow processes or use specific tools. A good example on the tool side of this would be, you can use an integrated development environment to let's say write a little shell script, especially if the shell script's like something simple like copying a file, file A to file B, you're going to create a cron job that's just maybe doing a simple backup kind of thing. It's just copying a file from one place to another or a series of files from one place to another and it's just a really simple couple command shell script. You could have an IDE, you could open that thing up, you could build a little project with any IDE and use that for your script and all that kind of stuff. You could put a lot of build processes around it and all that, or you could jump into like VI or Emacs and get the thing done in 30 seconds and not worry about it. It may be, depending on how you look at it, it may even be something you don't even need to do like version control and stuff like that. And so you have a, we'll call it the system, you know, capital T, capital S, the system that your code gets into normally, which are maybe very heavy processes and tools and all these things to make sure that we can keep track of everything we've done, who did it, when did it go, when was it pushed, when was it tested, when did it fail, what was done, or the fixes, the whole everything, which is, does have its value. But once you get in the system, then that means that everything you do has a cost to it. There's additional overhead based on it. And that's where this point says it's maybe sometimes you don't need to put stuff into the system or maybe the system needs to be simplified or allow for things that are not going to be either not that heavy that they can't either can't or shouldn't have that overhead of what the system incurs on it. Now, we've talked about the letting the team be the team, you know, be that individual team when we talked about the 12 principles. But this is where and this is where that came from, even though that's there's some different arguments and some different ways to look at things. This is partially where that, you know, where that falls out of, where you get that principle from the individuals and interactions is saying that in a sense, yes, processes and tools are helpful. For example, taking notes, you go into a meeting and you take notes and that is a process. It's a tool, pencil and paper. That's a tool or tools that you're using. And taking notes may be very useful in helping you understand whatever needs to be communicated in that meeting. But the important thing is not the process is not the tools. It's that you understand that thing that was communicated in the meeting. If the end goal is achieved, then the processes and the tools used don't really matter. And this is where we fall into a rut that sometimes takes us over a cliff. Especially in the IT world, I've seen way too many situations where you have particularly consulting type companies and things like that and development teams that have worked together for a while that they do. They have a way of doing stuff. They have a set of tools. They have a technology. They have a platform. They have an ID. They have whatever. All of these tools and processes that they use and that's what they use and they're fishing at them and they can get work done quickly with those tools following those processes. And maybe there's a whole bunch of other bonuses to that where it's very easy for the customer to see into what they're doing, to communicate status and progress. So there's nothing wrong with that. But the thing is, is there's a certain point where you have to, have to is even a strong word, where it is useful to take a step back and say, are the processes and tools that we use the right ones for this problem? Are they always the right one? Are there situations where maybe we can skip around the processes or to use a different tool? Or not. These are, these are things that are becoming sort of in a way, they are becoming less of an issue as we move to more and more remote workers and developers that essentially have their, their personal development environments and they use VPNs and things like that to connect into the team or they commit into repositories and things, but they, they don't have to be on necessarily the same tools. The same processes. Now that is not a silver bullet that causes problems at times too. If I'm using Eclipse and somebody else is using IntelliJ, let's say, and, or heck we could both be using Eclipse and if we've got different settings for, you know, probably the worst one is whether you use tabs or spaces for, you know, coding style things, you know, that maybe your ID enforces it or not, or maybe it pretty prints in a certain way that somebody else's doesn't that can cause all kinds of headaches. If you're trying to use a, do a diff on changes and it's not smart enough to figure out white space and simple formatting, things like that, you can simply use Eclipse and you can do it. White space and simple formatting, things like that. You can, you can easily get a very big source code file that the diff thinks everything changed. And you'll find out that, no, actually you changed, you know, one line of code. I have literally seen those things happen. And so there's, there is value in processes and tools and consistency. Do not walk away from agile thinking that the things on the left that we're talking about individuals and interactions, that's the thing on the left. Do not think that those supersede the ones on the right, in this case, over processes and tools, individuals and interactions has more value than processes and tools. That does not mean that processes and tools have zero value. That does not even mean that processes and tools have little value. It just means that individuals and interactions are more valuable. And I think that's where a lot of the misconceptions about agile come from, is the idea that, oh, we just work, focus on these things on the left that we're talking about here, and we don't even need to worry about the things on the right. Well, that's false. Very false. These things on the right are needed. Processes and tools are needed. They are valuable. You will be very hard pressed to do complex software without processes and tools. The point of this is not the processes and tools being of lesser value. The point of this is that individuals and interactions have a greater value. Think about that meeting. What is the purpose of the meeting? It is to convey information. Now, there may be processes or may be tools to help do that. You need PowerPoint slides or handouts or Zoom if you're doing remote meetings or PDF files or like I said, pen and paper to take notes. There may be a process and an agenda and we fall on agenda and then somebody afterwards sends out an email that says this is what was discussed and this is what the action items were and things like that. All those processes, all those tools are not worthless. There is a great value in those. But what we're saying here is what was the purpose of that meeting? It is to convey information. So if the processes and the tools get in the way or are not doing the job, then it falls back over, it's the individuals interactions went out. You don't become a slave to the processes and the tools. You don't say, well, we've got to follow this process. We have to use these tools. No, you need the individuals and the interactions to be able to do what they are asked to do. And the process and tools are about getting things done and communication. Individuals get things done. Interactions provide communication. So you could almost simplify this to say, there's all these ways you can do stuff, but the most important thing, the greatest value is getting things. Done. And I don't mean this in the, uh, the sort of the copyrighted GTD, getting things done, it's there are objectives that need to be met. And if there is, if there is a problem with using processes or tools in getting that thing met, then the goal needs to, the objective needs to be met period. That needs to be our focus. That is our why. And that really is what agile is about. You can call it, obviously you can call it agile software development as they did it's agile and there's or agile, however you want to pronounce it, but there are, there are values to it and there are agility properties, you know, properties that would relate to agility for a team and for a project that come out of this, but really agile is about focus is about keeping your focus, keeping your eye on the prize. What is it that we are here for? We are here to solve a problem and provide a solution to our customers. That first little bit we've talked about satisfy the customer. So if there's something we're doing that is not pointing towards that, if we are not keeping these essential critical objectives in mind, then we are not going to be as good as we could be. We're going to drift. We're going to get lost going down rabbit holes. So when in doubt, question your processes, question your tools if you need to. If you need to, it may be that everything's humming along fine and everything points to getting solutions out the door fast or deliverables delivered quickly. But maybe they don't. And so rather than spend a lot of time trying to figure out these complex plot processes and tools and how to make them all work, maybe even jamming a square peg into a round hole, sometimes it's better to step back and say, okay, what are we really doing? This meeting got totally out of hand. What was the goal of the meeting? Sometimes take a step back and you're going to see that, oh, we, we got way off track, here's what we need to do to just accomplish our goal and move on. That being said, my goal is to get through this first point and I have, and so we're going to claim victory and move forward. Challenge of the week though. I want to get back to that on these, as we move forward into Agile season, take a look at the processes and the tools that you use and do you find yourself being a slave to them? Are you using them or are you allowing them to use you, you know, to get a little bit philosophic about it. And if they're using you, then maybe you need to step back and see if there's some ways that you can master them again and make use of them instead of being a slave to what they, their approach or the, the approach, the type of style or whatever it is that they impart to you. And that being said, we will now go ahead and part ways, but as always, go out there and have yourself a great day, 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 today is still progress. So let's keep moving forward together. One more thing before you go. Developer Noor 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 be great, if you go out to developernoor.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.