Antipatterns in Agile Processes - IT Management and Stakeholder Issues

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. Hello and welcome back. We are continuing our season where we're talking about the Agile Manifesto, Agile Processes, and all things related to that. We've worked our way through some of the principles and the values, and we've talked about antipatterns, and we're going to continue our talk about antipatterns today. We're going to look at, it's sort of a combo this time, we're going to look at IT management and stakeholder antipatterns. There's a lot of essentially overlap in these, so I figured we would just go ahead and try to take these as they go. The first one, it really is a stakeholder, although it could be management as well, is pitching developers. This is something we've talked about in a couple of other antipatterns, which are essentially going around the scrum master, going around the process, and trying to directly go to, in this case it would be the stakeholder, directly going to developers and pitching some sort of an idea, a task, or something like that. Basically cutting the scrum master out, trying to get the developers to get some work done. It may be to squeeze something in on a sprint that's not really officially on the sprint, as we've talked about before, sort of like a side job. It may also be something that is maybe a scope change or something like that, that is not really taken care of, not estimated for properly. It's a change to the sprint that the scrum master isn't notified of. These are not, as antipatterns go, these are not necessarily horrible, but what they do, which is where we see a lot of these antipatterns are going to point to, is they break our ability to truly measure what we're doing and get better. Now remember, all the way back, our first goal is to satisfy the customer. However, part of that is that we have got to do this scrum and sprint thing in a way that we are getting better at it each time we do it. Otherwise, we're not learning from our mistakes, we're not able to improve, we're not able to increase velocity. At the end of the day, at the end of the project, we may end up not getting done as soon as we would like, and thus maybe not satisfying the customer as much as we want to. So this is a short-circuiting of the process is going to mess things up. We're going to have impact on a sprint that is not going to be documented, and therefore we're not going to be able to properly measure it when we compare sprint A to sprint B to sprint C. So when in doubt, we need to have the whole team involved. We don't short-circuit it, we don't kick anybody out of the discussion because we don't like what they're going to say. Another one is the short version of it is everything's a bug. This is typically a stakeholder kind of issue. Sometimes IT management will throw some stuff in there as well. They'll have a slightly different impact, but essentially it's the same thing. Sometimes what happens is bugs get, if it's labeled a bug, it gets pushed up in priority, urgency, things like that. You have sort of a special case, a special treatment for bugs, particularly high priority bugs. The problem is that also breaks what we want to do. If we have bugs that are in the backlog and we're moving bugs into sprints normally, so they're in a backlog, we estimate them, we go through the whole grooming process and we pull bug fixes into a sprint, that's okay. It's when we try to say, hey, this is a bug, this needs to get added to the sprint. We set a sprint and then even though we haven't started it, but it's like, oh, well, whatever your story is, we still have to add these bugs in. In either case, you're breaking the purpose. You're making the team redirect and do something that they otherwise maybe wouldn't have. This does come, depending on how this is done, this does get you into bad situations where almost everything's labeled a bug or everything's labeled urgent. My favorite story in recent years was a customer that would just make requests and make requests and make requests. Everything was urgent. All capital letters, three exclamation points. Finally, he said, look, we can't, you say everything's urgent. Why don't we, when we create something, we'll have a tag that you can tag it as, and I don't think we called it urgent, it was high priority. And so we said, well, just tag it high priority if it is high priority. Well, next day come in, everything is tagged high priority. So if everything is urgent, then nothing's urgent, really. I mean, if everything has to be done immediately, and obviously it can't all be done immediately, then we have no ability to properly prioritize stuff. And in a stakeholder point of view, if everything that is a change or a scope creep or something like that that they look at and they say, oh, well, we've got to add some additional tickets and some additional things to be done, if they all become bugs, then you're not going to be in there critical and they have to be in a sprint, then you're not going to be able to prioritize it. You're not going to be able to say, this is a bug that we can wait on. This is a bug that we have to do right away. Essentially the idea of this is a showstopper. This is blocking progress and testing and the ability for this to be working software versus this is an annoyance or a pain point that we can address later. If you don't properly label and realistically assess issues, bugs or features, however you want to look at them, then you're going to struggle a lot to get your grooming done and to build out a meaningful sprint. So label it what it needs to be labeled. Let's not set up a situation where we game the system by changing the label to get special attention to an issue, a bug, a feature, whatever that is. One of the stakeholders will do, Scrum Masters can do it as well, particularly when we talked about this with us, when Scrum Masters weren't the proper guardian that they needed to be of the dev team. This is the idea of disrupting the flow. Now a product owner can, they can go all the way to the point of actually canceling a sprint. They can look at something and say, oh, this is not going to work. This isn't where we need to go. We're going in the wrong direction. Let's reset. You don't want to do that too often, but that could happen. The challenge for a stakeholder is to decide and let go and let the team get it done. If you end up in a situation where you are as a stakeholder, where the stakeholders in there lining up a story saying, all right, this is what we want to do. Here's what's going to be in this sprint. This is a story we're going to tell at the end of this sprint. They get partway into the sprint and they change their mind on it. Then try to change the sprint and the scope and things like that. Then it's going to disrupt the flow. The team that was getting into a rhythm and was getting things done now has to stop and reassess what's going on and adjust what's going on. What are we going to do? What are we not going to do? What's in flight and what's not? Those disruptions, even in the best of situations, they cost time. They cost mental effort because as a developer, you're in the zone, we'll say, working on something. Now you have to step back. You have to basically reset your focus and your understanding so now you can talk through whatever this other bug or issue or change is. Then you're going to have to switch back to whatever it was you were doing before. There's this mental gear switching that goes on that is going to impact the velocity. You're not going to be as productive if you're having to switch gears all the time. You don't want to disrupt the dev team, whether it's a stakeholder or anything else. The IT management anti-patterns tend to be the same kinds of issues. They really are disrupting the team and not protecting the sprint. You don't have the same resources and runway that you started with. You don't have by the time you're done. There's a couple different ways this will happen. One is the all hands on deck. Something comes up. There's a bug. There's a new customer coming in or something like that. Management decides that they just cancel sprints and just get everybody together and try to work on something. It's almost by definition, it's an anti-pattern because it's abandoning the sprint. It is saying that we don't think the sprint's going to do what we need it to do, so we're bailing out. We're going to cancel this whole sprint thing and we're just going to have everybody work on this bug or this feature or this issue or whatever it is. If it's a bug, that's one thing. If it's something where we've got a critical production flaw and we need to just maybe pause sprints for a couple of days because we need everybody to work on this thing to help correct it and get it back online. Then we go back to sprint. That's one thing. If it's, hey, we've got a whole bunch of new features, we're going to stop doing sprints because we need to just focus on these features. Then you're just basically saying, well, we're not going to do sprints. You're not going to get the value of agility and sprints because you're not doing it. You're bailing out on them. You're saying, well, we don't trust it. We have to go back to our normal way, quotes, normal way or prior way of doing stuff because this isn't working. There are situations where you can say, I mean, you may be able to back that up with data or something else and say, this isn't working, but you also have to make sure you give it enough time. If you pull everybody off of something and you don't try that new customer project and try to work it in an agile approach and you work it into sprints, then you're probably not going to, I mean, you're undercutting yourself too much. So at that point, you might as well give up on sprints with that team because you've already showed that you're more than willing to just bail out if you think things aren't working right. One more of the apples to apples comparison is shifting resources, reassigning team members. So you get, particularly if you've got multiple teams where you end up moving people around on a very regular basis and not like a scheduled basis because that you can almost work with. If you know every third sprint, you're going to be team A and then on every third sprint, you know, on a different every third sprint, you're going to be team B and it's the same members, the same makeup of a team. And it's just that team only gets together every third sprint. And then other times they're doing working other sprints. You can sort of work with that because much like we talked about alternating sprint lengths, maybe you do three week sprints and four week sprints depending on what you need. Maybe you alternate them. Things like that where there is regularity and consistency, even if it's spread out, at least you can then map those consistent points to each other and do comparisons. If you're just, you know, each time you go into a sprint, your management's moving people around and, you know, one time you got this team and another time you got this other team. And even in particular, if you even if it's the same team, but you'll go, you know, multiple sprints before you swing back around to that same team again, then you're going to have a lot of issues because every team is unique and each of those combinations is going to be unique. So if I'm working on a retrospective and say, what did we do? What do we do right? What do we do wrong? Or what needs improvement? And I know that this team isn't going to meet again for six or seven sprints. That's going to be I'm almost going to have to have like a what happened last season retrospective when I started sprint is to say, OK, this is what we talked about. Here's our notes. Here's what our discussion was. Here's what we wanted to do better. Of course, now, you know, the team is weeks or months beyond where they were the last time around, they got to that. And that can be that can be very confusing and be very, very difficult to really get the team to work together and improve. And just in general, the teamwork is going to be off when you're constantly switching, you know, who you're working with. That's why you see professional sports is a good example, as you'll see a lot of times the. For example, like in American football, you'll see a quarterback with certain receivers that they work together very well because they work together all the time. And ice hockey, they'll put the same players out on the ice together a lot because they learn to work together. Basketball is the same thing. You'll have the same people out on out on the court or pairs or triples and stuff like that because they work together very well. I mean, that's just how teamwork is. It's like everything else. You get better with time. You do it better over time. So if you don't provide time, if you don't allow the time for that same team to work together and come together, then you're not going to get the value of teamwork that you need. So you don't want to have a situation where you you really want to have IT management buy in and allow them, have them set teams, you know, allow the teams to stay as much as possible static. Now, there's a. This one we've sort of covered, but this one we hadn't really talked about as much from IT management, but it really it's the idea of special forces or is is the IT management portion of it or fire teams or. Things like that where the side projects falls under this as well, where you essentially have the members of the team, people in the sprint that are assigned tasks specifically to work on. Now, it can be it really can be even this this idea even goes into the idea of working within the sprint, but maybe as a product owner could do this, the Scrum Master could do this even where tasks are assigned to dev team members. Instead of the dev team members picking tasks and working it and trying to figure out how best to organize and work as a team to get things done, you have outside forces that are essentially assigning stuff and saying, all right, you know, Bob's our database guru. He needs to be the one working on this one. Mary's our front end specialist. She has to work on this specific task and things like that. And we talked about this before when with the size of a team, it's got to be enough and there's got to be enough overlap that there are more than one there's more than one people, more than one member of the team that can tackle a given task. Obviously, you know, one may be better than the other, but at least you have the ability for multiple people to tackle those things. That's a that's where the teamwork comes in. If you only have if you have a team of five dev team members, but they're all specialists and that's all they do. You're not going to it's probably not going to be a good model for sprints and scrums because you're not really going to be able to work together. You're going to be working. You're going to have five silos. And you want to avoid that as much as possible. Want to be able to allow the team to ebb and flow over the issues that they as they want to. It allows them to grow and allows them to work on specific tasks and it even allows them to get some rhythm. So they may be in a certain frame of mind working on a certain business aspect of the application. And it's just something they're very comfortable with. So it's easy for them to flow into the next the end of the next task or or thing problem that they want to solve. That does it for management and stakeholders. I think we've seen there's definitely some themes as we've gone through the anti-patterns. And I'm going to talk about those a little bit in the next episode to try to try to wrap up the anti-pattern side of these. And just some of the things that we need to avoid. And they, you know, I think as I've gone through these and thought about them, they are common. It is not hard to find situations where some of these, you know, some or maybe a lot of these anti-patterns show up. So I think it's a good area. It's very rich for us to take a look at in a retrospective. Are we maybe doing some of these anti-patterns and then try to get away from them in the next in our next sprint? Challenge of the week is exactly that. Not just this week's, but what we've covered in the last couple of episodes. These anti-patterns. When you get to your next retrospective, hoping that that's one of the anti-patterns that you haven't stumbled across, that you do have a retrospective. Think about those and some of the issues that we've raised. Are some of these anti-patterns that to some extent you have fallen under the. Falling into this category. And maybe you need to clean it up. Maybe you need a scrum master that's a little stronger in protecting the team, or maybe you need management to either buy in, you know, fish or cut bait. They need either really support the agile approach and sprints or not. You know, those are things. Some of those things are. Some of them are not hard to fix. We just have to be more intentional about how we do stuff, how we set up the team, how we organize the tasks and the things that we do. Some of them are a little more complicated and may require the entire team to really buy in and decide that they want to overcome that anti-pattern. That being said, I think we'll just follow the greatest of patterns out there and go out 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 Noir 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 developernoir.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 Noir. One is the book, The Source Code of Happiness. You can find links to it on our page out on the Developer Noir 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 developernoir.com if you would like more information. Now go out there and have yourself a great one.