Agile Manifesto, Agile Processes, Scrum, Sprints

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 are continuing our season where we are looking at the agile manifesto, agile processes, trying to get ourselves a little more comfortable with how we can use this very popular, well, manifesto, but theory around software. Take it, make it our own, and become better developers, create better products based on that. Now we have walked through the 12 principles. We've talked, walked through the overarching things that we value, part of the agile manifesto. In the agile manifesto, we have talked about Scrum, and we've sort of touched on several times the idea of sprints and that piece of Scrums, of the Scrum approach. And I want to get a little deeper this episode on some of the things we do within a sprint. Sprints are a short period of time, usually two to, I don't know, five or six weeks, of basically doing many projects. The goal in a sprint is actually, in any given sprint, is to have something you can deploy, which goes back to one of the principles, which was the idea of regularly providing a customer with working software. The sprint is the mechanism to do that, essentially. Now, in doing so, it's not just let's get something produced every X period of time, every three weeks, every four weeks, or something like that. It is to take the entire process, really, and handle it in smaller bites. And that's what I want to focus on in this episode, is what really needs to be a part of a sprint and making it work for you in a way that will help you improve, will help you make improvements to your team in how they approach software and how they build software and communication and delivery and all of the things that are involved in satisfying the customer. Now, first thing within a sprint is to remember or to understand that it intentionally should have all of the steps of the software development lifecycle addressed in some way. So if you can remember back to that, that includes gathering requirements, design, implementation, testing, deployment. And although maintenance is in there, we'll talk about how that sort of gets addressed in a sprint as well. So just because we have this short period of time and we are implementation focused, we'll say, that we value delivering software over some of the other things that we want to do or need to do, our primary goal is going to be still within a sprint, much like it is an overall project, satisfying the customer and we want to deliver software. So that's our why and our what, I guess, for a sprint. But within a sprint, we still need to do all of the important steps. So gather requirements. Now, gathering requirements in a sprint structure is a little different depending on how you set it up, because typically you have a backlog. You have issues that you need to get done. And that means that there's probably some amount of requirements work that's already been done. But if you haven't, if this is your first sprint on a product, it's probably going to be almost entirely requirements gathering. Now, there may be some things that are not part of the requirements that are well, I won't say that they're requirements, but they're they're well known. For example, you may know that your application is going to have users and registration and authentication and security. So some of your tasks in the first sprint may be setting up that framework, installing development environments and getting those configured, scripting deployment, putting together deployment scripts so that you have in place the tools you're going to need to be able to create and deploy that software. So those are really well known things. The requirements are going to be minimal. You can get those done even while more application specific requirements are being addressed in that first sprint or two. So don't think that just because you start with nothing, that you can't have something that you can deliver. Now, working software is going to be maybe a stretch, but in a given sprint, even in a single sprint, you may be able to do something like bring up a home page or have the ability for a user to log in. So it's OK. The strictest description. It's working software. You can log in. You can log out. You can see a home page. That's it. Maybe is all you're going to get in that first sprint. And maybe you get further along. But there's there's still an opportunity to have something that you've delivered. Definitely, you're going to have some almost immediately some some backlog of tasks, which does imply that there has to be something done, some amount of work done outside of a sprint. Because you have like a setup or a pre sprint kind of thing that you need to do. Now, some places will essentially make that the first couple of sprints are not. Not full sprints or I guess not go. They're not aimed at delivering software. They're aimed at getting ourselves like a kickoff, getting ourselves configured and set up so that we can get the work done. And so that's there's nothing wrong with that. I'm just sort of throwing these ideas out of these are if you haven't done this before, these are some of the ways these things are approached. Now, once you've sort of flash forward, because I do want to focus on the sprint itself. Once you've got the backlog, then roughly that is your requirements. And by roughly, I mean, those are the tasks that you're going to that you will pull out of the backlog, put them into the sprint and say that this is what we're going to get done during this sprint. However, one of the first things you do or should do in a sprint is have the dev team take a look at what is it that we're going to do. What is it we're building in this sprint? And essentially, it's essentially gathering the requirements, even though that backlog item should have requirements listed, it should be somewhat planned out. It may not be complete in the requirements side of it. And it becomes this process in sprint really is almost more like a combo design and requirement gathering step. Because what you're doing is putting this in front of the developers. And it's I don't want to apply this necessarily the first time they've seen it, but this is where they're really focusing on, do I have what I need? Do I know enough about this to code this, to implement this in the sprint? Or there's some questions that I need answered or clarifications, things of that nature. So I'm going to look at the backlog item. They're going to assess the essentially assess the requirements that it has, maybe gather additional requirements. And then that sort of flows into design. They're going to, to some extent, put together a design and approach to solving this. And it may be individually, it may be part of the team where they may say, hey, we've got this thing. How does this fit into how do we want this to fit into the big picture? Or maybe this is something new. How do we want to approach it? Is this is this its own maybe framework or library? Is this a standalone piece? Does this need to integrate with others? The design related discussions. And depending on the sprint, this may be something that's done in a few hours as you start the sprint. Typically, it's probably best that it's going to be a day or two because you need to do this communication needs to be done. There's feedback. There's thought time to do the design. So it's going to be the thing you think about if it's going to be 10 or 15 percent of your time, then in a two week sprint, a day makes sense. And a three or four week sprint, then maybe a couple of days. But you still have these steps. You're still taking these steps. Even though you're trying to your goal is delivering software, as I've mentioned several times to this season, you're not throwing out all of these things and these steps that you normally take. You're still gathering requirements. You're still doing design. And you may have a situation where you pull something into a sprint and you realize you have to essentially push it back to the backlog because it needs more work, because it needs more planning, it needs more feedback from somebody else. Or it may be something that was designated to be implemented in this sprint and you end up kicking it back over as a design ticket or something like that. It may be swapped out, for example. Maybe you take a let's say implement a user registration ticket or item that was on the board that you pulled off the backlog and you look at it and you say, oh, wait, we've got to talk more about what's the user. Maybe we in discussing this, we realize that we have a couple different user types and maybe we have different registration approaches. And we haven't really thought that through. So instead, we take the implement, put that back on the backlog and maybe create a couple tickets for design. Let's say the report based user registration, the internal user registration, the external user registration, or whatever those flavors are. And then start working through those. And that's perfectly allowed, I guess, for lack of a better term. That's perfectly fine in the sprint world. If we have something that we look at and we realize we haven't thought it out enough, we don't have enough requirements, we don't have enough design, let me say, okay, we're going to go back to the drawing board in a sense. We're going to push this back to the backlog. We're going to make sure that we have the tasks that need to be done basically turned into their own tickets, their own tasks. And then we start knocking those things out. And you can have prerequisites and things like that as well to say, hey, this item, this task is blocked by these other things that have to be done first. But we still have, so we've got that design and requirements gathering. We've got those two steps still that are going to be as they would be in just about any other process. They're going to be pushed towards the, they're going to be the front end things that we do in a sprint. And there are different ways to approach this that I'm not going to go into because there's a lot of different ways to make these things happen within a sprint or a series of sprints. And since it's almost an infinite number of combinations and approaches, I'm not going to go into those in depth. But I just want to state that this is, remember this is not, this is not hard and fast rules that you have to follow. This is not some really strict framework or anything like that. It is something that is loosely defined to help you as a team, your team get better. And so you may even adjust as a team, you may adjust how you do sprints as you go from sprint to sprint to sprint. And we'll talk about that a little bit later as well. So you get your requirements, you get your design, and then you get into the implementation, which is for the most part, it's the bulk of what you're doing in a given sprint. You're implementing things, you're getting things done. Now, typically you implement and then you test. Now, depending on how you set up your sprints, ideally you want testing to be able to start as early into a sprint as possible so that you can get, you have the time, the availability to get testing done on those things that you're building. So that by the time you get to the deployment at the end of a sprint, that software you're delivering, that you've tested it as well, which can be a little bit of a chicken and egg problem because you're testing things that you're coding, that you're implementing. But if you haven't implemented it fully, you can't test it fully. So you do have some race conditions or prerequisites there. Now you can do things like offset so that your implementation is done in one sprint and you test it heavily in the next sprint and then deploy it as part of completing that testing side of the sprint. But again, there's different ways you can approach it. Generally speaking, if you do the testing on the things that are being completed, this is where as a dev team you need to be focused on completing tasks. Right away, if you've got a four week week sprint, you shouldn't have everything complete in the fourth week. You should be completing things that by completing, I mean, implement them to a point where they can be tested in the first week so that the testing group has the time to be able to actually test. Now with sprints, you've got these key steps that we've talked through. And then just sort of, I'm going to gloss over it, I know, but then there's a deployment at the end of a sprint. So you've walked through the typical software development lifecycle steps. You've built something and you've delivered software at the end of it. Now within a sprint, there's some rituals basically as we call it or ceremonies that are activities that are done within sprints that help us get these things done, that help us with these software development life cycles. Plus embrace the agile side of a sprint. Things like reviews and regular check-ins, communication and making adjustments and getting better. Now we're going to end up because of the way these things are done, we're going to end up, this is going to be a multi-parter type of episode. So I guess I want to give you a little heads up on that. But I do want to talk about these ceremonies. The first one I want to mention is sprint planning. This is what's done either right away or even maybe pre-sprint. And by pre-sprint, a lot of places I've been, you actually do the sprint planning at the end part of the prior sprint. So in sprint one, and we'll assume things sort of fall into place, but in sprint one, you get to that last piece of the sprint where you're doing the deployment, where you're delivering software. Well, there's usually time involved to do that deployment and some of the other ceremonies around that that we're going to talk about, which allow us time to take some resources that can be assigned to planning for the next sprint. Or maybe two or three sprints ahead. There's different ways you can do this, but essentially there, and this is that step where you pull stuff off of the backlog. You set some goals for the sprint as part of, and sort of those go hand in hand. So you're pulling items off of the backlog. You're looking at what you're targeting to get done. What is our goal for the sprint, which is basically what is it we're delivering in this sprint? This is where you do some prioritization. Maybe there's some give and take or trade-offs as far as what gets done and what your goals are. And then you basically fill up the backlog for the sprint, which is here are the tasks, the things that we want to get done in this given sprint. That's the planning side of it, and we will go a little deeper into those steps. So, you know, sorry if you still have some questions, that's okay. We may get back around to that, or probably we'll get back around to that. I'll be positive. Once you do the planning, then you go into daily, essentially each day of the scrum. And with that, with each day typically, it's rare that it's more often or it's less frequent than a day, you have a daily stand-up. Stand-up is a, the whole idea of a stand-up is that it's a meeting that you stand the whole time. Now in the world of remote workers and stuff like that, that doesn't have the same meaning. But if you're in a room and you come to a meeting and you don't even sit down, that implies that it's going to be a quick meeting. It's basically we're just going to go, we're going to gather in here. We're not going to actually meet or it's not actually a meeting. We're not going to sit down and walk through stuff. We're just going to have a quick discussion, somewhat like passing somebody in a hall and you have a hallway discussion. Well, daily stand-up, that's essentially the goal of it. It's not to have some formal status or anything like that. It's really more of a forum for the team members to say, you know, roughly, here's what I'm working on. Here's some potential issues or blockers. Here's some obstacles that we've run into. Or, hey, I'm struggling with this task. Can I get some help on it? You know, things like that. And then sort of checking the pulse of the project, of the sprint, are we on track or are we not on track? And that can all be done very quick. It's not, although you will, it can feel like a status because you may go to every member of the team. And just, you know, give them a quick, what's up? What are you working on? But it's not, it doesn't need to be much more than I'm working on, you know, ticket five. I'm going to work on ticket five today and I'm going to get to six if I can. Or I've been working on ticket eight for a couple of days. I'm really, I need some help. I want to try to get some time with somebody to help me through it. You know, things like that. So very informal status if it's status at all. So it's just basically, hey, I've got, and it may be things like, hey, I got this done. It's ready for testing. But even that probably should be obvious. If you're doing it right, you should have some mechanism that's essentially like a status board, combine board or something like that, where as you get it done, you flip the ticket over to the testing column. And so we've got testers working on it. And that means that your daily standup is more, you know, maybe a quick look at that board. And there may be something like, hey, we've got a lot of stuff piled up in testing. Do we need more testing resources? Or, hey, we don't have anything in testing. We need to get some stuff pushed over so we can get our testers working. Or, hey, we've got a lot of stuff that we need to get done. So we're not in flight, not complete, and we don't have much time left to complete this sprint. So what do we need to do? And things like that. That is your daily standup. So you go through your daily standups, you get through your sprint, and then you get to the end. And there's, there's really two, two main things, like meetings, essentially, that you have at the end of a sprint. If you're, we'll say doing it right. You have a sprint review and you have a sprint retrospective. The sprint review is essentially the deliverable part of the sprint. This is where you say, here's the software that we're delivering, the working software we're delivering. Typically, it includes some sort of a demo or a walkthrough, something like that. That's, you know, we spend some time, we've got the customers, we've got the team, and we're doing, we're walking through what we deliver. Here is the quote, we'll say working software that we built. Everybody's involved and it's really about showing off may sound a little bit, but it's essentially showing the features that were created. And they may not be terribly impressive, but at least it's, here's the working software and here's how it's used essentially. And it is a, it is a mechanism to provide information to the customer, but also an opportunity for the customer to get some feedback. So you can get some, you know, it's your first time showing this feature, this working software to a customer. So hopefully you're going to get some feedback of about maybe the user experience or some of the features, things like that to help you understand how, I guess, good or how beneficial or how useful that working software is. Because that's, this is a good communication point for the development team and the customer. To help the customer maybe understand a little better what the expectations can be for them moving forward, you know, how fast are we going to get some of these features delivered and how are they going to be delivered? But then also the dev team to understand what the customer, how they're receiving what's being built so they can make adjustments as needed for features, for user experience and all those other pieces of it. So Sprint Review is the development team and the customer getting together. There's also the Sprint Retrospective, which is more of a, it's really more of an internal focused. The Sprint Review is about the software that you delivered, that working software you delivered. The Retrospective is that covering the idea of let's take a look at how we did, assess it and figure out ways to get better. So the Retrospective also held at the end of a Sprint is looking at what we did. How did we do? What went well? What did not go so well? Where do we need improvement? And early on, the first couple of sprints, this is probably going to be a lot of, you know, we did this okay, but we need to improve here. We need to improve there. So it's going to be somewhat overwhelming. But you're going to want to essentially chip away at that list. So you're going to get through a Retrospective. You're going to basically build a list of what do we need to improve, discuss how you can take some steps in the next, as early as the next sprint within the next sprint. I want to, as a team, let's, I want us to get through this. I want to make these adjustments. We want to do this differently or why don't we try this? And you have these meetings, the Sprint Review and the Retrospective are your wrap up to a Sprint that allows you to share with a customer and cover that idea of regularly delivering software. And then also do the Internal Review that allows you, that covers that goal of regular assessments review and improvement. And then you basically rinse and repeat. Now these are deeper topics and things like that. So rather than have a marathon episode, I think that sort of seems like a good stopping point. We've gone through the key items of planning, daily standups, Sprint Reviews and Sprint Retrospectives. And touched on how some of those things go, but I want to spend the next episode, we're going to go a little deeper into those and some good and bad habits, I guess. And then I just hesitate to say best practices and things like that, but some ways that we can approach these various ceremonies that will help us. And in particular in a way that we can do them so that we get better at them as we go on, as we go from sprint to sprint to sprint. Challenge of the week is how do you, are these new to you? If you, particularly if you've been doing sprints, does your current sprint process include a daily standup? I bet you do. That seems to be like everybody does that at least. Sprint planning. And then think about how that's done because that actually varies a lot. Is it just the, maybe the product owner and the scrum master, is the whole dev team involved, things like that. And then do you have a review and do you have a retrospective? And sometimes those aren't reviews are not always included retrospectives. I've been several places that I've experienced that don't do retrospectives at all, or they do them every once a quarter or once every six months or something like that. And depending on your answer to that is, you know, what can you do maybe to suggest to make some improvements? And that being said, I hope there are zero improvements as you move forward and you have a great day and a great week. And of course we will talk to you next time. Thank you for listening to Building Better Developers, the Developer Nord podcast. For more episodes like this one, you can find us on Apple Podcasts, Stitcher, Amazon and other podcast venues, and we'll see you next time. Or visit our site at developer.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 Nord. One is the book, The Source Code of Happiness. You can find links to it on our page out on the Developer Nord site. You can also find it on Amazon, search for Rob Broadhead 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 developer.com if you would like more information. Now go out there and have yourself a great one.