Agile Manifesto, Agile Processes, and Agile Patterns

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 are here again talking about the Agile Manifesto, Agile Processes, and we have cruised all the way through to patterns. Last episode, we started our discussion of these agile patterns, which are somewhat like software patterns, somewhat things that we need to do, things that we should do, that we should include, making them a little different from normal patterns. The software patterns normally are going to be problem specific, and while these are similar in that, these are also problems that we're going to find in just about every sprint, every team. These are things that we need to deal with. I'm going to dive right in. This first pattern we want to talk about is the increment. This is very important. We've touched on it several times as we've talked about agile and sprint in particular. The biggest, or I guess the most obvious of the increments would be the sprint. What's the duration of a sprint? What is the increment that we're going to define that will be a period of work, and then ideally, release software, have working software? One week is almost always too small. I don't know that very few people do that, and if you do, it's probably not a real sprint. Two weeks, I've seen it often enough, but when you factor in all the things that go on, that's really only, I don't know, maybe five or six days of work. You figure two weeks, that's 10 days, but then you've got a day that's probably taken up with things like overall, things like reviews and retrospectives. You may have a day of testing, and then now you're down to eight days, and maybe just from normal meetings, you suck away another day's worth of work. You're starting to run sort of just short. There's just not enough time to get stuff done. Three is very, you're getting more common, and three and four is definitely the more common timeframes. Some people try to match them by months. I think that's, you can do that because you get a little bit variation in days, two to three days, but it also ends up running into issues when you've got months that have longer typical holiday periods, whether it's maybe in Europe where they've got, you've got sort of like your vacation where you maybe shut down in August. Some companies shut down in July for a week or two or go to a skeleton crew. A lot of places, you're doing sort of your summer holidays and vacations are going on then. You get into November and Thanksgiving and the US and your Christmas holidays in Kwanzaa and everything that goes on in December. You end up having some months that are just very, very light. I think it's better off to just do it by straight weeks. You could do days. You could do 20 days, 30 days, 25 days, something like that, but it's going to end up being close enough to weeks. You might as well make it weeks. It also allows the team to just sort of have a feel that there's going to be certain days, certain times that they're going to be called to do certain types of work. This is really useful in planning out some of their vacations and time off and even things like dental appointments, doctor appointments, things like that. Consistency is very nice. But the increments also, while the sprint is probably the most, is maybe the most obvious of them, there's also, when do you do your daily standup? Since it's called daily standup, most people do it daily. There's some teams that don't. Some will do it every other day, maybe three times, Monday, Wednesday, Friday, maybe Tuesday, Thursday, maybe Monday and Friday or something like that. There are some adjustments to that. We want to just sort of set those, lay out those ground rules for how we're going to iterate, or that's a different thing, but how the increments of time we're going to use as we go through these sprint to sprint to sprint. Increment is an important pattern for us to, much like the last couple we talked about where it's a, maybe it's like a definition kind of pattern, something that we need to define as a team. This is something that I guess sort of has gone, this next one has gone unsaid but is critical. The pattern is called information radiator. Essentially the goal of this pattern is to make the team status and work immediately apparent. This goes with keeping your board, whatever it happens to be, up to date, whether it's digital or not, and being able to, as a team member, take a look at what are we working on, where are we at, what's done, what's to be done. This is, I can't put a warning in here because this is something I've run into in a couple places where it becomes, it really becomes an issue, is that you can, we've talked about, you can punt, you can push something and say, we're not going to get it done in this sprint, and you can push it back to the backlog. can stop work on something or adjust because you know that you need to for sprint purposes. There's some things maybe that are the low priority that you say, we're not even going to look at them because we have these higher priority things and we need to get those done first. We know we're not going to have time to get the low priority things. This goes back to also theoretically, actually in reality, you can allow things to roll from one sprint to the next. There are things that can roll over. You can have stuff that were in the sprint backlog and they were lower priority and you just didn't get to them and you can always move them either back to the backlog or move them forward to the next sprint, however you want to do it. When you start pulling stuff out of a sprint, then it really becomes difficult or if you start adding stuff into sprint, it becomes really difficult to deal with because now you're changing scope. Yes, you want to be able to do as much work as you can, but you should be focused on doing a better job on your estimation so that you can put the right amount of work in there. Ideally you probably won't get it all done. Put a little extra, push the team and if they get it all done, that's awesome, but if they don't, that's sort of expected. Expect them to get 80 or 90% of it done, not 100%. The information radiator is a way for us to have an easy to read, easily accessible and easy to update source of information that is being updated on a regular basis by the development team, actually by the whole sprint team so that we all know where we are, what are we doing, how far we are along. It's something that is because of the nature of sprint. It's something that could be used at any given time. At any point, the product owner may look at stuff and say, there's some business changes, business roles changing out there. Let's see where we're at at this sprint. Do we want to cancel the sprint or are we maybe close enough to the end that we say, we can take this to the end and then we'll address this change in the next sprint, things like that. All sorts of decisions like that that go down to, I as a team member need to know where the team is at, where are we at, what are we working on. Dev team members are going to need it hopefully on a daily basis when they complete a task and are looking at what's left to be done and select their next task. So we have to have some sort of information radiator. This is a tool that we really need to have to some extent. So that's information radiator. The next one pattern I want to talk about is inspect and adapt. This is key to the growth of a team, to the not only the growth, the improvement of a team. We need to be able to look and this is typically through, for example, a retrospective. We need to look at what we've done and make some changes to do it better, to get things done better as we move forward. This is on task but it's also on the process itself. It may be you think of some of these other definitions that we've talked about, what is done, estimation, what is the forecasting, things like the duration of the sprint, the frequency of our daily, of our standups, statuses, how do we move stuff on the board, how do we maybe go all the way back to the avatars, how many works in progress can a team member have at a time. We need to look at these on a regular basis and the whole idea is that we, as best we can in an objective way, look at what did we do, what was accomplished, what did we do well, what needs improvement and then with that plan for the improvement. Inspect and adapt is actually inspect and adapt and plan. Although the adapt I guess sort of assumes the planning in there but this is a pattern that we need to embrace is that we're going to take a look at ourselves, what we've done and then we are going to look for ways to change, to adapt, to improve. That is a very key pattern if we want to get better, if we want to improve as a team. The next pattern is, it's an interesting one in the software world and this is the iterate pattern. I think we, I've seen a wide range of understanding of this and how we iterate to make things better. Some developers and designers and scrum masters and product owners understand this where you sort of do a are we there yet, are we there yet, are we there yet kind of approach to iterate where you take a pretty good stab at something and then get some sort of review or assessment and then based on that make adjustments and then repeat or go through the review or the assessment and then again make adjustments. Very much similar to the plan and adapt, the review and adapt that we just talked about is we need to have, and this is very critical in sprints, is that we build something, we do something and then we take a look at what we did and we make changes and we do it again and it's also sort of like walking in mortar fire or whatever. It's that you start, maybe you're not very close to the target initially but then you some adjustments, you get closer and closer and closer until you're spot on with what you need. That's what iterate is. It's almost like the 80-20 rule done over and over and over and over again. So you do the 80-20 and then you look at that 80% that you got done and get feedback and the next 20% you do essentially an 80-20 on that and then do a review and then an 80-20 on that and then you're going to get closer and closer to getting done each time. The key to iteration is that you've got to be able to, it's not like shots in the dark, it's not random. It's not you're just flailing around at something. There's an intention with iterating where you, whoever it is that's doing it has an idea of where they need to go that's pretty close to there. Like I said, maybe that 80-20 rule, they're pretty comfortable and so they can get to a certain point and it has to be another key I think is it has to be sort of an accessible point. Maybe it has to be working software or a demo or something that is enough for you to communicate to the person. So when you say, are we there yet? Think about that whole thing. Are we there yet? Are we there yet? Are we there yet? What you're doing is you're sort of, there's a lot of assumptions underneath that. It's really more like, let's say, I think almost like 20 questions. So let's say you're trying to guess an animal and you say, okay, is it a mammal or is it a fish or something like that? And you get yes or no and things like that with 20 questions. Well, that's sort of what you're doing with iterate is you are taking the universe of possibilities and you're iterating your way down to a specific thing. Iterating we're sort of doing the same thing. We've got some, except for we've got some constraints that we start with and then we're saying, okay, does this, based on those constraints, is this what we need? And then there's going to possibly be, probably be, especially in iterate, there will be more constraints or adjustments to the constraints and then you go back and you do it and then you just keep doing it until you get to where you need to be. And so we iterate over the product on sprints. We iterate on work and our daily standups. There's those time, those frequencies and those sort of like time boxes that we've put together are iteration steps. And then we do that to get better. So that's the iterate pattern. It's one that we probably have adapted to some extent, whether we know it or not. But the key to iterate is that getting closer with each step. One is accepting that we are going to iterate because there are some situations I've been in where that's part of the challenge with the sprint is that you have somebody, a product owner or whoever that wants it all, wants it to be 100% done at the end of the sprint or the three sprints or whatever that you're working on it. And it's not really how sprints work. Instead you're going to get, you're not going to define it 100% upfront. Instead you're going to start defining it. People are going to start working on it. And the understanding is that you don't really know 100%. If you did know 100%, then you could define it all out and there would be work done. You don't have to worry about iterate. Iterate assumes that there's going to be some adjustments and some clarifications that need to be done. So let's move on to the next pattern. And that would be, it's called limited work in progress. Different from the avatar that actually is a tool for, a pattern that provides a tool for the development team to not overburden themselves. Limited work in progress is really more at the, we'll say it like the sprint level. And the goal here is that with a given story, actually with a given sprint, we have a story that completes in that sprint. So we don't have, we want to limit and actually even within the sprint. So there's two things here, I guess at two levels. One is at a sprint, we want to be able to complete, complete enough stuff that we do have working software at the end of a sprint. Otherwise you'll end up not delivering as often. Within a sprint, limited work in progress, which goes back to part of the reason we want our developers to, our dev team to be limited, is the idea of completing stuff sooner rather than later. So instead of having three or four things that we're working on at a time and they all sort of wrap up towards the end of a sprint, we work on something, get it done and essentially release it for its next step and then move on to the next project. So this is basically, if you think of every, every task could potentially be a, a blocker for somebody else if it's not done. This isn't as a prerequisite, but this is more along the lines of things like testing. If I've got something that I've built and somebody needs to test it, then I need to, or even code reviews, I need to get that done so that people have time and can work in that testing or that code review before the end of the sprint. Just think about the worst case, if you have the entire dev team works, say it's three week sprints, entire dev team works and you get to Wednesday of the third week and then suddenly all of the dev team starts committing stuff that needs to be tested and needs to be code reviewed, then you basically get, you end up in this like code review testing, you know, flurry of work when some of that stuff could have been done sooner. So the limited work in progress is, it can be simplified to pick a job, do it, complete it and then move on. Don't grab two or three things. And from a definition point of view, this is important as well, is you need to define tasks as a team, as a product owner, a scrum master. Everybody needs to think about defining tasks in a way that they can be done in a sort of a standalone environment so that that task can be grabbed, done and completed all on its own, not with a bunch of related tasks. If you have some sort of like an epic or, you know, an over a larger story that you're addressing, that's fine. You know, that overarching task doesn't need to be done, but within it, you need to be down into tasks that can be done and not in tandem. And this is where you can run into problems is that you get these group of tasks, groups of tasks that really all, you can't have one done until they're all done. Sometimes this is, for example, like maybe an API or some related functionality, things like that, that needs to be dealt with. But that means that you should be able to, there's got to be a starting point. You can't have, I don't think it would be possible to have essentially a circular reference of features and requirements. If you do, you need to change how you designed your solution. But typically there should be something that this needs to be done first, and then that's going to free up these other tasks can be done. And then those free up these other tasks that can be done. And so you need to define your tasks and scope your tasks in a way that allows you to do this limited work in progress, complete stuff and move forward and not have to be a situation where you essentially have to wait until the end of a sprint to get something done or to wrap up, you know, to really to complete something. I think that's probably a good place for us to stop this time around. So we still got some patterns we're going to talk about and we will catch those in the next episode, maybe next two episodes, depending on how long we take to go through these next couple. And then we're getting close in. We're just about there, almost ready to wrap up the Agile season and we'll see where we want to go with what will be season 15. Start thinking about that where we want to go. As always, if you have any suggestions, feel free to email us info at developerneur.com with suggestions for future topics, anywhere you want to go. Or if you want us to revisit some of the things that we've talked about in the past, we're 400 and almost 450 episodes in. So we've covered a lot of topics, but we can always go back, particularly stuff that we covered back when we started out. There may be some things that are really good to go back to and to revisit. A challenge of the week this time, and we've covered a few different patterns. Which one of these are you not using and that you need to maybe take a look at and adopt? And that'll do it for this one. So 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-Nor 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 developernor.com. Just a step forward a day is still progress, so let's keep moving forward together. Hi, this is Rob from Building Better Developers, the Developer-Nor podcast. We're excited to be on Alexa now. You can enable us by simply saying, Alexa, enable Building Better Developers, and we will be there ready for you every time you want to listen to your now favorite podcast. Whether we are your favorite podcast or not, we would love to hear from you, so please leave a review on Amazon.