The Agile Manifesto and its 12 principles

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're continuing our season where we are looking at the Agile Manifesto. At this point, we are focusing on the 12 principles that they laid out many years ago. Some ways to literally become better developers, to improve the software development process and all of the challenges that are involved. These are, as we've talked about, these are some theoretical things maybe. This may be academic, but this is grounded in the real world. Each of these principles definitely has a value to look at for your day-to-day software development approach. Particularly if you're building applications and not just out there slinging some code or something like that. If you're out building something and not just maintaining it, you're going to find that these are excellent ways to improve your productivity and your odds of success for your project. Now we started the very first thing, first principle. Our highest priority is to satisfy the customer. I want to make sure we keep that in mind as we move through each of these principles. This episode, we are looking at the fourth principle, taking from top to bottom, but not actually numbered out. This principle is, quote, business people and developers must work together daily throughout the project, end quote. This may be, this was definitely a big deal when it was proposed. There were instances of people doing it, but not to the level that it is today. And this is one of those that again has directly impacted software as time goes on. I think everybody has found that this is one of those things that really, really needs to happen. You cannot have business and developers in silos and throw stuff over the wall and expect it's going to work right. There are just too many communication challenges to say the least that will make that a very difficult and time consuming process. Instead, you need to have cohesive teams where the customer and the people representing them, which would be the business people, are able to talk directly to those that are implementing, which would be the developers. Now, this sometimes gets stretched out, we'll say. So there's some middlemen or women in the process. So you may have, for example, maybe a lead or a manager on the development side and a subject matter expert or business analyst or something like that on the business side. And that can work depending on what the skill level of those people are and how they interact with their teams and peers. But I have found even with junior developers where you wouldn't expect them to do much more than be able to code, it is useful for them to have interaction with the business people, with the customers. It helps them get a better sense of what really matters. What is the why for this project, for the solution that we're building? And the interesting thing that this little principle is it says business people and developers must work together. It's not that they should, but that they must. And this is easily overlooked, but it is a critical factor. This goes back to what I started with. If you have developers in one group and business people in another, you are going to have, and they don't directly communicate, you're going to have some serious problems. You're going to have very big challenges. This is one of, I think, the biggest problems that we run into when we have offshore teams, is that inevitably you have a person, maybe a lead or maybe a couple, that represent the developer side. And then you have the business people. And so there's always this translation from business to lead to the team. And the team, a lot of times, does not get the why. They don't get the reasoning behind what's going on. They just get marching orders. This is what you need to code today. Write this thing that does that. They don't get the big picture. And sometimes there are some people that do this better than others. I don't want to say this is always by any stretch. But when you think about it, there have been more than a few times I've dealt with offshore teams where they don't even have the ability to do a full build, to run the application they're building in a meaningful sense. They're not able to actually use what they're building. They're just writing code, and then it's somewhere else being put together. And that's just, it can be done, but it's very, very challenging. And time consuming. Because they don't, they're almost having to guess their way through some of the work, instead of having a solid understanding of what they're building and why they're building it. Now, an interesting little nugget that drops out of this, if business people and developers must work together daily throughout the project, that means that from the Agile Manifesto, there is a presumption that developers can and must have some business acumen, some business knowledge, some ability to comprehend and work with the business side. And that the business people must have some IT knowledge, some knowledge of the development process. Now, this doesn't mean that business people have to write code or developers have to balance the books. But it does mean that there has to be some level of understanding amongst these team members. This is critical as we build teams. If we do not do some sort of at least exposure of developers to business and business to the developers, you're never going to get this principle. Because people aren't going to be comfortable or knowledgeable of the things they need to have in their arsenal to be able to get the job done. This is part of becoming a better developer, is that we don't just do the technical things. We need to also understand the industry that we are in. And not from top to bottom, although that would be helpful, but at least have some understanding of it. And I think most of us get that over time. You may walk in as a green new employee in healthcare, but over the months and years go by, you're three to five years in, you're going to have some understanding of how that portion of the healthcare industry works. Same for finance and things like that. And I think as team members, we should push to have our ignorance corrected, I guess, in these situations. Do what you can to maybe read trade journals or just sit in on meetings that are maybe not necessarily a development meeting, but where you can, read through some of the emails that go across. Get a feel for what's going on in that company and be, I'd say, hungry to learn more than just what your coding role is or your implementation role is. Get an understanding of the environment and the complete solution, and that will help you. That will help you help them. And that goes back to, highest priority is to satisfy the customer. If you're having to guess, that's not as useful as when you're able to talk to the customer and say, OK, this is the environment you're in. These are the requirements and the constraints that you live under. Here's ways that we can address those. As opposed to them trying to explain those constraints and requirements to you and you trying to figure out how that works and then push that back to them and say, OK, is this right? Are we there yet? Did I get it for you? Did I meet your needs? That's a question you're going to have. You're going to ask anyways. At the end of the day, at the end of the project, you're going to say, OK, here it is. This is what we're doing. We think this covers your stuff. Are you satisfied? Is this what you need? But a lot of those questions should be the ones that we can to somewhat answer ourselves. We should have enough knowledge that we can understand that, oh, this solution will not work because they have these requirements that mean either the format or the data or whatever is not going to work in their environment. This is where we get the special things that are those little extra touches and really the value adds that we can bring when we can marry our technical knowledge and experience with business needs and requirements. And we can't do that if we don't understand business needs and requirements. Now, the nice thing here is that although this presumes some level of knowledge or at least ability to gain that, it works without it because business people and developers must work together daily. I don't care what it is. If you work on it daily, you're going to get better at it. And the working together means that both sides are by osmosis by just working in that environment and hearing how the team progresses and what they do. They're going to start gathering knowledge about how the other side does their work, how they approach this problem. And that's going to benefit the whole team because what you where you start with, you know, in a clean slate, you start with a lot of very ignorant people because they don't understand the other side. But that ignorance gets brushed away as they work together. And so as you work together as a team further on, and that ignorance has been pushed away, now you've got a better foundation and you can go deeper. You can understand better and you can continue to grow. But you're growing on a foundation that's stronger and stronger and larger and larger. And so this is where you can have teams that can start out OK. But as they work together over time, not just the technical side, not just the business side, but the whole team, they can get much better as they go. And I have seen this and you probably have to if you spent even more than a few years in development, especially if you can spend a year or more with essentially the same team. They're going to see how they get better. They have an understanding of the constraints and the requirements and the processes of the other side and things that maybe early on were challenging or time consuming to review or to go over become very quick because everybody's on the same page. And then there's that foundation means we can start focusing on the competitive advantages and all the extra things, the extras that we can add into a project as opposed to trying to hash through the essential or the critical requirements that we have to deal with that everybody in that industry has to address for their products. Now, the daily working together daily, I think, is one of the things that has brought us to sort of to the daily stand up because that at least gives us a touch point every day. Now, a stand up is not supposed to be some long meeting where everybody hashes through what they're working on and especially with larger teams that can be get out of hand very quickly. But what a stand up does is it gives you at least a quick scheduled thing every day where you can basically touch on what's our focus. And you're going to hear it's not a working session, but you will mention items that may require working sessions. And it gives you a point for everybody to be able to talk to each other. So if a developer has a question for a business person, it doesn't have to be answered in that meeting. But that's a perfect time for the developer to say, hey, I need to schedule some time to talk through this or vice versa. There may be a business person that says, you know, we're we don't think you guys quite understand this. So let's schedule some time where we can walk you through what our needs are. Those kinds of things, those touch points, at least build a relationship between the various members of the team. And it tends to open communication a little better. It's a little easier when you're talking to somebody every day to say, oh, yeah, I'm going to send you an email for the set up a meeting or I'm going to give you a call so we can talk through this. Or I'm going to chat whatever our chat mechanism is. I'm going to chat with you about this because we need to walk through it. Or you may have a group group emails or group chats or tools like your Slack or Teams or something like that. But that gives you that daily. Starting point. That is that also includes the other side. If you're a developer, it's easy to get in a silo, go down a rabbit hole and be working on something for several days and not think about the business side at all. You're focused on your problem. If you're a business person, you may have all of these things that have nothing to do with that project that you have to do. And it's easy to go a couple of days and get lost in your other work and really not think about this application or solution that's being built. The daily thing keeps it more in upfront in people's minds. What is going on? Not just their role, but what the team is trying to accomplish. It's going to build cohesiveness. And like I said, I think there's this osmosis you get by hearing how some of the discussions of the other side that work. That it enlightens you. Much like if you work in a bullpen kind of setup where you've got several people basically open cubicles. So you're hearing other conversations even while you're working. Yes, it can be distracting, but also it can be a good learning experience. Be very educational because you're going to hear how other people are working through problems. And you may be able to throw a suggestion out there that helps them get to a solution a little faster. So this one, although short and simple, it's very, the payoff is incredibly big. But the bottom line is assume that you as a developer assume that you are going to help your customer more if you understand their problem more. If you have some level of business knowledge for the domain that you're in. And that may mean that you have to do a little work on educating yourself in that area. But that's okay. We talk about becoming better developers. We talk about things like moving the ball just forward a little bit every day. In this case, maybe spend 15 minutes a day flipping through industry websites or blogs or news. Or reviewing some of the documents that the business people are pushing around and creating. Looking at some of their projects. Or just talking with them about what they're doing and what their challenges are. When you do that, you're going to find that you're going to be able to work together better. And your project is going to be better. And the odds of success are going to increase. That being said, I think it's time to get back to it. So whether you're focused on technical stuff or you can expand that business knowledge, it's time to get back to our day. And 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. 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.