I Fear For My Job Because I Can Never Meet Sprint Commitments

Transcript is auto-generated and may contain errors.

Hey folks, we're going to the YouTube comments. This one is from Crash Zero Gaming 40 and um sounds like a pretty challenging situation for them because we're junior developer. Sorry, I just backed out of this parking spot before this whole car fogs up. Uh and um I'm not reading it as I drive, but I had a a read through before I started moving here. And so their situation is that they're a junior developer. They feel like they're not growing. It's been a couple years. Um seems like their scrum master is basically pushing to have things done, you know, within within the sprint, which you know, rightfully so, kind of like part of the role of the scrum master to make sure that the stuff that's getting committed to is getting done. So, can understand that.

But I I I think I know where this person is coming from cuz they're basically saying like I'm just hoping that I don't get fired cuz it feels like I'm constantly trying to get the things landed, but like I don't know if the quality is there, like I'm rushing, right? Um you know, they also said they don't feel like I I'm extrapolating a little bit, but it sounds like they're not getting a lot of um mentorship or guidance from their other team members. So, um, that can feel a little bit isolating. It can feel like they're not supported. Um, bunch to unpack here. And obviously when someone writes a comment like this in it's hard like I have to like I feel like it's only fair that I try to provide advice, but I also like I I also kind of talk about it in a way that's like hey there's some unknowns for us as you know for me being the speaker here and for you as the audience.

There's some unknowns that I need to challenge. Okay. And that's not because I want to be like, "Oh, this person obviously sucks and like clearly it's their fault." But I have to I have to explore this a little bit when we talk through stuff like this because the the reality is that when people talk through challenges they have, right? Um we'll always say there's like at least two sides to every story. So when someone's like, "Hey, here's how it is." I I think it's my like I feel like it's my duty to be able to respond and say, "Yeah, but what about and challenge them a little bit. Not because I don't want to believe them, not because I don't want to support them, but because I, like I said, I think it's my duty, feels that way, to be able to kind of get people to look at it from a different angle." So, I want to do some of that as we talk through this.

So, let's talk about this the scrum master situation. Okay. So, there's already people that are listening to this that are going to be like, "Well, that's why agile sucks." Um, but um, hear me out. So, the role like let's not hyperfocus on like specifically what a scrum master is because we'll go in circles, no one will agree, and then everyone will just be upset. So, let me let me simplify some of it and especially based on what I'm kind of getting from this person's comment, but a scrum master is going to be uh like a like a narrow focused project manager who's looking at what sprint commitments are there. So, for folks that are uh you know kind of new to the concept cuz I have to think about the audience here. In this situation, there's going to be something like a sprint. So some period of time uh you know that could be a week 2 3 4 weeks.

So there's some time boundary that's usually set up and then the team will commit to some volume of work that fits within that boundary and they say the this is our sprint commitment and the scrum master like sort of keeps task keeps track of what's going on looks to unblock people. Um, and the way that we hear this person talking about this working relationship is it kind of seems like scrum master says X is getting delivered and we don't have a choice. Like there's a deadline set, the work has been scoped out and like I just have to hope I don't get fired. Um, which obviously that would be a an absolute way to go through work all the time. No doubt about that. Um, this person did say they are junior. I don't know what their work environment is actually like, right? So, in a situation like this, like I would be doing a couple of things.

First one would be pushing back on the scope of work, right? Like, and I don't know is is this person the only person on the whole team that feels like they can't get their work done? If so, we can approach that from, you know, one angle. Is the, you know, the team often like, "Holy crap, man. Like, like we're getting down to the wire here and like I don't know if I'm going to get my commitments in or like I can do it, but I'm going to have to like cut corners or like we're not going to be able to test." Like, is this a teamwide thing or is this like one this one person on the team that's having this issue? Because if it's a teamwide thing, then I would be getting the engineers to kind of rally and push back a little bit on Sorry, I had to stop at this light before getting on the highway.

And I'm looking at the wrong light like an idiot. Duh. There's two lanes. I was looking at the wrong one. Um, good thing there was no one there. But um if it's if it's the whole team then like then there's sort of a like a software development life cycle issue that's not being addressed. And I always look at this stuff between like engineers who are going to be doing the work and any other role whether that's a product own let's call it a product owner in this case to to simplify the conversation. So, cuz you can have product manager, project manager, you could have your scrum master, whatever. Uh, in this case, we're talking about effectively someone who's going to be owning what's getting like the schedule for what's getting delivered. And if they're not the person that's going to be building the things, they're kind of I I'm putting them at this like on the other side of the engineers.

And I personally think like from my own lived experiences, I do really enjoy a healthy conflict between wanting more things to get done. Right? So from outside of the engineering scope, we're looking at the product and the deliverables all up. I like when product is like jeez my god sorry terribly slow in that lane. Um I like the healthy conflict when when we have people in product that are pushing for more but it does require that you have like engineers with a strong enough voice to also push back. And I say this not like it needs to be a battle. Not that it needs to be like there's so much tension that you hate each other. I say healthy conflict as in you can challenge each other. You can talk through it. You're on the same team, right? I want someone from the product side to be able to say, "Hey, like these are the things I would like." And I realize that sounds challenging, but like it should be challenging, not impossible.

And then I like the engineers to come back and say like actually here's why that would be impossible or we agree that would be a challenge. Let's see if we can do that. Like it seems like a realistic challenge that we should be able to go tackle or try our best to get there. But then here's the other part to this, right? So part one is that if it's a teamwide thing, you need to be able to push back on the product owner or the scrum master in this case. The second part is communication. Because the reality is if you're waiting to the end of the sprint, let's pretend it's two weeks long. If you wait till the end to like surprise the scrum master and be like, "Ah, yeah, my work's not going to be done." And you do this every time, like that's pretty shitty behavior.

And I get it. You might be scared and nervous that you don't want to admit that it's not getting done or that you're falling behind, but it's significantly worse to surprise people at the end of the sprint and go, "Yeah, sorry, it's not going to be done. Yeah, sorry, not going to be done. Can't do it. I'm behind every single time." And the reason it's shitty behavior is because there's supposed to be a lot of these other opportunities like a daily standup to have this conversation about being blocked or being behind schedule. That's the entire purpose of it. I mean, some people will argue that, but it's one of the reasons that we have those types of meetings, those checkpoints to be able to say like, "Wait a second.

We're halfway through this sprint and I have barely even started this." Like, I need to put my hand up and say, "I am falling behind and I need support." I realize that's very difficult for people to say, "I know this because I've been doing this for like 13 years managing teams. I understand. But that's why I'm telling you that it is much worse to wait till the end of the sprint to make it a surprise that you're not going to be done. Raise awareness early. There is nothing inherently wrong with being like, "Hey, I'm falling behind on this." Or, "Hey, this is more challenging than I thought." Or, "Hey, uh, I don't know how to get started. Here's what I've tried so far, but I'm blocked. I don't know how to get started." That's okay. We are literally a team of people working together.

Now, this person said that there doesn't there doesn't seem to be pairing and all this other kind of stuff and like not that it should all fall on this one person to go kind of lead by example, but like I would have questions for them. So, like what does it look like in your standup meetings or whatever type of sync meeting you do? Why is this person switching lanes? What are you doing? I can't believe that they got in front of me and slowed down. Maybe they're on their phone. um you know has this person been like what does it look like in your sync meetings or standups when you go to raise awareness for your status are you are you telling people throughout let's I'm assuming a twoe sprint right it doesn't matter but are you telling people in that twoe period hey I'm

falling behind hey I'm falling behind and you tell anyone you know after standup can I sync with someone on this like is that happening Again, like I understand if it's not if no one else is doing it because it feels like you're going against the grain. But this is also why I asked at the beginning like are other people on the team experiencing challenges with their sprint commitments? If you have a bunch of people on the team and no one's sort of stepping up to model behavior that's going to be like helpful, it's probably not a strong team overall. I said overall, by the way, not to say like everyone's an idiot on the team or something. I just mean if you don't have people that are facilitating that kind of behavior, then no one else is going to know to model it, right?

Like I to give you an example, when I'm on call, I I try my best to make sure that I publicly ask questions when I'm stuck or if I've had a side conversation, I will share in a group chat like, "Hey, so and so was helping me with this. I was stuck on this and here's what I learned." because I need to be able to model that so that other people feel comfortable. If you don't have people modeling behavior like that, then you have people that are less experienced going, I don't know what to do. So recap so far, we need to be able to push back on scrum masters and product owners to talk about scope of work in a sprint. Number two, we need to be able to raise awareness. If we're stuck, we should have other types of meetings, rituals, whatever on your team that help raise awareness.

If you don't have those things, think about it this way. You have been tasked with work, you need to be accountable to it. If it's not on task, if it's not on track, it doesn't necessarily mean that it's your fault. There are many, many situations where something not being on track could be not your fault. Someone might expect the workout and it's completely wrong. I got to switch lanes. This guy's got to move. Um, so you know, it could be that you had a dependency on another team and they're they're behind. The point is that if you've been tasked with work, you're accountable for it. So, you could either say nothing and then surprise people at the end and they're going to go, "Man, like what the hell?" Like, "I wish." And this will happen all the time. I wish you would have told us sooner because we could have tried to do something else.

It's very rare in software engineering there's only one solution ever. So something's not working out. You probably want to look at it from a different angle. So raise awareness early. Raise it often. Um like I said, I don't want to like, you know, task the the one junior person on the team. I'm sure there's others, but you know, this one junior person on the team, it's like it's your responsibility to lead by example. Like it might be that you got to step up and do that. It doesn't feel fair, don't get me wrong, but that's why I'm saying maybe the dynamics on the team are like not stellar. Maybe everyone else on the team is also struggling with this kind of stuff and uh and no one's saying anything. I don't know. or maybe it's this person and one or two other people and they're really having challenges getting their work delivered.

Again, that's not the end of the world. It's okay. But like something has to change because if you need more assistance and you're not raising awareness to that, it's it's just going to look like disappointment after disappointment. But the reality is if you raise awareness early, that's not a problem. Right. And I I'm I'm not your manager. I don't know those interactions, but I have in my history of managing teams for over a decade. I've never had someone in a sprint in some type of, you know, whatever the meeting setting is or 101 or whatever, message me on the side going, "Hey, I think I'm getting stuck on this and I think I need some help." I have never gotten that and been like, "Oh man, like I knew this person was bad or something like that." It's like, "Okay, well that's part of my role on the team working with you, right?

My responsibility as the engineering manager is to help ensure that my team can do their best work and help them grow in their careers. So if you are stuck on something, great. What have you tried to look at so far? Why are you stuck? Like what options have you explored? Are you stuck because you have too many options? You don't know which one to pick from? Are you stuck because you've tried five things and none of them work and you need a different perspective? Are you stuck because you're waiting on other people? Like, talk to me about it. Why are you stuck? Cool. Let's go come up with a solution together or let me point you in a new direction so that you can come up with a solution. Now, I say all of these things, but this person maybe they have tried stuff like this before.

Maybe they have been asking for help. Maybe they have been raising awareness and nothing on the team is changing. Right? This is me trying to challenge some of the things I'm saying. So, if they've been trying to do all these types of things and they're like, "Nick, it makes sense what you're saying, but like it's just not working. You know, I've been asking for help. No one helps. I've been trying to push back on the product owner, but nothing ever changes." Um, even if you have other people on the team that feel the same way and they're not even chiming in to like rally behind you and be like, "Yeah, like we need to talk about our sprint commitments, right?" Or they're like, "Yeah, I've been asking for help from the more senior people, too, and I never get it." Um, if you have these

types of things happening and you have people on the team that are aware of them and no one's driving any change, if you have been trying to drive change and it's not working out, it may very well be time to go look for another team. Right? This person said in the comments, "I feel like I'm not growing. Been two years. I feel like I'm not growing. We have to think about the the things that are in this person's control, right? That's why some of the stuff I focused on was like, can you raise awareness? Like, have you been doing these things? These are actions you can take. Can you lead by example and show other people like, you know, there's a safe place that we can put our hand up and say, "We need help or I need to get something clarified or whatever it

happens to be." If you start doing those things and it's still not driving positive change in the team, it might not be a great team to be on, which is unfortunate. Doesn't mean the team is bad. It might not be a great team for you to be on. Doesn't mean that you're bad. Right? I think it's I don't like looking at things I try not to just look at them like as good and bad, but they might not be a good fit for you. Maybe the other people on the team are content working like that, but there's nothing from my perspective, there's nothing wrong with like kind of stepping back and looking at this stuff and being like, "This isn't a good way for me to work. It's not effective. It doesn't mean that the product's bad or the company's bad or that you're bad or any one thing is bad, but the dynamic of the team just might not be a good fit for you.

So, I I like looking at these things like you have an option, which is you can try to drive change, which is a challenging thing. It takes a lot of time and effort and energy, right? You have to get other people bought into the idea. You have to advocate for the things that you believe and you have to speak up about them. You have to get other people rallied behind these things, right? You're speaking up against the product owner saying, "Hey, I actually don't think that we can get all these commitments done because last time and the time before that we were spilling over. We weren't getting our test landed. I think we should talk about this." They might like genuinely they might be waiting for some of that push back to have a healthy conflict and balance these things out. and no one's ever doing it and they're like, "Okay, like I guess if no one's saying no, we'll just keep adding more stuff.

We'll just keep doing it." So, there's actions you can take, but if you're trying these things and nothing's changing, there's still an action you can take and that's going and looking for a different team where the dynamic isn't better. Doesn't mean it's easy to I'm not trying to trivialize and say, "Oh, this is very easy. Go switch teams or whatever." But like that might be a thing to go put energy into. Just one last note on this whole scrum master thing is like you there isn't a person that just gets to sit there and like magically decide that some amount of work just like fits into a a period of time by law. Like there is no like scientific physical law that just dictates that. So don't work that way. it's not going to work. Um, they could get lucky and they could be right about it, but like you don't just get to make a decision like take x amount of work and it must fit into a specific period of time.

But what you can do is suggest that you can say, "Hey, I want us can we can we do this?" And if you have a good challenging conversation, you might have engineers that will say, "Sure, yeah, you want us to get that done? Then we can't do X, Y, and Z." And you might go, "Actually, that seems like a fair trade. I'm okay with that." Right? We're trying to get this release out, and we wanted to go build this other automation platform on the side. That can wait till after the release. That's okay. Actually, I'm okay with that trade. or no maybe maybe it's like well then we don't have the automation platform if that's what you want to cut and then that means we don't have any confidence in the stuff that we're shipping at this time and then I might go oh then

I don't want that I want us to be confident okay but we need to be able to have these healthy conflicts to be able to to go unwind like what's not going to work but if it's just like I don't want to do the work or I think the work is dumb like that's a different conversation so hopefully this helps. I appreciate the question. If you have questions you want answered, please leave them below in the comments. You can send in an anonymous message at codemute.com or send a message to me on dev leader on any social media platform. That's also my main YouTube channel. You can check out programming tutorials there. It's all edited for you to follow along and hopefully it helps you on your programming journey. So, thank you so much for being here and I will see you next time. Take care.