Agile Manifesto, Agile practices, anti-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're continuing our season where we're talking about the Agile Manifesto, and we worked our way into Agile practices, developing software using this pretty common approach. And we have now sort of eeked our way into anti-patterns. We've talked about the development team. We have talked about the Scrum Master. This time we're going to look at anti-patterns for the overall team. This is the Scrum team, not the dev team, but overall the team and some things that maybe you should avoid doing. First thing, we're going to dive right in. And the first one is, and probably the most important of these, delivering X instead of Y, or Z instead of Y, or A instead of blue, whatever it is. When we put together our sprints, when we have a story and we've got a list of issues, of tasks that we are addressing, then we need to make sure that we follow through that. We can't set expectations one way and deliver something else. Now there's many ways that this disconnect will happen. The bottom line, the disconnect is that the product owner should have a view of what they have expectations. They have a view of what they're going to get at the end of a sprint, actually also at the end of the product development. As you go through all of your sprints, there's something that's eventually going to be delivered. And they have some vision of that. It may be very detailed and complete. And also, because it's agile, it may change as things go on. That's okay. It's not that we're not saying that what you started to build is what you have to actually build. Actually, it's the opposite of that. We're making none of those assumptions. However, this is a disconnect kind of thing. It goes back to our favorite. Usually, it's some sort of communication piece. Now it may be, there's several levels where this can occur. If it happens, or if you're running into that, where you've got a sprint review that you go through and you feel like there's somebody feels like the customer is essentially surprised. There's something they didn't expect. We didn't know the product was going to do that. Things like that. Those kinds of comments. Then we need to look at where things broke down. Now it could be, and probably one of the more common reasons is that there weren't the stories, the tasks that were defined were not built out enough. They were a little too vague or actually in this case, just too vague, full stop. We need to get better as a team at understanding, at communicating what it is that we want and what it is that we're delivering. Sometimes this is from being overwhelmed. Sometimes you've got a, for example, the product owner puts together a user story that's just too granular where there's nobody, it's just, it's a combination of things. It's too granular. It's too detailed. Sort of the opposite side is too detailed. The development team says, oh, okay, looks great. Anything with that kind of detail is correct. Instead of really digging into and doing that requirements gathering design part of the sprint properly, the dev team just dives in. And then the next thing you know, they've gone off in a different direction. Now this also can be sort of related to that is if the dev team has not spent time with, talked to, or worked with the customer and they just, they don't really understand what it is they're building, which just goes back to one of the things we talked about. The dev team is part of the scrum team. Everybody on the scrum team needs to have some level of understanding of what we are building. If you don't, then things can go awry. And this, this can show up in bad user experience. It can show up also in missed requirements. Now this, you know, a common, I guess, aspect of this, regardless of how we get to this point, a common way that this thing does get off, you know, goes off the rails and that we get out of sync is that the product owner and the dev team members are not in a regular communication. And this would be, for example, your daily standup. There should be, the product owner should be there as well and should be keeping a finger on the pulse of what are we doing? What are we building and listening to some of these conversations? And then if they have questions, if they have any concerns, it should be, it's okay for them to say, hey, we need to have a schedule, a little session to go through what it is that is expected to make sure that we're doing the right thing. That is not a misuse of the dev team to pause them for a second and say, hey, wait a minute, we need to take a look at what we're building. I don't think this is going in the right direction. It may even go to the level of canceling a sprint and saying, whoa, whoa, whoa, we are moving in a direction that seems completely incorrect. I don't think you guys understand what we're trying to build. Let's get together. Let's make sure that we all have an agreement of what's going on here. And sometimes that comes from that disconnect or the period of going off the rails comes from the product owner not being technical enough or the dev team being almost too technical. And I think that's where you see these things get out of sync is that there are requirements that are technical requirements based on the business requirements. And the dev team can, I guess, soft sell those in a sense to the product owner and say, well, these are some things that we need to do technically in order to solve the problem, which may be a hundred percent correct. And that's not necessarily wrong in and of itself, but sometimes there's other things that creep into those technical requirements. And the next thing you know, the dev team's gone off in a little bit different direction than the product owner believes, or more likely, there are design decisions that are made in the technical realm, architectural decisions and things like that that actually end up impacting or limiting the business. A simple thing would be the dev team may decide that, oh, we're not going to have every user. Something simple that you see a lot would be like every user has their own environment and there's no shared data among users. But maybe that the product owner says, oh, no, no, no, we have to have organizations of users so some users can share their data and things like that. These are moderately common requirement issues, but sometimes we don't, as we get into the technical implementation side, particularly with sprints, because you're diving into this and you're not necessarily taking a thought all the way to completion sometimes before you start into it, you can end up setting yourself up in a situation that's equivalent of painting yourself in a corner. So you want to make sure that you keep up as a team, that you keep everybody together and maybe on a regular basis talk about. For example, I've heard some things done in other realms that may be an opportunity in the sprint world. Maybe in your daily standup, you spend 30 seconds or a minute every day and say, what's our story for this sprint? What's our goal for this sprint? It seems redundant, but coming back to that over and over again and actually starting your day with that may not be a bad thing. It may be something that you're doing it every day. You may get several days into a sprint and somebody says, wait a minute, this is our goal, but we're doing these things and those don't seem to line up. That could be anybody. It could be the product owner. It could be a dev team member, scrum master, whatever it is. Although Agile by nature tries to avoid over-communicating in some senses, but that doesn't mean that over-communication is always wrong. Especially these critical things like what are we actually doing in this sprint? It's okay. It's worth the investment to over-communicate. That's one anti-pattern, is that the expectations are not met. They're out of sync for whatever reason. Another anti-pattern that I don't know that this one happens very often is when I'm actually going through and looking at anti-patterns that are out there. It's an interesting one that's brought up, and this one's the no sense of urgency. Now, this is, I guess I do see this in some sense. With the no sense of urgency, it's basically the idea that you're not pushing the team to complete something. In sprints, I think it more, let me back up, in typical development, waterfall in particular. What happens in a lot of cases, in my experience, and possibly in yours as well, is that you have this long implementation period. Early in the implementation period, there isn't a sense of urgency, so things move a little slower. But as you get closer and closer to the deadline, then people start getting a little concerned and you have this urgency appear and then it increases. Then the next thing you know, people are canceling vacations and working through the weekends. Well, Agile doesn't tend to do that quite as much because you have these sprints, and so it has a built-in urgency for each sprint. You need to complete stuff for a sprint. However, because we allow things to roll over and because we allow sometimes a potentially infinite number of sprints, there can be this sense of, oh, we'll get it in a future sprint. We'll get it in a future sprint. It goes back to the old approach to software where people would just, oh, we'll get it in a future release, and they'll cover it in a future release. We'll fix it in a future release. You just keep kicking the can down the road. Agile, you need to... Now, part of this is somewhat solved by having working software at the end of each sprint because you want to... That really builds this one that you're building working software at every sprint, but it builds this sense of, I need to, we need to as a team, have progress so that from sprint one to sprint two, we need to have something in that working software that is new, that shows that we've made progress, that we've moved forward, we've moved the ball forward. That helps to do the regular deliverable. Sometimes, I think it's probably more often when we don't have a truly working software or something that we deliver, maybe we just demo a couple of things, but we're not really delivering software into the hands of users to poke around with it. Sometimes we say, oh, well, we can coast on a couple of these things. These are some issues that we'll get those covered in the next time. That can become really devastating to a situation, to a team, to a solution. I think the thing to do with this, this goes back to trying to keep stuff from festering on the board, essentially. If it goes into the backlog, you should have something that you're looking at. How long does stuff stay in the backlog before it moves into a sprint backlog? Then within a sprint, if you don't finish something in one sprint, you really, again, this goes back to you should not have any tasks that are multiple sprint tasks. If you have something that rolls over from one sprint to the next, that thing really needs to get addressed in the next sprint. Unless somebody's canceled it or said, hey, we don't need that, it should not ever sit there and fester for more than one extra sprint. You need to build that sense of urgency into your team to say, hey, here's some leftover stuff. We need to get this stuff done now. Now, as part of your grooming, you may reduce a couple items on the sprint because you're catching up, but you have got to avoid stuff just floundering from sprint to sprint to sprint. When you do that, you lose the trust of the team. It really does. It's one of the things once you start doing that, it's easy to keep doing that and it becomes a negative habit that you can build. It's sort of like the idea of broken windows where they'd say, if you've got a building and a window is broken, then if you fix it, it's no big deal. But if you leave it, then it's more likely that within the next week another window will break and another window will break because it's just people don't have the same concern about, oh, it's a broken window. Essentially, it looks like it's an abandoned building at some point, or maybe it is. Same kind of thing with sprints. We need to make sure that we are very aggressive in tackling things that go from sprint to sprint. That's two. We've talked about delivering something that's outside of expectations and then not having a sense of urgency. Another one, I'm trying to think, as I've thought about this one, I don't know that I've seen this much. I've heard of it. There are rumors that exist, but I don't know that I've actually run into this. Not in recent years anyways. This anti-pattern would be the variable sprint length. It's basically you get to the end of a sprint and you haven't met the goal. So you extend it. You say, hey, we're going to give it a couple more days so that we can hit the goal for this sprint. It is much better to call it a failure, essentially. We didn't meet our goal. This was not a successful sprint. We didn't meet our goal. And address why did we not meet our goal as opposed to lengthening the sprint to eke it in and say, okay, we got it done and then moving on. Because when you have that success that you essentially cheated the days to get to that, when you have that, then you end up sort of hiding and obscuring some of the issues maybe that you run into. And this does occur. I think I want to be clear on this. My thoughts anyways on the variable sprint length is that it's when you vary it once the sprint started. Now, if you vary your sprints because of things like holidays and vacations and things like that. So maybe you've got, let's say you normally have a two week sprint cycle and you essentially have three weeks to the end of the year. Well, then either you can do your normal two week and then you just take a week off and then come back. Or maybe you say, well, we're going to do a three week sprint here. And I did work in one place that actually did a really good job. They alternated. They do two week sprints and three weeks sprints. I think it's what, or three weeks and four. I can't remember what the links were, but they actually alternated. And it worked out really well from a productivity point of view because you would have these smaller, you basically would end up having, is you get a lot of smaller items in the short sprint. And the longer sprint was the things that needed a little more design and thought and implementation time. And so you were allowed to, you had sort of a steady, it gave you a steady stream in a sense of in a sense of features that were coming into each sprint at the end of each sprint. But what happened is, you know, in reality you had lower sort of like low hanging fruit issues that would show up at, or things that would be addressed and show up with new features in the short sprint. And then you had the more complicated things would show up in the longer sprint. Now you do have to, you know, then if you do that, you've got to realize that you're going to have varying velocities and all kinds of things like that. And those are, because those are, those are by the nature I described, very different types of sprints. So you wouldn't want to compare one to the other, but there is, you know, there is value. I think you can do that with variable sprint length, but you do it, you set it up, you set the rules before you start the sprint. Don't change them midway for whatever reason. You know, don't shorten it, don't lengthen it. And that's part of proper grooming. You need to be able to make sure you put in the right amount of stuff that you're addressing the story for the sprint and that you can get it done in the right amount of time. If you start cheating it one way or another, then you're going to end up with issues, thus making it the, the Andy pattern. The last one I want to cover in this one is, this one's called, I've said it called New Kids, called New Kid on the Block. This is an issue that we've, we've actually touched on a couple times. And that is, is that you add a team member during a sprint or actually, or subtract a member during a sprint. This is, it's not totally uncommon because you do, you have, you know, teams grow and shrink and things like that. But ideally, and it's the Andy pattern side of it, to avoid this Andy pattern is do what you can to plan the team, just as we don't want to change the sprint length, we don't want to change the resources for a sprint within a sprint. So if somebody's going to leave, if somebody's giving their notice and they're going to leave, hopefully they do so in a way that allows you to remove them from the sprint. If they're going to, if their last day is going to be during the sprint, don't put them in the sprint. And you know, this may be something as an organization that that's part of the, the employment agreement basically, is that you, you say, Hey, normally you would give two weeks notice, but we need to give up to three weeks notice basically. So it's not really a two weeks notice, three weeks. It's a one sprint notice. So you have to, you know, you agree as part of your employment that you will let us know in a manner so that we can, you know, when your last day is going to be so that we can put you in, you know, use you fully through the sprints, you're going to be here. And if you're going to be here partially through a sprint, then you're not going to be part of that team. On the flip side, it's much easier for rowing instead. Don't, and just don't add a new member to a sprint until they midway through a sprint. You can bring them in and it's actually not a bad idea to have them sit in and just listen, not have sprint, any sprint responsibilities, but as a new staff member, employee, team member, however it works, have them listen in a little bit. That will help when they actually are part of a sprint, then they will have at least already been exposed to it. They'll done some standups. They will maybe hear some of the discussions around what's going on and get a feel for the team, the scrum master, the product owner. So you don't do the best you can. And that's these last two anti-patterns we've talked about. Do the best you can to set everything in place. When you start the sprint until you end the sprint, you have throughout that a known, you know what the rules are, what the resources are, what the time is, and you know what the issues are. What are the tasks that we're going to address in that? What's the story? You want to do the best you can to protect that sprint so there's minimal changes to those core items, resources and scope within the sprint. That's what I'm going to cut. There are some other scrum team. This will probably, this will go into a second episode and maybe beyond. We'll sort of see as we start to blur a couple of these anti-patterns. But I think that's a solid couple of things to work on today. Challenge of the Week, how's your team doing? Are there any of these anti-patterns that smack you in the face and you go, oh, shoot, we're doing that? And if so, how are you going to address it? How are you going to back out of that anti-pattern? Put together a plan and maybe you bring that up in the retrospective and say, hey, we're doing this a lot. Let's take a look at how we can fix it. And hopefully, you don't have to worry about at least fixing your day because hopefully you 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 Nord 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 developernord.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 Rodhead 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 developernord.com if you would like more information. Now go out there and have yourself a great one.