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 continuing our season where we're looking at the Agile manifesto, Agile in general. We've worked our way through all sorts of areas through the principles, the values, any patterns. Then now, we're going to wrap up looking at some patterns. And we're going to dive right into those. The first of the Agile patterns, and actually let me back up just one second. We looked at in the any patterns, classifications of any patterns we'll call it. There were the dev team any patterns. There's the Scrum Master any patterns, the product owner, IT management, the entire Scrum team or Sprint team. We're going to look at these patterns are a little more like software patterns where they're much more specific in addressing a very specific issue. Now with that, setting that stage a little bit, let's step into the first pattern. This pattern is known as, call it because I've seen enough of that, Avatar. This pattern, the goal is to avoid a team member, a dev team member taking on more than they need to. Remember, we talked about one of the any patterns was not having a limit on works in progress. keep people from doing, taking on more than they could or sort of gobbling up tasks and then having things sort of just sit there and rot basically while we're waiting for that resource to get to them. Because there really is only so much you can do at a time. So it doesn't make sense that you would have 10 tickets you're working on because you're not really working on all 10 of those. Avatar addresses that and it does so by, and you got to think about this in the world of maybe like a Kanban board or something like that. So where you've got these tickets up there that are either the backlog, depending on how you do it, that you have the backlog, they're in progress or they're done. Well typically what happens is someone will write their name on a card or something like that or in a tool, assign a ticket to themselves and move that over to in progress. What you can do with an avatar is you give, thinking about the board, you give everybody maybe a certain pin color or maybe you do have something like an actual avatar if it's an app or maybe refrigerator magnets or something like that that signify that person's working on it and they've got a limited number. So they can only put their magnet on a certain number of tickets at a time. It may be one, it may be two, it may be three, but it basically says, here's your limit. This is what you're working on. So maybe it's no more than one thing at a time or no more than two things at a time because then you're out of avatars. You can't grab anything else. You can't be working on it. And if somebody wants to move it into the in progress, well, then it's going to be an in progress and nobody's going to be assigned to it. So it's going to be a problem before it needs to get pushed back to the backlog. There's a lot of ways you can go about using avatars. I've actually not done research on that being a feature of any of the tools that are out there. There probably are some that are configured in a way that you can limit the number of things that people are assigned to. Most likely that's going to be some sort of a customization, but maybe as teams progress and we get a little more mature in our ability to do agile and sprints in particular, then maybe we make a little bit of a change in that. Even if you don't have them, that can be part of your daily standup. You can just look at what people are working on. If somebody says more than whatever your limit is, more than X number of items, then at least you can take care of it that way. But avatars are a real nice way because then you only have X number of pins or magnets. Once you're done, that's what you're working on. That is the avatar pattern. Next one I want to talk about is backlog. This is something we've talked about quite a bit, but we've thought of the backlog as more of a bucket or a bag. I think the backlog, although we've looked at it, it is a pattern essentially. One of the things we haven't touched on is turning it into essentially an ordered list. You would do it most likely by priority. Some people will do it as a future sprint. Some places will even create two or three or four sprints into the future and you will have backlogs for each of those sprints so that you have a built-in sort of prioritization. Again, the key to this is it's not going to be set in stone, but what it does is it allows you to actually plan epics or series of stories or even address stories that are going to have to be like a part one and a part two. They're going to have to cross sprints. You can build up multiple backlogs. That's the easiest part of it. That's the simplicity of a backlog. You've just got this thing, this container that you're putting tasks in and then you're assigning a container instead of the individual tasks in a sense to a sprint. Then within that, if you add a little bit of some sort of prioritization or ordering to it in some way, form, or fashion, even if it's the simplest, as we talked about, prioritization in three ways. The have to have, want to have, nice to have, something along those lines. Then you're in pretty good shape. Then you've got something that you not only know what you're going to do, you have something that sort of leads the dev team to pick certain items sooner rather than later. Backlog obviously should be pretty comfortable and familiar by now because we have mentioned it many, many, many, many times. The next one I want to talk about is controlled failure. We touched on this in a couple of the anti-patterns. I don't remember that we really mentioned it before we got into those. And that's the idea of, in short, canceling a sprint. Or it really goes beyond, control failure goes beyond canceling a sprint to even more granular things like canceling a feature or stopping a path or removing something from a roadmap. So it could be longer term, it could be shorter term. And the whole purpose of this, this is a pattern that it's interesting that we need to have this pattern in a sense or that we need to look at this because we're very quick to add, to increase a product, to put features in and functionality and things like that. But we tend to be sort of slow to say, no, we've got to stop. This isn't going to work. This is not either not valuable or not valuable enough or the market's changed and we don't, this doesn't make sense anymore. Things like that. It should be, we've talked about this, it should be at the product owner level. But one of the patterns that we need to consider out there is the idea of controlled failure. And the pattern for this is really that we do as part of our, really like our grooming and things like that, that we should be regularly taking a look at the project or the feature and saying, does this make sense? Is this, is this something that we, we need to work on? And we have a couple of options. We can either say, yes, let's continue. Or we can say cancel it. Or you can do a, you know, a pivot essentially where you say, well, this is the direction we were going with it, but we need to change that direction. Halt, you know, moving forward in that direction. And now we're going to change direction. This would be a good example. This would be building out a, a mechanism for supporting organizational users. And you get to a point where you realize that, no, this is only going to go out to individual users. So the infrastructure to support organizations and hierarchies and things like that is not needed. So we're going to pivot and we're going to design for, you know, the individual user, and then we're going to, you know, we're going to make the adjustments as needed. And this can also be, it doesn't have to be a complete failure. It's called the control failure. It could be a stop as well. There may be something like in a pivot, particularly where we look at something and you say, oh, this is not the direction we want to go anymore. So instead of moving forward, you stop, pull it back into the backlog, reassess it, redo it, fix it, whatever you need to do and adjust it. And then end up pushing it back into at some future sprints. Then you push it back into a future sprint. Obviously not, as we've talked about, not pulling it into the current sprint because that would be changing the scope. Another pattern we need to be sure of, and we've, we've touched on this when we talked about statuses and things like that, is the done pattern. And we think that some of these are things that we need to not, in a general sense of patterns, you think of it as how you do stuff. These are patterns that you in some sense need to have as well. And done would be probably one of the, the primary of these. What constitutes in an agile, you know, smooth flowing, constantly adjusting, or maybe not constantly, but adjustable framework, what constitutes done? What does it mean when we say we are done with the task, when we are done with the sprint, when we are done with a retrospective or review or anything else? We need to be able to do something. And then we need to have some common understanding in the team of what constitutes that being done. What makes us, it's pretty easy, I think, to move from the backlog to in progress. You know, somebody's working on it. What is it that needs to be completed to go from in progress to the done column? Is there, is there some sort of a, like acceptance, whether it's user acceptance or management or product owner acceptance, you know, something like that. Is there a code review that's required? Is there testing that's required? There should be, all of those should be there to some level, but depending on your team and how you have stuff set up, then you may or may not have each of these pieces. And you may, there's obviously going to be varying levels of doing those things. A, a code review may be very simple or it may be, you know, a whole team gets together and stuff like that. A place that I recently worked at that was pretty, pretty well structured for that kind of stuff. They had a minimum number of code reviews had to be done. And in some cases, they even had specific resources, you know, teams that had to have at least one of their members do be part of a code review and they weren't done. These were done online. So you would just have your, your code had come through. You'd take it through, and this is through Atlassian's tool, Crucible and FishEye. Crucible is really the, with the code review tool and FishEye is for, for doing the comparisons, but you'd go through and you'd have to have a certain number of reviews for something to pass. If it didn't, and you tried to move it forward, then it would end up getting flagged and you get a little email that says, Hey, you need, you know, you don't have enough reviews, it failed the review. Some places, a lot of places now are building in testing as part of that, particularly with continuous integration and deployment through, you know, like a Jenkins or some of those kinds of tools that you've, you've got some built in rules that say when something gets committed and, you know, there's some sort of a, maybe a pull request, a merge request or something like that, that there's a, you know, there's a, there's a merge request or something like that, that there's a series of tests that are run against it to make sure that it's, that it passes a test. If it doesn't, it fails and it's got to go back. So it's not, you can say it's done, but if it fails those tests, it's not done. And so you go back, you work on it and you try again. So done is very, very important for us to clarify that, document it to some extent so that the team members know what, what to do and how to do it. And that brings us to another good pattern that is in that same, that definition style of a pattern. And we'll call it forecast or estimate. We have talked about estimating being, not a hard and fast thing that we do. I mean, it is, and it isn't, it's not like, and it's not, and by that, I mean, it's not like we say this is going to take two hours. This could take four hours. This is going to take an hour. It's going to take 30 minutes. And then we add all that time up and then we say, okay, so for an a 40 hour week, this is what it's going to take. No, we, we try to avoid that at least we should. And instead we have these essentially the buckets of difficulty. So it's made there, you know, very easy and quick, or maybe it's not so easy, but it's quick. And then maybe it's, you know, average, and then maybe it's complex and then maybe it's very time consuming. And you have these gradations of effort that you can use for your estimates. A lot of places have used, I don't like it. Several places I've been use a Fibonacci sequence. So you have a, which is basically every number is the sum of the previous two. So you'd have like a, your, your estimates are one, two, three, five, eight, 13. And then by the time you get about, you could go to 21, but by the time you get to 21, that's too big. Typically several of the places it's, it seems like it's, it's a little bit more than that, but it's moderately consistent. It's also a growing scale a little bit. So you can probably do three or four ones in a day, but an eight is probably going to take you a week. However, that, you know, works out in hours and stuff like that. So it sort of works out. That's not quite hours, but it's definitely a sliding scale. So it's, it's more likely to take longer. You know, like maybe a three maybe can be done in a day or so. A five is going to take a couple of days. By the time you get to eight, it's a week. Usually by the time you get to 21, you're talking a couple of weeks, unless you've got a really long spread. And even that it's, I guess I say a week. It's really, it depends on how you want to do your velocity and your pointing and stuff like that. But it's, I've been in a couple of places where it's turned out that roughly an eight is half a sprint, whatever the sprint happens to be. So, you know, a longer sprint, you may not, you may not get as many in. But again, then you may, you know, you may try to keep it to the point where your, your velocity points are higher. So maybe an eight is, you know, a day plus. You know, a day plus. And by the time you get to a, a 21 is, you know, maybe three to four days. If you go to whatever would be next at 34, then maybe that's a week. I don't know. You can adjust those accordingly, but I digress because that's the whole point of this pattern. The forecast pattern is we need to sit down and define to some extent that doesn't have to be exact, but we have to have everybody on roughly the same page of. What are we talking about? What do we think we should do? What would be a, let's say a productive person full-time in a sprint? How many points do we expect? You know, what do they, we expect their velocity to be, and this may change. It may grow, but early on, um, it needs to be something. I think you need to have something like that. So people have an idea of what is the scope of this thing. And it can be defined as you go. So you get together and you have everybody throw an estimate number down and they'll be, you know, initially they may be all over the place, but you talk through it as a team and say, well, you know, why do you think this is a one? Why do you take the, think this is a 43, all that stuff like that. And that discussion helps you as a team come to sort of an understanding everybody with their own individual understanding of what the, what the estimates should be. And this is even, uh, even in time boxing when it is, we're just going to spend, you know, at most X amount of hours. Um, it, it does give us a little bit of an idea of what, uh, there's some forecasting there where we're going to, there's going to be things like research and, um, other related, not directly implementation, but there's other tasks that need to be done. And we may set a couple of essentially standards for what, what constitutes, uh, you know, I'm going to quote, look into this versus, uh, I need to have a quote, you know, solid understanding of this versus, I don't know, I quote, I need to come up with a solution for this. There's some things like that. There's some sort of vague terms we use that we need to, or at least it's very useful for us pattern wise to know what those things are, to have a, a feel as a team for what that, uh, incurs as far as cost and resources and things of that nature. I think that's a good point to pause for, for this episode. We're, we still have some more, uh, several more patterns to go through. We still have some more, uh, several more patterns that we're going to talk about in the upcoming couple of episodes, but, and they're going to be some of the same. We're going to see some of these where there are things that we've talked about to some extent before, and we'll just sort of see how we need to spend a little more time approaching how we need to do those, how we need to define those and how we need to refine them also as a team. Challenge of the week. Which of these patterns do you, have you not worked with? Is there something here that, you know, that maybe you're like, wow, I hadn't really thought about that, whether it's forecast or done or controlled failure or backlog or avatar, are there any of those that you hadn't really thought of? For myself personally, avatar is one of them that I had not really thought of in that sense until I was doing the research for this guy, for this episode or series of them anyways. And, uh, you know, thought about that as a, you know, it's actually a nice little tool to be able to help the dev dev team members understand where their, uh, their focus should be and how thin or not they should be spread out. So that's your challenge for the week. Which of these are, have you not incorporated in it? Maybe you should. And the bonus challenge is for you to 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 today is still progress. So let's keep moving forward together. One more thing before you go, the Developer Noor podcast and site are a labor of love. We enjoy whatever we do trying to help developers become better. But if you've gotten some value out of this and you'd like to help us be great, if you go out to developernoor.com slash donate and donate whatever feels good for you, if you get a lot of value, a lot. If you don't get a lot of value, even a little would be awesome. In any case, we will thank you and maybe I'll make you feel just a little bit warmer as well. Now you can go back and have yourself a great day.