Scrum and Agile Manifesto

This is building better developers, the developer 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 applying it to modern software development. This episode, we're going to continue and look a little deeper into the three ceremonies of Scrum. Those being the Sprint Review, Sprint Retrospective and the Daily Standup. Now we have mentioned other pieces of Scrum and how sprints are done, but these are the three that are, they need some extra discussion. Sort of where we left off. So that's what we're going to pick up for this episode. Let's start with the Daily Standup. That is very common. I think just about every company I've dealt with, if they are trying to use Scrum in some way, Daily Standup exists. I think, partially, I think there's a problem with that because there's managers that seem to think that that is the way to keep a, you know, to get a status every day. Status meeting every day. What are we doing? Drive people, push them. Get them to spend some time. They don't think about spending time, but get them to keep us as managers, keep us up to date on what's going on. That's not the purpose. It is not a status meeting. A standup should be quick. The whole purpose, the name of it, standup, is that you don't even sit down. You come in, you do a brief, essentially pulse check, and then you get back to work. You don't, you know, this should not take time. This should not, this should not be a working session. This should not be a problem solving session. It's really more about assignments, I guess. And so instead of coming in and saying, here's what I did, here's what I'm going to do, things like that, it may be a quick sort of what am I doing? What am I working on today? And that's really not to get into it other than just to get a pulse from the team to get an idea of what people are working on, where they're at. So, for example, you may have, let's say we're a couple days into Sprint, so everybody's assigned or picked out a, you know, selected a task that they're working on. And the standup at that point will basically be, hey, I'm going to get this task done. I think I'm going to go work on this other one. Or I'm struggling with this. Can I get somebody to help me out to get me over the hump? And with that, you should be able to really get the status from your, your, your Sprint board, your Kanban board or whatever it happens to be. You should be able to look at that and see where things are at and how you're progressing towards being successful, completing items on your Sprint. Daily standup is just as a team. So the team doesn't have to look at the board for what's going on today to help them understand what's being worked on and maybe raise a flag if there's something that is a concern. So, for example, maybe somebody's working on a ticket and they say, well, I want to move to this ticket next. However, is somebody going to be able to get this other prerequisite done first? You know, something like that. And you don't have to, it doesn't have to be more than 15, 20 seconds to just say yes or no. And if it's a concern, then the, really it's the scrum master at that point would say, you can say, hey, all right, I'm going to take a look at that, see if I can get somebody to take a look at that, to put that on there. I'm going to do next list or maybe pause something and they may say, hey, you're working on X. Can you pause that and go switch gears and go work on Y because that's a that's going to become a blocking issue. And if there are any blocking issues, then the scrum master can note that and go address those. That should be it. Standup should be very quick. It should be very straightforward and something that everybody can basically, there shouldn't be shouldn't be any thought really that goes into it. They should be able to walk into the standup, talk about what they're going to do, do it. And that's what they're doing that day. And then everybody gets back to work. If it starts becoming very time consuming, then that's that should be a red flag in itself. For example, think of a normal team of dev team, three to nine people. This is another reason why a very large team can become a negative is that you should be able to with a team of even of nine people of nine dev members. And even if you've got the product owner in there and you've got and pushing your numbers up to double digits, you should still be able to get through a standup in 15 minutes or less. It really should be really, I would say, less than a minute per person. And ideally, you should be able to crank through those things on a normal team should be able to get through standups in five to 10 minutes. And a lot of times we'll talk about this a bit more as we improve our our scrum, our sprints, each sprint getting better. I think early on in particular, that seems to always be a challenge is, hey, let's get our standups shortened up, tightened up and move forward from there. Now, as a help, if you have if you want to use it, essentially some sort of a working session, which is possible, you may have a situation where there's a. There's a bug or some obstacle or something like that that really needs the they can benefit from the whole dev team or the majority of the dev team and sit down and talking through it. Situations like that get through the standup. And essentially noted say, OK, we need to do a working session that maybe at that point you say, hey, is everybody available that we will when we're done with the standup, we'll go right into that working session. And that's a great way to approach it is you get everything through sort of as a scrum master, take notes. Is there are there some things that may require additional conversation? Get through the standup and you can say, OK, this is the we're going to count this as we've completed the standup so everybody can get to work, except these people. We're going to stick behind and we're going to turn around and go right into a working session. Do that and that allows you to free up even if it's just one or two of those resources, it frees them up to go back to work as opposed to sit around and listen to other people and to be unproductive essentially. And that's what remember that's our goal is we wanted free up, get obstacles out of the way, free up the dev team to be as productive as possible. Spending times and meetings, talking through planning and stuff like that is not going to be your that's not a good approach. That's not a good use of your time, particularly when you do it every day. If you're spending every day having to talk through planning, then you you aren't doing it right. You're way behind. You need to do a better job of spending less time, set up the plans and let it go as opposed to set up a plan. And then essentially if you're going to do 30 minutes of planning every day, then you're micromanaging too much or you're you're having to make way too many adjustments to the plan. So those are some red flags. If you have to do a stand up that's longer than 15 minutes every day, you're not doing it right. And it may point to some other areas that you are you're not doing things right. You're maybe not giving them the the attention or getting the level of detail that you need from some of these other activities that you should be doing as a team. I say you and this would be the team should be doing. And this also just I say you not saying that I never do this. A lot of this comes from things that we've learned over the years and those have all included mistakes that I've either witnessed or made and how we came together and found a good solution for. So this is a daily stand up. Like I said, it is I think that it it's daily. It's daily. So it's something that shows up a lot in a sprint, but it's also something that needs some it always needs a little. Massaging or review in itself to figure out the best way to get it done for the situation you're in the team you have and the kind of information and I guess the pulse check that you need for your specific team. Everybody's little different. Now we do our daily stand ups and we get to the end of a sprint and we do a sprint review. This is it can sometimes a lot of times it's referred to as maybe a demo or a maybe a customer meeting or customer review. Sometimes it's referred to as user acceptance testing you AT but it's not really that this is more the presentation side of you AT and it's not really. Intended it's not intended not really it's not at all intended to be user acceptance. This is more handing it over to the user user acceptance would be a different process. The review should be also much like we talked about the stand up. It should have some sort of a time boxing some sort of limit to what it's going to how much time you're going to spend on it. If it's a if it's a two to three week sprint cycle you probably should be looking about one sixty to ninety minutes. I think unless it's you may adjust occasionally but I think sixty to ninety minutes should typically with what you would cover in a two to three week period should be enough. Should that that should be able to allow you to get the things done and we'll talk a little bit more about what those things are here in a minute. If you're in a four or five you know or longer sprint then you're probably going to be looking at roughly I don't know typically it seems like this is not a hard metric but it seems like for every two or so weeks of a sprint about an hour would equate to about an hour of review. So if it's a six week sprint you're probably going to do a three hour review that may be top in sort of the high end of it. But again six weeks is a long time to do a sprint. Normally you're going to be in that three to four week period which is typically one to two hours for your sprint review. And what the sprint review is is it really is a demo it is sort of the deliverable part of the sprint is delivering working software. The idea here being that each essentially each dev should dev team member should be able to do some sort of presentation on the things that they completed in a sprint. It's it's sort of showing it off saying OK these three tasks were completed and here's what this looks like or here's how this integrates in the system something like that. Now I know some of these things that we do are not they're not visually useful. You're not going to see that probably that you created a bunch of functions and validations on this import process but you can at least talk through them you can at least say hey this is what I did. We worked on validation so now as this script is being run as this data is being imported here are the things that we are checking for. And if you want to show something off I guess you could always show like unit tests or something like that. But that should be part of what is presented is to say this was done these unit tests were run on it this these tests this past QA or it didn't you know basically to give sort of a now it is sort of a status of the things that you worked on. And in most cases actually really in almost all cases vast majority should be that you're showing that it was completed because if it's not then you would just basically just mention it say well you know started work on this thing but it didn't complete. Cover the next sprint. Everything she did get done then you talk through that just say hey here's what we got here's what we did here's what it looks like and it's not. It does allow for feedback but it's not as it's really driven more to present than it is for the feedback side of it. Ideally you should have all the team members involved product shown owner should be in their scrum master all the dev team. This is where we as a team come together and look at what we've done. And we should be able to we're part of this so it's going to be very helpful to listen in to questions and reviews and or feedback and things like that that come from the review because it is mostly a presentation style meeting then you definitely want to front load that you may want to even time box each of the the devs to make sure that they did. That often is a problem as you get maybe some more user interface heavy kinds of thing you know more visual kinds of results that end up chewing up a lot of time and some of the other stuff isn't just you run out of time and so those things don't really get presented so there should be some. Maybe the scrum master is sort of sitting there maybe that maybe is as much as running a stopwatch or something to say okay you know time let's you know let's move on. And then if you've got time and hopefully you schedule such you had a little bit of time at the end to get some feedback and brief feedback you don't need to go into deep discussions those should be tabled and addressed in another time. So we get to walk through every day we do our daily stand up and then we get to and we do a review we say okay this which like I said is really the. The deliverable part this is the should be working software and we should show that it works and maybe do a quick walk through of it things like that. Now once we've gotten through the review really the final nail in the coffin of a sprint is a retrospective and when we look at the principles of the Agile Manifesto this is the idea of regularly reviewing how we do and look for ways to improve that is the retrospective. Much like a review it should involve everybody and it should be time boxed and it usually I think probably about the same amount of time you spend on the demo is a reasonable amount of time to do for the retrospective. Maybe even a little less on the retrospective because those meetings can there tends to be a lot of discussion there tends to be a little bit of a working session mentality that comes into it because of how it's laid out and you know spoiler alert that's what we're going to do next is it when you come into the retrospective there's really two things that are that well I guess there's three key things. What do we do right what do we do that needs improvement and how do we improve. Now the what do we do right and what needs improvement you can approach that however you you want to to and that should go out to the team you know it's it's open for discussion and it's not even a discussion as much as it should be really just building a list. They make sure as much as possible you want to drive so that everybody has at least. It has some input say hey here's what I ran into that was good here's what wasn't even if it does end up being a lot of. The the later people that speak up say well you know I agree we did these things well and I agree here's some things that we need to adjust at least they're getting that feedback. They're getting that feedback because it does allow us to say okay this is an issue that everybody ran into or. This is an issue that really just one person ran into so that that will adjust that informs how we want to approach it because it may be something about how the team works and maybe something about the environment it may be something about that person's understanding of. Of the tools a project or whatever it is so that's a scope of the issue or even frequency of the issue can help us prioritize how we want to address them. So the time about really building that list should be. I say it's normally going to take probably half your time if you take an hour easily especially early on in the early sprints. Because you're you're gonna have more. Things that this is sort of new that we've run into that were that were working with this you're going to have more feedback ideally earlier on in the earlier few sprints. Is you get more mature is your team matures and their ability to do this there should be more things that are basically are chugging along well. Which they can easily say yeah we you know we're doing most of these things right however here's a couple things we want to improve on so it should be less time building that list out. But I would say. I guess you can adjust as you go but you want to leave at least. I'd say at least 20 to 30% of the time for improvements discussing how we're going to improve in the next sprint. And it's not necessarily entirely a working session but it should be enough that even by the time you're done with the retrospective. You the team has come to. The agreement essentially here's some things we're going to work on ideally with some some action items as far as how we're going to make those improvements. But at very least so that everybody's had their input and you know have basically come to that decision as a team this is what we're going to work on in the next sprint. And it can be. It can be a wide variety of stuff. But the scope of those improvements should be one sprint and ideally you get the retrospective and you may have a whole lot of stuff to work on and you're going to want to keep that list but. It's only so much you can do so it may be that you say well we've got this list of 50 items that we want that we need to address to improve well we just don't have the you know that's just too much so let's take the two or three items that we're going to work on. And i think this is like a lot of the goal setting things that we do we want to keep it small enough that it's it's not overwhelming i think really limiting. What's the improvements to make to three or less. In the next sprint i think are that's a that's a good approach because what we're trying to do with sprints and the things that we're doing is build habits. And that means it takes a little bit of time of doing it the same way or correctly or however you want to look at it in order to build that habit to get that momentum. And if you're working on too many things it it's hard to keep track of all those things that you're trying to do a specific way to get that habit built. You think about it if you wanted to do in a sports analogy would be if you wanted to be better at. Whatever your sport is going to be better at running then or let's say you want to be better at running you want better upper arm body strength better core strength you want to be able to throw better you want to be able to catch better you know better I hand coordination. And you want to be able to do long and short distance you know sprints but you also want to be able to do long distance better that's a lot of stuff. So in order to do that you know if you want to improve on that in the next two weeks there's a lot of things that you would need to do and you'd have to remember every day you know or however often it is. Oh yeah I want to do this I want to do that I want to do this I want to do that instead simplify build that habit and then that allows you to sort of forget about a little bit because now it's a habit and you can move on to something else take it and baby steps are fine. So that's the three ceremonies of scrum and hopefully you get a little better idea of how this is done all of these are they're not hard and fast ideas these are all recommendations because every team is a little different they do things a little different. And they will benefit from things in different ways and even the way the scrum master works will and the product owner those things will impact how best to approach these but I highly highly recommend that you do have some manner of the three ceremonies in every sprint. And you know they stand up like I said most people that's even if it's not daily even if every other day there it's accepted it's becoming sort of a common thing sprint review and sprint retrospective I have seen all over the place and so those tend to be the things that it's important to get those things incorporated into your sprints. Get those things incorporated into your sprints challenge the week do you in some way you know take a look at sprints you've done do you incorporate these three ceremonies and as I said before they may be labeled very differently. So you may have to think a little bit about what do we do every sprint and does this thing fit the label that we've just talked about is this. You know for example is this really what would be a sprint review is this really what would be a sprint retrospective. And if not then you know how can you consider how you can maybe find a way to make those things a part of your sprints moving forward. And that being said I'll let you get back to it so go out there and have yourself a great day a great week and we will talk to you next. Thank you for listening to building better developers the developer podcast for more episodes like this one you can find us on apple podcast stitcher Amazon and other podcast venues or visit our site at developer.com just a step forward today 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. One is the book the source code of happiness you can find links to it on our page out on the developer site you can also find it on Amazon search for Rob Rodhead or source code of happiness you can get it on Kindle if you're an Amazon prime member you can read it free. lot of good information there that'll be a lot easier than trying to dig through all of our past blog post 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.