Building Better Developers, Episode 439

This is Building Better Developers, the Develop-a-newer 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 agile processes, and we've moved to a portion of the season where we're talking about anti-patterns. This episode, we're going to focus on some anti-patterns of the Scrum Master. We've talked about the development team. We're going to talk about the product owner. We're going to talk about the overall team. But this episode, the focus will be the Scrum Master. These are essentially things not to do. And we're going to dive right into them. We're going to dive right into them. The first one and probably the most, I don't know if it's the most comma, but definitely one that I've seen a lot. It is a crucial thing to miss out on, a crucial anti-pattern. And that would be no retrospective. Whether the reasoning behind the lack of a retrospective is that you have, I will say, achieved perfection, achieved nirvana, that you have an agile team that works awesomely, or whether you just don't have the time for it or you don't think the team is taking it seriously. Whatever the argument is, whatever the reasoning, if you don't have a retrospective, you will not improve. Actually, I would go out on a limb, and it's not very far out on a limb, to say that if you don't have a retrospective, you will get worse. You will actually, instead of, as we've talked about, getting momentum going in the right direction and building good habits, if you don't have retrospectives, you are far more likely to create bad habits. And that can end up being a very big problem. You skip a few retrospectives, let a couple bad habits settle in. Next thing you know, you are just, you're scrambling and struggling to get any kind of improvement because you've got all of these bad habits that you have to break before you move into good habits. This is accepting reality. We are not perfect. No team is perfect. Nobody does everything 100% right. There's always room for improvement. End of sentence. So that means that we always have an opportunity in a retrospective to look at what we're doing, what we're doing well, what we're not doing as good as we'd like to, and maybe some instances where we're doing things very poorly or that really need to be addressed. Whatever that point on the spectrum that your team is, a retrospective is critical. You need to always have the retrospective. Of all of the ceremonies we've talked about for Sprint, for Scrum, I think retrospective may be the most important. You can get away without a review from time to time. If you never have one, you're going to have some, you're going to struggle. But retrospective, I think that needs to be probably first and foremost, the ceremony you do every time, every Sprint, you have a retrospective. And in itself, when the team knows that there is a retrospective, when that is just, that is a part of every Sprint, you are showing that you understand and respect the process and building good habits. The first retrospective or two, people may be scrambling a little bit, trying to rack their brains to figure out what did we do right? Where do we need improvement? As you go through a couple of these retrospectives, the team will get a feel for what they do well, and thus, maybe some things where they can make improvements. And there's going to be pain points or struggles that are going to bubble up, and that's going to end up showing up in retrospectives. At least it should. If not, then you may have a team that's just a non-functioning team. But lack of retrospective, probably the number one most damaging Scrum Master anti-pattern you can run into. Lack of support is another, and it's sort of a lack of support or almost, I don't say like a lazy fare, hands-off kind of Scrum Master that acts more as a project manager maybe or glorified secretary or something like that. Scrum Masters are part of the team. They are there as a coach. We've talked about that a little bit. The purpose of the Scrum Master is to coach the team, is to help them get better, is to remove obstacles, and to be a set of eyes on progress. So if you don't have a Scrum Master that is active in pushing things like estimates and trying to meet those, then you may allow team members to flounder essentially. Because although, yes, team members should raise their hand or notify the team or something like that when there's something that they're struggling with, that doesn't always happen. So the Scrum Master should be that second set of eyes. They should be looking over people's shoulders figuratively a little bit to say, Okay, you said this thing was going to take, we decided this was going to take roughly a half a day or a day. We figured in an estimate now it's taking you, we're on our third day and you're still working on this. What do we need to do to move this forward? Or it could be sooner than that. But that's part of what the daily stand-up should help address, is to highlight where people are having struggles. And it's the Scrum Master, they're supposed to help them with that. They're supposed to coordinate what needs to be coordinated, to organize what needs to be organized, to allow the dev team to work as fast as possible. If they get blocked, for whatever reason, the Scrum Master should be looking into that, should be trying to help them get through or get over that obstacle or get around that obstacle, however that works. We need a Scrum Master, the Scrum Master doesn't need to be technical to help the development team, the dev team gets stuff done, but they do need to be able to help essentially manage pieces of that. So for example, if somebody's struggling, then the Scrum Master may be able to look around the team and see that there's a resource that is not struggling that could maybe help out and say, hey, why don't you shift your focus a little bit and help out with this task? Pause the one you're working on and move to this other. Or maybe bring the whole team together and say, this seems to be something that we can all learn from and it would help us to all put our heads together and figure this out. Or a couple members of the team, however it works out. But in general, Scrum Master needs to be doing what that person can do to help assist the team, the dev team in getting things done. Any pattern anywhere probably, another one that you'll see in Scrum Masters is micromanagement. Now from a Scrum Master, I guess there's two things, there's two micromanagement facets that Scrum Masters deal with. One would be the Scrum Master themselves micromanaging thing, making themselves too much a part of the estimates and the requirements gathering and all the other stuff. In particular, if the Scrum Master at some point is some sort of a gatekeeper or decision maker or something like that, because then they could become the blocking factor. More likely, more often, the challenge for the Scrum Master is that others are micromanaging the team. Scrum Masters should be sort of, besides removing obstacles to the team, they should be a buffer for the team. Product owner and stakeholders, CEO, whoever it is, should not be able to go directly to dev team members and co-op them and say, hey, I need you to go work on this or hey, why don't you work on this project, this ticket or something along those lines. Because it breaks the Scrum. If you start having access to the dev team that's not through the board, not through the sprint board, not through the product owner and the Scrum Master, then you're not going to be able to get it done. And I've seen this many, many times. Actually, recently spent time with the team that that was a common challenge, is that they were trying to work their way through sprints, but they had other job responsibilities that would pull them away. And you end up in a really bad situation because you have things that need to get done that are outside of the Scrum that everybody recognizes it needs to get done. But then with inside, within the sprint, there's things that need to get done as well. And sometimes it's a, they're both number one priority. So you can't do that. You need to find ways to either split off part of the team to allow them to do the things outside of the sprint and maybe reduce the size of your team a little bit or push every, make sure everything goes through the process, make that the only, you know, that goes through the backlog and we talk about it as a team, we discuss it, and then we figure out when we're going to get it done. This is most commonly seen in my experience, at least when you have teams that have some sort of a, I'll call it like a support kind of aspect to the work they do, where there are some job responsibilities that are maybe, for example, sometimes you'll see development teams that they create a product, but then they also are some tier, somewhere along the line in the support tier structure. So maybe they're, you know, tier four support, but nevertheless, they're on the support track. And if something comes up, especially in customer support, it can be critical. It can be something that has to be done now. All hands on deck, get this thing done. And that's, that's just reality. That's okay. But you need a way to handle that that doesn't disrupt your sprint. Which, as I said, it may be that your, your available team gets shrunk a little bit and you peel some resources off and say, you know what, you guys are not part of the sprint. You're going to do support. If you can take those, I will call it, I don't know, there are things that are impossible to estimate the kinds of tasks like support. You don't know when a customer call is going to come in. You don't know what it's going to take. Some of the bug fixing that is, we'll call them critical bugs. The things that are the kinds of stuff that say this has got to get fixed right now. We can't go through the normal scrum cycle or this normal sprint cycle and wait a sprint or two or three for this thing to get done. We need somebody working on it immediately. Then don't put it in the sprint. Make that something else. Otherwise, if you go all in on a sprint, then say everything comes through this and we may as a team decide that we're going to quickly move something to the backlogs and move it into the tickets. We're going to dress in the sprint, but that can blow up the sprint. We'll talk about some other options and ways to deal with this, but generally speaking, there should be a very narrow path that things come through, that things get introduced to the team. That's the only access you have to the team is through the scrum mechanisms, not outside or direct contact. It's hard. This is a very difficult thing to do as a manager, particularly if you've got a team that has been traditionally has had, there's been open access to the team from other people in the company. I don't know how many times I've run in a situation, and I've been in these situations where everybody in the company knows what your skill set is. If there's a certain problem, you happen to be or a team member happens to be, their name is labeled to those kinds of issues. If something comes up, people are used to directly sending an email or call that person and say, hey, I need help on X. I need this done. Because they've always done it, because they're nice people and they've got a good work ethic and all that, they say, okay, I'll drop everything and I'll get that done real quick. Or maybe it's not even drop everything, but I will get to that. I will find a way to get to that as soon as I can. Maybe they say I'm in the middle of a task, but however they do that, that's extra scope in a sprint. And you need to track that. And this goes back to the retrospective. Is that something that should be looked at on a regular basis? When you look at what your velocity is and how are we getting these tickets done, how are we hitting our estimates, that should bubble up. So if you go to that resource, that specialist resource, and say, hey, these tasks added up to whatever, 100 points of effort, and you only got 75 points done, why did you – you've been doing pretty good on the 100 points. What was the impact? And they should say, oh, well, I got pulled aside for two days to go work on this other thing. And there's – it's not always work, by the way. That could be – you could have things like, hey, I had a day off or there was a holiday or whatever. There's all kinds of things that can come up. That's the stuff that goes back into the retrospective. We should know that. We should note it. And then if it is somebody being – the time being stolen or whatever or redirected from other people outside of the sprint, then that needs to be dealt with in some way. And it doesn't need to be rude or controlling or anything like that. It needs to be done like everything else. It should be done with the goal of win-win. And I think the easiest way to do that in a lot of cases is to pull a resource or two out of the team if that's needed. If it's a one and done – if it's a once a year maybe you have some issue that you've got to pull these people out, okay, you can work with that. That's not something that you're going to run into enough that it's going to matter. If it happens every sprint, if there's some time stolen for these other things every sprint, then you need to find a way to support those external tasks and protect the sprint. And if it's member – if it deals with membership, sometimes there's multiple sprint teams that are used to do this as well. And I know we're talking any patterns, but I want to throw a couple of options out there while we're on the topic. One thing that's – and I've actually – I've seen this done in a pretty good way when you've got multiple teams and you have a couple – some number that are driving forward the product. And then you have essentially a support sprint, which is by nature, you know that that's the team that's going to pick up any support related issues and calls and things like that. And what you do is you build a very light sprint for them. Assume that they're going to have a very low velocity. And then you keep very – essentially you tend to also do sort of simplistic sprint stories and goals. And they may be things like – you may be catching – maybe it's a little bit of technical debt kind of stuff that's addressing technical debt because that's the easiest because then you're just – you know, you say, hey, if we can make some great progress, that's awesome. If we can't because all the support does it, then that's okay as well. And it's not – when you do that, if you have a – I don't know what you want to call it, a technical debt team, it's not really going to be a sprint because you just – there's too many unknowns. But it is a way for somebody else, for some resources to try to pick away at the backlog a little bit while allowing the product to move forward. And there's some other things you can do, but that's often, I think, the way to look at it. Probably the best way to do it is to pull some resources out to cover all of your other stuff, pull them out of the sprint, and then let the rest of – and that's not like mid-sprint. They're just not part of that team for that sprint. And you can – you know, if people don't want to work support, then they work support for one sprint cycle or whatever, you know, and then swap them out. Let them come back and do the product development while somebody else falls into the support role for a while. So that's what we call micromanagement is basically allowing access without the gateways that we've built into Scrum. And this is – this sort of flows into another anti-pattern, and there's a lot of overlap in these, which would be the disruption of – flow disruption of the sprint itself, which is anything that risks the sprint being successful, the sprint achieving its goal. And this may be the micromanagement of somebody stepping into the team in a sense. I don't know why I use this, but I've seen this a lot where it's a – it's the CEO or the CTO or some high-ranking person in the company steps into the process and starts talking directly to a resource, and it disrupts how the team works and their flow. And maybe it's you've got a team that's a cross-functional kind of team, and there are managers – you have the Scrum master running the sprint, but you may have managers that are outside of the Scrum that manage different resources on the team, and they may pull somebody aside and say, wait, I need this person for this thing. They think that – I'm trying to think of the best way to put it, but it's basically if you put a person into a sprint, it's not alone during the sprint. You are giving that person over to the sprint for that sprint period. If a manager thinks that they're just giving a resource part-time to a sprint, then that part-time needs to be very well-defined and very heavily protected. Otherwise, you get sprints that are planned, and they fall apart sprint after sprint after sprint because you don't have the resources to get the job done. The resources keep getting pulled away. And that's a – really, that's a Scrum master thing. The Scrum master needs to be the one that says, okay, this is not working. Either we step into a sprint the way it needs to be done, and we give resources over, and we don't pull resources back out, or we abandon sprints completely and say, this is not going to be a valid approach. Because you get in a situation where the sprint is essentially promising something that they can't deliver on because they don't have enough control of the team and the resources to get the job done. And then that just disrupts everything. Now, another one that's most common within this disruption – and this is really – I mean, you think of all these as sort of time thieves for the sprint. And this is the last one I want to cover on this episode is the over – the consuming daily Scrum, daily stand-up. Is that we get in there and instead of just a quick stand-up meeting, it becomes more like a status report, and there's a lot of back and forth and a lot of discussion. And sometimes you get managers in there, and then they start saying, well, I need this status, or I need to report this to this person or that to that person. And you end up basically sucking all of the team's time into this daily status report, which is definitely a risk that I've seen a lot of people had to struggle through. You get some managers that don't understand Scrum, and they say – and they're not necessarily Scrum masters. Maybe these managers that say, oh, I want to be a part of the daily stand-up because I'm going to get my – I'm going to get the status, and we're going to get all my questions answered for all the meetings I'm going to go to today or all the people I have to report to. That's not what the daily Scrum, the daily stand-up is for. If they need to do that, that's something that you do outside of it, and actually it needs to be planned for. As we talked about some of the other micromanagement, things like that, is that we need to know that resources are going to be pulled away for some of these kinds of things. Do not do it with the whole team. You need to – your goal as a Scrum master needs to be to get the whole team together for the brief amount of period to just make sure everybody understands where we're at and what we're doing. Not really status as much as just almost like looking at the board and saying, all right, this is what we've got. Maybe here's a couple of things that are a priority that haven't been touched, or here's some things that are getting – they're taking longer than we think they are. So do we need help or not? Are you almost done with that? Or do we need to reassign resources? It's really to help the team and Scrum master get their finger on a pulse of how the team is doing, how Sprint is doing, and then send people back to work. Now, if you need to hold people over and have discussions, then you can do so, but don't hold the whole team there having people that really don't need to be a part of a meeting be a part of that meeting. You need to be very respectful of the time that people have and that they're going to give to that and do whatever you can to free up the dev team as a Scrum master to free up the dev team to do the dev work. If you don't, you're going to have some issues. So Scrum master is not only a coach, they're a little bit of a taskmaster as well. I guess that's a typical coach, is you want to drive your team to do the best they can. Challenge of the week. How's your Scrum master doing? Or if you're a Scrum master, how are you doing with these anti-patterns? Are there some of these that are struggles that you need to work through? And when you think through and figure out ways we can do it. As always, it's just an email if you have any questions about them and we can we can throw some ideas out there as well or join one of our many mentor classes and bring that up. We can always have a pretty lively discussion of these sorts of things. But that being said, whether you have a lively discussion or a really dreary day ahead, however you do it, I hope you 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. 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.