Building Better Developers, Episode 425

This is Building Better Developers, the Develop-a-newer 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're looking at the Agile Manifesto. We have started off looking at the 12 principles, and since we've gone through all 12 of them, I want to step back and look at them as a whole. This is a lot. There is a lot to be learned. There's a lot to consider. There's a lot of experience that went into these principles. I'm going to think one of the things I want to do is do a summary real quick of these 12 principles. Maybe you'll see as I do that there's a couple things that fall out. Just going from 1 to 12. The first one, our highest priority is to satisfy the customer. It talks about early and continuous delivery of software. The next one, we welcome changing requirements and that we can actually gain a competitive advantage by doing so. Principle 3, we're going to deliver working software frequently. Number 4, the people, the business people and developers must work together daily throughout the project. The next one, we're going to build projects around motivated individuals, and then we're going to support them and trust them to get the job done. Next one, the most efficient way to convey information is face-to-face conversation. Next one, working software is a primary measure of progress. Next one, these processes, the agile processes, promote sustainable development. The sponsors, developers, and users need to maintain a constant pace. That one, talking about sustainable development in a constant pace. One of the next one, continuous attention to technical excellence and design enhances agility. The next one, simplicity is essential. Number 11, almost to the end, the best architectures and everything else basically emerge from self-organizing teams. And then the last one was that regularly the team should reflect on how to become more effective and then do so. As we've gone through those, maybe a couple things that will have jumped out to you is the idea of essentially consistency, regularity, regular intervals, continuous delivery, things like that. I'm sort of flipping through some of the words. It's just the sustainable and things like that. It's even indefinite. The idea of agile, one of the key things is that if we do this right, we can do it and do it and do it. We can do it continuously. We can do it over and over again. It is not only repeatable. It is something that we can easily repeat. So it's not something that is a burden in itself. It doesn't burn us out. It doesn't take away our resources. It allows us to continue to use those resources. Think about a hypothetical solar powered vehicle. If the solar power that you're getting from it can generate a certain amount of energy that vehicle works, is moving forward at that speed, then they're always going to have enough solar energy to be able to move forward. If they go too fast, well, then they're going to be able to progress and then they'll have to stop and then they'll progress and then they'll stop. The Agile Manifesto tries to level that approach. Remember that idea of a roller coaster. We've got these highs where we're very busy and probably working overtime and maybe vacations are canceled and stuff like that. We've got these lows where we barely get through the day getting anything done. We're just not terribly motivated and there's not a whole lot of stuff that we feel has an urgency, a need to get done. So it's really easy for us to come in late and leave early or take a long lunch or get sidetracked with discussions with coworkers or whatever. All the different things that can be not productive. So this continuity, this regularity is important and it really is important for a couple of reasons. But I think the main one that we need to think about is that regularity breeds habit. If you do the same thing at the same time, regular basis, it's going to become habit forming. It has doing these tasks on a regular continuous basis creates momentum to a point where it becomes a habit and then that momentum is very difficult to stop. That's what they're looking at. They're not looking at a silver bullet, do this and the next project you do is going to be perfect. They're saying, okay, slow and steady wins the race. If we make steady improvement, then we will get better and get better and get better and eventually become an unstoppable juggernaut of quality and success. They don't quite say that, but that's hopefully the goal. So while we've talked about this a lot in becoming a better developer, it applies as a team as well. When we make these incremental improvements on a regular basis, then they do build up and can become huge improvements in how we get things done. Another key thing that sort of pops out when you look at these principles altogether is the idea of teamwork and communication. You see it referred over and over again. You see mentions of the team and then you see the one specifically about communication, but how the team works together, which implies communication. This is a very important concept that I think has gotten better in my experience, but definitely was lacking and I think can be done. There's still room for improvement for sure in this area. The idea that everybody working on a project are, they become together a team and they need to work together. If you work on a project where you've got the business that has a lack of respect or isn't communicating everything completely to the development team or implementation team and the implementation team maybe thinks that the business side doesn't know what they're doing and maybe the testers think that the implementers are all incompetent or something like that and the implementers think that the testers are Nazis or something like that. Somebody's harassing them and then they're nitpicking bugs or something like that. Some of the stuff that I've experienced over the years, some feedback that people have and views that they have of different team members that they're not helpful to say the least. We need to work together as a team. We need to find ways to communicate so we can stay on the same page and when we do so, we will be able to get stuff done better. I hate to use the cliche of everybody rowing the boat in the same direction, but it really is a good visual essentially. If you've got everybody rowing the same direction, that helps. If you've got some people rowing in different directions and they're not helping, then probably you're slowing things down. In order to do that with a team, is it all of the people? Everybody's on that boat. That's I guess the thing to think about here. Whether you're the customer, the business owner, the business rep, the subject matter expert, implementer, tester, deployer, whatever it is that you do, you're on that boat along with everybody else on that team. That means that everybody needs to row in the same direction if you want to make the most use that team to the best of their ability. That doesn't mean that you can't have a bunch of people that are there for the ride and a couple people that are doing the rowing. That could be done, but it's not going to be as effective as getting everybody working. That's what this says. That's what the approach to Agile is. It says, hey, let's get everybody working together and make the most of everything that they do or that they, most of their skills. That's another underlying thing that is subtle or sometimes direct, is the idea of the team, as they say it, is actually self-organizing. Is the team owning the goal and allowing the team to own the goal and saying, okay, they all desire to get the boat across the river. Let's let them figure out the best way amongst themselves to get the boat across the river. That doesn't mean there won't necessarily be false starts and things like that, but it does mean that everybody will have buy-in. Everybody will have ownership. Everybody will hopefully be looking for ways that they can make improvements themselves. At the team level is great, but also individually. They'll look for ways to motivate themselves to continue to move forward, to get things done, to contribute to the bottom line. This goes back to the people in the boat. If you say, all right, it's up to all you guys, all of you folks to get this done. Think of the visual again. Let's say you've got 10 people in a boat and two of them are rowing and the rest are just sitting there. You're going to get interaction within the team to get more people rowing. The people rowing are going to say, hey, we could use a little help. I think the people that are there for a ride that are basically passengers will probably feel some guilt and say, you know what, I can probably help out somehow. Even if they don't necessarily, maybe they're not good at rowing, but they may find some other things that they can do. Maybe they get a glass of water for the people that are rowing. Maybe they look around and find some things that are dragging in the water that they can pull out and allow the thing to move with less obstacles or less drag. Or maybe there's a lookout that says, hey, watch out, we've got a turn here, we've got to move there. The analogy is not perfect, but the idea of allowing people to figure out where they can best be useful is huge. That's what we see is time and again, it's not only that we work together as a team, but that we own the fact that we are a team and we work together to get it done. That everybody on the team matters and is important in us getting across the finish line. The other big thing, which really I think most people think of these days when they talk about Agile and things like that, is the continuous or regular, at least regular delivery and even of working software. I think that is becoming baked into a lot of people's brains, is that that is an output. That is one of the drawing cards of the Agile approach, is that we do stuff regularly. It's key because that gets brought up many times that we're regularly delivering stuff, we're putting stuff in front of the customer, we're making adjustments, we're reviewing, we're moving forward in these steps and we're trying to make each step better. Each sprint, if you think of that as a step, we're looking at what we did, how we did it, how can we make adjustments and get better. This goes back to what we've discussed so many times, is how that incremental approach will build and eventually be huge. It goes back to the, it's probably an ancient saying that the journey of a thousand miles starts with a single step. You think about it, in that journey of a thousand miles, there were a lot of steps that got there, but eventually those steps added up to a large journey, a very long journey. That's what we have to look at. That's I think the other main underlying thing that I see when I look at these principles and hopefully falls out to you as well. This is not an overnight thing. This is not a one and done thing. This is a way of life, I guess, if we want to really add some hyperbole to it. This is an approach that has to be taken in the long term, with the long term goals in mind in order for us to really do it effectively. It's not something you turn on and off. It's not like you, hey, we're going to do Agile for a couple of months and then we're going to do nothing. Then maybe next year or two, we'll come back and we'll try some Agile again to see what we can do. You can try that, but the true benefits come from that regularity, the expectations and and the scale and things like that that we work with that get everybody involved, understanding how fast we're going to move, what are we going to produce, when are we going to review it, when are we going to make adjustments, when are we going to assess those adjustments, all of that accountability. That is key, is having that cadence so that we have our marching orders individually and know that this is what we need to accomplish by the time we get to the next marker, the next sprint ending. That goes back to that whole roller coaster ride. That is very key in leveling that roller coaster ride out. Because now, instead of us just burning at a very high rate for a while or not contributing as much as we could, we find the just right approach. Particularly, this is across the team. We find for the team we have, what is the just right approach for the amount of work and keeping us busy, but not exhaustingly busy. It's not even just keeping us busy, it's keeping us productive. Instead of us filling out busy work and things like that, we focus on getting the things done that we need to get done. That itself is a cure for busy work. If you think back to when you were in grade school, busy work was what you would get if you had an hour, if everybody had an hour to take a test and you get done in 30 minutes, then the teacher may have some busy work for you to do to keep you busy until everybody else finishes the test. That wasn't necessarily productive, it was just a way to keep you busy. We still do that. If we go to work for an eight-hour day and we have six hours of work, then we'll find something to fill that eight hours up. If we've got eight hours of work, we're going to do eight hours of work. We're going to be probably more focused on that. That doesn't mean that we won't get sidetracked and have things that derail us a little here and there, but it does mean that our focus is going to be, our aim is going to be to get eight hours of work done. If you only give us four hours of work, then our focus is going to be to get the four hours of work done, and we'll probably end up getting the four hours of work done in eight hours just because we can't. That's just human nature. I think those are the key things that we need to think about as we continue looking a little bit into the, as we move off the principles and look at some other things about the Agile Manifesto is that it really is, it's about the team. It's about regularity. It's about building habits and momentum. It's about owning what you do as a team. It's about being given the respect and the freedom to get the job done right and then go do it. Get the obstacles out of the way. Do what we can to remove busy work and things like that and allow people to be as productive as they possibly can. I think that'll do it for this one. Give you some time to reflect on that and maybe some ways that you can make some adjustments to fill out your schedule a little better without busy work but with actual productivity. That being said, I'll send you back out into the wild, but 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 Noir 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 developernoir.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 Noir. One is the book, The Source Code of Happiness. You can find links to it on our page out on the Developer Noir 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. Please shoot us an email at info at developernoir.com if you would like more information. Now go out there and have yourself a great one.