Building Better Developers

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'll continue our season where we're looking at the Agile Manifesto. We're going to dig a little deeper into it and see where it can help us become better developers, where it can help us get software out the door better, faster, higher quality. We're looking at the 12 principles, and we've reached principle number 12. This is not going to be the last episode. We're going to look at some other stuff, but it felt like the principles were the best place to start, at least. And without further ado, let's look at that 12th principle. It says, quote, at regular intervals, the team reflects on how to become more effective than tunes and adjusts its behavior accordingly, end quote. This is a perfect final principle. When you look at what we've talked about in the prior principles, they are all somewhere along the way of suggestions up to maybe requirements, essentially, for improving the way we build software based on the non-Agile approaches of the past. This is what people have gotten together with when they put together the Agile Manifesto. They said, let's look at our experience, the good, the bad, and the ugly, and figure out some guidelines we can use to get better, to do this better. We've done it enough times. We should be able to improve it, which, interestingly enough, would be the equivalent of a team reflecting on how to become more effective, and then tuning and adjusting accordingly. Now, this was actually a group of teams, and they don't do it at regular intervals, at least not from the manifesto itself. And they didn't really tune and adjust. They made recommendations. But they realize that this is a key step in getting better. It accepts the fact that we don't do it right the first time ever. None of us never happened. It's just too much going on. You're not going to get it perfect. If you did, it would be on accident. So there's always going to be room for improvement, which means if we want to get better, then we need to regularly take a look at what we're doing. How is that going for us? How can we improve on what we've done, and then take the steps to do so, and then repeat? And all of these are very critical. I think we'll just start from the beginning of it. I think the regular intervals is really something that goes into their whole idea of becoming a better developer and some of the things that we've espoused. You have to periodically take a look at what you're doing, how you're doing, how's that working for you, and assess it. You need to grade yourself, whether it's an individual or a team or an organization. You need to grade yourself periodically and then use that to make changes. And I think the regular intervals is key. And I say that because we need to have a scope, essentially. We have to have some constraints around what we're trying to do and holding ourselves accountable to getting it done. If we don't do regular intervals, if we just randomly do stuff, then we have no idea how long we have to make an impact before the next interval, before that next grading session. And along with that, that means that we don't have an idea of what kind of advances can be made in that time. For example, if you do it every week, then you're going to take small steps. And you're not going to be...actually, you wouldn't even probably be able to necessarily directly impact big change. You'd have to find a way to do it incrementally on that weekly basis. If you do something once a year, then the day-to-day and even the week-to-week stuff sort of gets lost in your bigger goals. Now, that's not to say that you can't adjust accordingly. It's not to say that you can't take weekly goals and build those into a year's worth of progress or take some annual goals and find a way to break those down so that you can make weekly progress on those. But however you do it, it makes sense to know that that's the approach you're going to take. If your focus is going to be really on annual goals and you're meeting every week, then you may end up spending a lot more time on the assessment of those annual goals than you need to because you're not going to be achieving those annual goals. You're going to be achieving the weekly goals. Of course, if you meet after a week and then you meet after a month and then maybe take a couple of months and then you meet and then a couple of weeks later you meet in this random thing, then you don't really have a scope to decide how many, for example, weeks worth of work should I be able to accomplish or improvements should I be able to accomplish before the next time we meet and review. The nice thing about the regular intervals is it allows us to say we've got X amount of time, we're going to get A, B, and C done in that time. Then when that time elapses and you go back to another reflection period, then that's one of the things you're going to do is reflect on how did we do on the adjustments that we said we were going to make, the tuning that we said we were going to do. Did we get it done? The reflection part of this is I like to think of it as being very open-ended. People call it green fields or blue skies or something like that or just brainstorming or whatever. The idea here is to say let's look at what we do as a whole. What are all these different things that we do? Maybe as combining them, how did we do? But then really I think the more important thing is stepping into those individual pieces. The thing about software development, so it would be stepping into requirements and design and implementation and testing and deployment. All these little things that add up to what we're trying to get done is reflect on them, take a look at them. As a team, it's not just the testers work on the testing and the implementers work on implementing and the designers look at how they design. Because the outsiders to that group have very valid and sometimes critical insights into how you can do things better. Sometimes we have our heads down focused on our area of work or expertise. We always get blind to how other people perceive what we're doing. We also buy it that very nature. If we're just focused on our area, we're not going to improve our interactions with the other areas, with the other team members. Doing this as a team and spending time reflecting and leaving it wide open as to what have we done right, what are we doing wrong, where can we make some adjustments, where can we tune this and get better. When we open it up to that, then we allow ourselves to really improve everywhere instead of maybe limiting what we can do. Because we can tune everything from specific areas of work and getting tasks done to processes, to communication, to delivery mechanisms, all that. It's all on the table. That's, I think, key for us to continue to improve. Because if we, let's say, this is maybe an extreme case, but let's say we focus just on implementation. Then over a period of time, if we're doing it right, let's say that we are improving our implementation approach on a steady basis. We're just going to get a point where the return on investment for doing that becomes very minimal. Because we're constrained from actually making other improvements in the process, such as integrating with other areas, other steps of the process, how the other team members work and things like that. There's also a, I don't know, it's almost like a going hand in hand. There's some synchronicity, I guess, for lack of a better word, that we can get when we're working in multiple areas at a time. Particularly when you think about things like communications and interactions across teams, is that it's usually not one section or area that's entirely the problem. There's an adjustment or tuning that actually needs to be done in a couple different areas in order to make it work more smoothly. It's not just a matter of, let's say the implementer is sending a weekly status. Maybe it is the design people that are trying to stay ahead of the implementers also need to kick some information back and do a better job of communicating back to the implementation team so that everybody can stay on the same page. It's just a random example, but there's a lot of that that I think, and particularly in my experience, there's a lot of that kind of stuff that goes into, or I guess comes out of these meetings. We look at how everybody did everything, how was it perceived, and then where can we make some adjustments. And it doesn't mean that we have to do all of it at once either. That's the nice thing about the regular intervals is, particularly if they're reasonably sized, then what you can do is you can say, well here, we've got this long list, and you probably will early on. You'll have a long list of things that you can do better. Well, what you do is you take those off in bite-sized chunks and say, well, we can't cover everything, but let's for the next period just focus on this little area or these couple of areas. And then when you get to the next review, you look at how did our adjustments work? Did they improve things, which hopefully they did? If so, how much? Or maybe we went in the wrong direction, and so we need to adjust those, adjust our adjustments. Or maybe we made very good progress. We say, okay, now we're going to find something else. Let's focus on another area. And particularly when you start early on, there's going to be some things that are, we'll call it low-hanging fruit, which are easy to do, easy adjustments to make. And then there's also going to be some things that have a big bang for your buck where you don't have to do a lot of change or a lot of adjusting. And you think that will make a very big positive impact on your team and your process and what you produce, your deliverables. So when we get into this cadence of regular intervals, reflecting on how to become more effective and then tuning and adjusting, we start building momentum and we start building habits of looking for ways to get better and then following through with adjustments to do that. And this is another side effect of doing this at regular intervals. When we do this on a regular basis, then there's going to be an expectation by the team that we're not going to do this once and then be done, that we're going to regularly have these meetings, we're going to get together and we're going to talk about what we did right and what we did wrong. And I think doing that alone, having that regular meeting is its own form of accountability because we don't want to come into the meeting time and again and say, well, I just can't think of anything because we probably will run into stuff that's a frustration or a pain point or something like that. But we may forget when we get into the meeting. The key to doing this regular interval is that we're going to have it in our mind that is there something that would make sense to discuss in that meeting or when something bothers us, when we reach this pain point, we have an outlet for that where we can say, you know, this just didn't go right. I'm going to make sure I take a note of that or a mental note or whatever and I'm going to bring that up in our next meeting because I think it's something that we could maybe make some improvements on. And of course, even better, now if you've got that in the back of your mind for a while, you may have some great suggestions by the time you get to that meeting and you can say, hey, you know, here's something that we ran into and here's a couple ideas I have where maybe we can make some adjustments, where we can tune this and make it an on issue or reduce the frustration. And even though I'm focusing in that case on an individual's experience, opening that up to the team is where you get the real value because you have all of these different points of view into the process. And you're saying, OK, let's go, you know, essentially go around the room to all the people that are involved in all these different points of view. And let's see what they see from that point of view. What do they see that we can do to make adjustments to improve things? And as I said, it will be if you, I want to say if you do it right, it will be overwhelming at first. But that in reality, I haven't seen that. We usually what happens is the first couple of times there's some things that are usually very obvious. There's some big changes that can be made to do some improvements. But the quality, the quantity and even the quality of feedback is not as good because the team is getting comfortable with what makes sense. And we feed off of each other. So I think there's a lot of times where we come in and we don't really have any ideas per se. But then as we start listening to the other team members talk about what they've experienced, it triggers stuff in our head that we say, oh, yeah, you know, I ran into this thing that may be related or maybe it's totally unrelated. Yeah, I had this other issue that I ran into and I want to make sure that we take a look at that at some point. You know, we get this give and take that sometimes we only see something partially with our point of view. And when somebody else adds in, you know, provides their point of view, it helps us maybe see something and, you know, maybe in total or at least enough that we can say, oh, yeah, here's some we need to address this thing. And here's a different point of view of some opportunities we have to tune it, to adjust, to make those changes and to get better. And this is not, it's weird because in software this really didn't happen before and it still doesn't. There's a lot of places where they don't do, they'll do agile approaches and scrums and sprints, but they won't do retrospectives. They won't do postmortems. So there's organizations that they will crank out software after software after software, but they don't really ever look back at how they did spend time to reflect. And you'll find that they they're not going to get better other than maybe haphazardly because you may have individual members that do this even if they don't as a team. And so they may be bits and pieces where certain people are involved and they are getting better because they are finding a way even just with themselves to reflect and get a little bit better. But the real advances don't come until you do it as a team. And it's sort of odd that it isn't more common because if you look at a lot of other areas, we do this, we do this regularly. Now, most jobs, I don't want to say, I don't know if that's most jobs, but I think probably it is even if you don't have an official review, most jobs have some six or 12 month review kind of thing. And it may not be formal. It could be completely informal. It could be your manager just spending five minutes and saying, hey, I like how you did this or hey, you can do this a little better. But we do get that feedback. And when you look at high performing teams, you look at like sports teams, they get coached and typically will reflect on probably at least a game by game basis. Most of them, if you listen to any media stuff after an event, after a game, after a match, then they'll talk about, you know, we did this right, we did this, that wrong. This is how we're going to get better the next time we play a game. And so why not do that with our software as well? And in a way that with chunks that are workable that we can actually work with and make some changes. Thus, if you do sprints, sprints are perfect. They are nice little self-contained periods of time, you know, amounts of work. And it was very easy for us to then say at the end of a sprint, okay, let's see how it did. And of course, we're going to jump right into the next sprint. So let's see how we did on the last one. Let's see what we can do to improve the next one. And I think that is key. And it does go back to, and we're going to talk about this more as the season progresses a little bit, because we're going to go back and look at some other key statements, I guess, from the Agile Manifesto and how these things need to percolate into our life, into our professional life. But I think we're going to, there's things like the length of a sprint that become much more important when we want to do this right. A week, you know, doing a sprint a week can be very difficult to get this retrospective in. It can be almost too small. Of course, if you did a six-week sprint, it may be too big because you may forget things that you ran into in weeks one and two of the sprint, and it's going to be sort of top-heavy or back-heavy. You're going to be more likely to discuss things that happened in week five and six of that six-week sprint. So when we start putting these principles together, I think a lot of stuff falls out that is now, good on us, I guess, is now becoming much more common in the software development world. And we'll probably talk about that next episode because we'll go back and we'll walk back through these principles before we move on to a couple of other areas in here. But I think that's it for now. I think we'll allow ourselves to, not necessarily a regular interval, but I guess sit back, reflect on how to become more effective, and then we can tune in and adjust our behavior accordingly. But one adjustment you don't have to make is you just need to go out there and have yourself a great day, a great week, and we will talk to you next time. If you like this one, you can find us on Apple Podcasts, Stitcher, Amazon, and other podcast venues, or visit our site at developer.com. Just a step forward a day is still progress. So let's keep moving forward together. One more thing before you go. Developer 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 developer.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.