8.4 Follow guidelines for the use of Agile - Video Tutorials & Practice Problems

<v ->Some guidelines to consider during the sprints themselves.</v> We talked about the duration of them. We talked a little bit about what is involved in a sprint. Some things to think about is that when we're in the middle of a sprint, we don't change the goals, because sometimes people ask the question, well, what happens if changes occur? We're in the middle of our sprint and now we get a call from the customer saying, we need this, not this, or something's happened in our marketplace, and so we need this. The first point is we don't make changes in the middle of a sprint. That's why the sprints are necessarily of relatively short duration. So we finish the activities necessary in that sprint and we save those kinds of issues for our next scrum meeting when we're trying now to talk to the product owner, talk to the people involved, and see what needs to be done at this point in time. But we don't, as we can see, we don't change horses in midstream. We don't suddenly stop and fix or move in another direction in the middle of a sprint. The sprint continues to the fixed point where the time box ends. We also don't make goals that decrease quality. So at some point, in other words, with a sprint, we don't suddenly say, well, you know what? We thought we were gonna do this but let's just kind of, instead let's do this. Let's change it. Let's get a little bit, ease up on that, because you know, it's kind of tough to do the quality the right way they want it, so we're gonna make it. Don't do that either in the middle of a sprint. We don't make changes to the goals. We don't make changes to the quality issues. And as we learn more, even during the sprint, the product owner can start renegotiating or clarifying what should the scope be. But we do that during the process we learn from the user what their concerns are and then we make those necessary changes at the end of the pipeline, or at the end of the specific sprint. What does the sprint then look like? You can see here, I should just show a simple time box. What I've done is I pulled out that example and I've I've popped it in here into a simple thing that shows five basic steps involved inside of each sprint time box. So there's five things you're gonna do on a multiple reoccurring basis when we employ agile in projects. Sprint planning, daily scrums, development work, the sprint review, and then what is called the sprint retrospective. And this is all occurring within that time box. And so let's talk about these. Sprint planning, at the beginning of the process, so now we've started a new time box, so we're getting ready to go off on our next set of activities. So the first thing we do is we hold a planning meeting. We identify the work to be done, jointly not just the the scrum master, not just the project manager, but the team jointly. We identify the work that has to be done in this next sprint. We don't spend a lot of time here. Okay, you notice the one thing we want to get away from is long planning cycles. We want to keep the planning cycles focused, targeted, and of a reasonable duration. So keep the planning the way we want it, which is in a finite basis. No more than one day should be spent for a one month sprint when it comes to planning. The scrum master runs this meeting and he gets the team buy-in. This is why it's a collaborative effort. Make sure that we're all on the same page. This is what we're doing in this sprint. And as part of that, there's two key questions that we have to address in this process. Number one, what can be delivered during this next sprint? What is the expectation? What's our product backlog gonna look like? Because what can be delivered in this sprint? And how will we do the work? How will it be achieved to get that increment done? What is to be done? How is it gonna be it done? Okay, that's a sprint planning meeting. It should be relatively short, it should be focused. The scrum master is essentially laying out the work plan for other members of the team also getting their buy in. Remember it's collaborative. Having done that, we then move into those daily scrums. Daily scrums are morning meetings and that's all they are. We come in in the morning, we have a short 15 minute meeting to allow everybody to sync up their activities. Remember I said before the product backlog, maybe this is the list of activities, the to-do list for the day. You're gonna take this, you're gonna take this, you three are gonna take this one, et cetera. We're gonna develop a plan for how we're gonna sync our activities on a daily basis. We do this so that we don't have any excuses or any surprises at some point saying, "Oh, I thought I was working on this". No, this is all laid out. The development team, we explained what was the output of the last 24 hours? What happened? What is the current intended work to be done? Are there any problems? Has anything happened? Okay, this is just a way for us to coordinate each other. We don't wanna spend a lot of time here. You notice it's 15 minutes short meeting once happens in the morning, where we kind of all get our marching orders for what the expectations are. And as you can see here, finally, the daily scrums are just for communication. It's just to keep the lines of communication open. That's what the goal is. Then having done that, we move into the work itself. The development work is when we actually are working on the activities during the sprint. So these are the things that have to be done during this period of time. And the key is to coordinate this effort. We don't want people sitting around with nothing to do, while other people are buried. We wanna make sure that the level of effort, the way that we've designed the sprints, keeps everybody busy. Everybody's got activities that are involved in. Make sure that we don't get sidetracked by things that aren't part of the sprint. It's easy to suddenly someone comes in and says, "Oh by the way, did everybody develop blah, blah, blah"? When the reality is we don't really want them worrying about that. It's not an issue related to this sprint. So the development work is the actual work being done during this period of time, and everybody's connected, everybody's involved. There's no wasted time. You remember I talked a minute ago, I said that the nice thing about a burndown chart is it allows us to chart to determine how the development work is processing. And so just to give you an idea of one, I created a sample burndown chart, and you can see this is for a 15 day, say three week sprint. And so over three weeks, you'll notice in the top left, we had identified the total hours of work to be done in this sprint. So there was a total of 600 hours that had to be done during this 15 day, three week period of a sprint. And then you can see that just for simplicity's sake every three days I marked, how are we doing? Are we ahead of schedule? Are we behind schedule? Have we hit the numbers we're looking at? And you can see in some cases we may actually have been behind schedule and now we're getting up ahead of schedule a little bit, which is great, because the total number of hours still to be done. We're getting below the ideal curve, which is a good or ideal progress line, which is good. So we're moving along at a rapid pace. But burndown charts, as I said, are a nice visual way to show the team and top management, anyone else who wants to know how we're doing on a sprint by sprint basis. So it's a nice tool that adds a little bit of a graphic clarity to what we're attempting to accomplish. The sprint reviews that take place during each sprint. Now notice I'm not gonna go through this in a lot of detail, 'cause there's several issues. I just wanna make some general mention of some of the key points here is at the end of the latest sprint, we inspect the completed increment. How did it go? Have we completed all the assignments necessary? First question, 'cause remember a sprint has a defined time box. And so if in three weeks time we get there to the review and three or four items haven't been completed, that's a serious concern, because we deliberately set up the items to be done within that increment of time. So that begs the question, why is so much still hanging out on the back end? Because depending on the answer to that, we have to reconfigure future sprints to take care of these problems that didn't get resolved. During the review, the product owner, that's the person who's explaining what items have been completed and what haven't been completed, what worked, what didn't work, where are the problems popping up? Somebody may speak up and say, "You know what, I'm using a computer system with old software. And as a result, every time I try and send my latest updates over to so and so, they're getting corrupted in the process and I have to go back and redo them. I need a updated software in order to make this process flow". It's just one example. Demonstrate the work completed. This is what we've completed, this is what we've gotten done. Let's show it potentially to a user. How is is this in line with what you guys are looking for? Remember the idea is to keep them close to the project not to keep them pushed out over here at arms length the whole way. We wanna make sure that they're engaged and involved. The product owner discusses the backlog and the project completion dates. The team reviews how the marketplace has changed. Has anything changed here? I mean, we're about to move on to the next sprint. That's gonna be another three weeks. Are we good? Is everything we've done still relevant and current to what's out there and what we're aiming toward? The team is performing a reality check, folks. That's the goal here is to make sure that we're still on target. Our timeline still works. We're still dealing with user needs. Those user stories are still ringing in our ears. And we haven't had any sort of major technology shifts that could put us off. So that's a sprint review. And finally, we don't spend a lot of time with the sprint retrospective, but the sprint retrospective is the last thing we do at the end of the process before we complete the sprint. All we're doing here is just having a little sit down. And it can be a very informal one, but it's what's working, and what's not working. How is the process working? You may have somebody raise their hand and say, "I've called the user four times this past week to get them to come in and talk to me, because I think I wanna understand what they're looking for and they keep avoiding my phone calls, or they keep putting me off, or they're they're not engaged right now and I need their help". Okay, this would be a good time to say here's a problem that's emerging. We need to correct it. What's the action plan? The action plan with the sprint retrospective may be go and talk to the users or their manager and say, "Look, we need George to start showing up or to be engaged because right now we don't feel like we're getting enough input from the user's side". Okay, the scrum master is working with the team to improve communications, figure out what's going on, what's not working. You notice I call this retrospectives are a shortish movie shortish meeting. We want to do two things here. How's it going? And notice the second one, keep the enthusiasm level up. So the scrum master is looking at how we've done, but also okay guys, we're about to get to the next sprint. We're gonna be doing blah, blah, blah, blah. We've got the product backlog items are set up for starting that sprint. We're gonna hit that one on Monday. Make sure you get the idea. The point is that we want to generate enthusiasm. We wanna make sure everyone is on the same page.