Building Better Developers, the Develop-a-Noor podcast

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 and finding ways to improve our software development through some of the principles and guiding ideas that that puts it down. Now this again started from people that really spent the time and learned about software development. The combined years of experience was some pretty high number. Most of the people involved were decades into building software. Now that was also a couple decades ago. So things have changed a little bit. Mostly they've improved. And in this episode, we're going to address that basically. We're going to look at the sprint retrospect and how to use that to get better from sprint to sprint to sprint. And we've already talked about how the first couple of sprints of any team is going to be challenging. And that doesn't mean bad or anything like that. Just everybody's going to have, depending on where you're at, how often this team has worked together, you're going to have different experiences and different processes and sometimes even different language. There are some teams that go out there and they don't use a sprint review or a retrospective or a standup or at least a daily standup. And those things could be called just about anything. They could call it a user demo. They could call, they could just say their status meetings. There's all kinds of things that can be done that would basically confuse people a little bit coming into a sprint. So the first couple, you're probably going to have a rather large amount of things to work on. And most of those are preamble or setting the stage for future work. And by that, I mean exactly what I'm talking about that are the key things you're going to run into. It's communication, it's labeling, it's the process. So in your first few retrospectives, expect that one of the things you're going to hear about is process related stuff. If any items or data or whatever wasn't communicated either properly or in a timely manner, if you've got some sort of a workflow for tasks, there's going to be people that don't do that correctly. They may be missing some information, maybe they put too much information, maybe there's steps are skipped if that's possible. And so it's really, although it can be, I don't know, demoralizing to get into your first couple of retrospectives and have a large number of, almost like, it may feel like nitpicking. It may feel like very minor issues. And honestly, they are. And as far as addressing them and fixing them, but they are important to address and to fix. So we need to treat those seriously. And we need to understand that there's going to be, we'll call minor adjustments we can make and a lot of minor adjustments we can make early on that will help us quite a bit moving forward. Now, a good example in early sprints of something that we're just not going to have would be velocity. We have to have enough sprints to build up data to define, to have an idea of what our actual velocity is. The first couple of sprints, we're going to make estimates and the velocity is going to be all over the place. There's not going to be any kind of consistency because of how we're getting used to or working on estimating and making sure even if the individuals within a team are good at estimating, translating those estimates into point values and things like that. And so we're going to have, I say struggles, but they're probably not struggles. We're just going to have a lot of things. We're going to have a target rich environment early on as far as improvements. And so that's where I want to go with this episode is I want to get a little deeper into How do we, we have this list and how do we address it? And this is definitely like everything within Agile, this is a suggestion. This comes from experience with various teams and software and otherwise and trying to get them to work better. And a lot of these are going to be themes that you've, we've covered several times when we've talked about becoming better developers and better team members and driving ourselves and our teams to do better. And this, these ideas work, these recommendations work even if it's essentially almost if it's a, if you're an individual and you've got your own, they will call it a personal sprint or something. I mean, it's not a true sprint because you don't have the resources and things like that. Maybe you look for, you know, once a week, once every two weeks, once a month, look back at what you do and you do a little bit of a retrospective to see how you can do things. And this also impacts personally how you do stuff within a team as well as how the team improves and the adjustments that they make. Now, first and foremost, and you may find this very obvious once I say it, because you're going to say, oh, of course, this is where he's going to go. And that is communication. You've got to be able to get on the same page as a team, which needs means the things that you really are going to get the most bang for your buck early on adjusting are the process to make sure that it's defined. And I guess it's processes because there's several processes that are involved in a sprint and making sure that those are solid, that they're agreed upon, that they're well defined and that the team is comfortable following those processes and walking through the steps they need to walk through along with this as a language. Just making sure that when whatever labels you use within the sprint, within the team, they are understood by everybody. So there's not, in some cases, maybe very different understandings. It could just be nuances of how people understand or experienced certain words or processes tackling those things. And then along with that is probably the most important and the one that you're going to always have starting out is the communication of how are we doing, where are we at? Because that data, that communication is what's eventually going to turn into our metrics. That's how we're going to score ourselves, grade ourselves. Are we doing better? If we don't know, if we don't have a way to measure what we're doing, there's going to be no way that we're going to be able to actually improve upon it or make adjustments or, and we can, but then we're just shooting at the dark because we won't have anything to say, yes, we did this and we got better or no, we did this and it actually hurt us. So we need those things. We need the ability to communicate within a sprint. And then we need the ability to essentially communicate from sprint to sprint, which is tracking those metrics. And most of this is very easy for people to do. It's about building habits as opposed to something that somehow challenges their skills or knowledge or anything like that. It may be as simple as documenting hours that you've worked on a task or adding requirements to a ticket or adding more information to bug reports or, you know, or QA feedback. There's all, and there's a lot of that kind of stuff, particularly that communication around a ticket or a task. I see very often that you'll see you run into developers will do, I don't want to say limit it, but sort of a minimalist description sometimes of a ticket and just say, well, here's what, you know, here's the task I'm working on. Because it's mostly for themselves in that case, just thinking, okay, well, this is roughly what this is. Now, depending on how you, your team works, it may be that the team has already as part of their grooming, and this is probably where it should live, part of their grooming is that it's discussed what that ticket means, what that task is. And by what it is, I mean, what are the requirements? What are the things that we're going to be able to use to validate that it was done? You know, what is the, what's the end result? What are the inputs or the constraints? And then what comes out of having this complete? And that may be use cases, it may be related to a story, it can be other deliverables that may be a document or maybe a certain section of the application is now visible, things like that. The outcomes can be all over the place. But at the end of the day, what you want to be able to do is know going into it, what needs to be done. And then coming on completion, how do we validate and verify that this is complete? How do we go through and say, yes, this is done. And we can move on to whatever the next task is. That communication, and then I guess following that up is when you get to the QA side, testers will, they're varied and actually rather broadly varied as far as what you'll get back. Sometimes you'll get back like a screen capture. Sometimes it's a screen capture and you get a couple of things that are circled or highlighted or something that says, this is wrong. That may be very useful, it may be very vague. Sometimes you'll get recordings of here's what I did, and here's what the, which is awesome. Then you can see exactly what they did. Sometimes you'll get something like, this feature doesn't work, which is totally useless as a bug report. So you got to work on that. You want to work on it from really all of the members of the team. This goes back all the way back to the product owner. There may be tickets or requests or tasks that they are involved in creating. To say, hey, we need these features and we need these built into the application. Or the product owner probably is going to have some level of learning or adjustment in working with the team to figure out what kind of information needs to be, I guess, initially stored into that task or that item so that the team can work on it. So they can estimate, so they can ask the right questions. There's always going to be questions, I think, but as we get further into the process, we get more used to what the other members of the team are going to be looking for. Instead of us having to put something out there and they ask for it, we start answering those and we assume the questions are going to come and then we can answer those beforehand and cut down on the back and forth and the discussion. All of this is communication. All of this is going to hit every team as they start out, as they're getting used to each other. It even will, if you sometimes have a team member leave or a new one come in or things like that, then you'll sort of a little bit restart those kinds of struggles as well. That's okay. Those are easy to fix, like I said. I think the key really here is with most of these items, these process and communication things is to early on address them as much as possible because then they basically become habits for the members of the team and they become a non-issue. That's how people work. Although those will be easy to pick out and easy to list as part of your retrospective early on, they're also things that I think it's highly worth it to tackle those. You may want to tackle things like maybe estimation, being out of control, or maybe how the demo, the review or demo went. All your daily standups, you're going to run into stuff like that that are going to be early on, that are going to be most likely listed as things we can do better. Before I get into those, I do want to step back one step about the retrospective itself. With the things we can do better, remember the retrospective, we as a team, the sprint team gets together and talks about what did we do in this previous sprint that we just finished? Where do we need improvement? And then how do we approach that next sprint? How do we make improvements in the next sprint? When you talk about what we do well, sometimes it seems, I think people get the idea that it's not valuable to list what we did well because if you did it well, then okay, we did it well. We don't have to talk about it anymore. We don't want to make adjustments. If we didn't do it well, if it needs improvement, well then it needs improvement. It needs some action to get better. But the key here is that the things that we did well, one, it's a marker to say, okay, we did this well, but let's make sure we continue to do those well. So maybe five or six sprints in, maybe you did your daily standups really well. You can suddenly have a sprint where nobody really lists that or people say, well, it wasn't as good as the last one. You're then going to have a little bit of a warning sign to say, well, what did we change or what did we do different? So it's important to have what you do well for a historical basis at least, also from a morale just so you can say, hey, we did some things. There's a lot of places where we can improve, but hey, we did some things right. And it also gives you something to measure against a little bit to say, we should be building or getting to a point where there's more and more stuff that we do well. Maybe the first one or two sprints, there may not be much at all. There may be a lot of areas, but it's good to at least get some victory out of it. And then that also early on says, okay, here's maybe an item or an approach or an area that we don't really need to worry about. We seem to have that one under control. And then you just monitor going forward so it doesn't get out of control. Now the things that you can improve, particularly early on, like I said, they can be very, it could be overwhelming. There could be a lot of stuff, but just take bite-sized chunks. What can you do in the next sprint? And then the rest of it, leave in your correction or improvement backlog. What you will find is some things you're not going to be able to, particularly early on, you're not going to be able to address them for a while. Really measuring velocity takes several sprints so you can sort of settle down what your estimation approach is and also get some sort of an average. Because you can get skewed sprints where there's some issue really sucks up a lot of time. It's sort of a surprise issue. Or maybe there's a lot of stuff, everything moves really smoothly for a sprint and you thought it was going to be more challenging than it was. The idea of velocity is an average. And so if you don't have enough data points, then the averaging thing doesn't really work out. It doesn't make any sense. The average of five is five. So that provides you zero information. You've got to have multiple instances to be able to work with it, to do something useful. You can push that off. You can say, well, we didn't really know what our velocity was. Okay, that makes sense. And we'll sort of be working towards that maybe, but we're not going to worry about that for a few more sprints. Things like that. So there's going to be issues that are, I want to say not worth, but maybe either aren't feasible or they just don't. The return on investment for working on them at this point is not worth taking a look at it. And so early on, I want to go back to this. When you're first starting out, work on the things that are habit building. Work on the things that are more about how the individuals within the team do stuff, how they work, what is their day-to-day grind, what are the processes they use. And getting those things in place earlier, sooner rather than later are going to pay off big because they become habits, because they become something that the team just does without thinking and it just, it smooths that area out. Yes, there are going to be bigger things. There may be some major communication issues or for example, the, the review, the sprint that demo, that dog and pony show that you do a lot of times is a struggle early on because of the mix of, of tasks. Some are very visible. Some are very much not particularly early on in a, in a project's life when your early sprints or maybe things like, I don't know, setting up a development environment, getting a test server created, basic, you know, downloading some libraries, installing frameworks, doing basic connections to the framework, creating a database, even though not the tables within it, but just getting a database server stood up. Things like that are not flashy and they make it, it can be very difficult as far as stories are concerned because it's really just, you're getting going. And then even in your first pieces of implementation, it may be things, you know, like a, I don't know, user registration or just creating a customer table or designing the header and the footer to a screen or something like that. But those are still things you can display. But that mix of visual and non-visual can sometimes mess with your review because you'll have the people that are doing the very, the visual stuff that has more of a storytelling facet built into it end up sucking up a lot of the time in the review. And the people that are doing the non-visual stuff really don't, you know, they do very little. They may spend 60 seconds talking about their story. And so getting that storytelling aspect of the review in place a lot of times is going to take work. And those things are more, those are team interactions kinds of things because there's a balance. You want to have the, all the members should present essentially something within that review. And you want to get it, people used to what's the kind of time that I have, what's the amount of content I should put into this. It's like anything. You practice. So what you wanted to do, if you had to do a presentation that's, I don't know, say 10 minutes long, once a week, you had to do a 10 minute presentation on topics. You pick a topic and do a 10 minute presentation. The first couple of times you're probably going to be, you know, maybe it's a little short, maybe it's a little long. Usually it's going to be a little long and you get better because you figure out what my audience is and how they interact and what my cadence and approach is within a presentation. Which may be very different from what you do when you're just doing it by yourself versus doing it in front of others. Things like that, that those adjustments we learn because we do it. We get some experience under our belt and we get better at that kind of timing. We see that with sprint reviews as well. So that's going to be something that we will probably see it crop up early on and we can mention it so people are thinking about it. And maybe throw some hints at team members and sort of work at things. But if it takes a while, then that's okay. We can say, you know what, that's not something we're going to tackle yet. In the next sprint, we're not going to fix it maybe in one sprint anyway. So instead of doing that, let's work on these other things that we can make adjustments to in the next sprint. And maybe just set the wheels in motion to make some improvements down the road. And this is that building better developer type of idea. It's the same thing here is that we just want that forward momentum sometimes from sprint to sprint. Well, there's some things that we can knock out and ideally we want to address in a way that we can say, yes, we made significant improvement in X in any given sprint. There's also some things that we just want to say, you know what, we can't tackle those in a single sprint or even a couple of sprints. It's something that we have to build up to it. And so in those cases, maybe you take a look at some of these bigger, harder challenges to address and say, well, let's just see where we can maybe adjust a few things so that we prepare ourselves to address that further down the road. So that's some ideas on the sprint retrospective and how to take the feedback and do something with it. And like I said, it's very general and it's going to vary from team to team what they do and what they can improve and how fast they can improve. And there's so many things that go into it, which is most of the stuff that we've talked about with Agile is that it's not about hard and fast rules as much as it is being sensitive to the team and how they interact and how they work and what are their goals and how to get better with those. Challenge of the week, put together either, you know, look at your last retrospective or maybe you didn't do one and this would be even at a personal level and it sort of combines in that. Look at how your team did. What did they do and are you doing a good job making a workable list of improvements from sprint to sprint? And then there's sort of a 1A and 1B with that one. Look at how you have done and spend a lot of time. Do you have a couple of things that maybe you can do better to improve in the current sprint or the next sprint? Well, the team benefits from these things. Sometimes it's good to do a little bit of an internal retrospective and see what is it that you can do and get yourself some lists. What do I do good? What do I not do as well? And take a look at some of those things where you can make improvements and try to make a little improvement, personal improvement during the next sprint. It's one of those things that is definitely a path becoming a better developer, but also it's a practice that I think helps us take away the personal tie to the pros and cons of a given sprint because it's not personal. It's about us getting better as a team and maybe some people do things better or not, but that's not the point. The point is just how do we get better as a team? Nobody should feel bad coming out of a retrospective. They should feel like, okay, we have some things we can improve on. We agree on it. They should actually feel good because there should be clear direction, some clear items, workable, measurable items that they're going to work on in the next sprint to get better. That's the goal and that should make everybody happy. But nothing will make me happier than if you 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 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. Just 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.