Soft Skills Engineering - Episode 394: Scrum master, weapons master and minimum tenure to not look bad

Episode Date: February 5, 2024

In this episode, Dave and Jamison answer these questions: My team are about 4 months into transitioning from a scrum/kanban way of working to a more traditional scrum/sprint way of working. ... I feel like our scrum master is “weaponising” some of the scrum practices in order to show up weak points and failures in the team, rather than working with the team to ease us through the transition and make gradual improvements. In private conversations with me and some other trusted developers (lol jk I clearly shouldn’t be trusted as I’m writing in to Dave and Jamison) the scrum master speaks about how little refined work we have in our back log, and how they are looking forward to “exposing bottle necks” in the team. As they expect this will lead to pressure on our PO and Business Analyst and force them to step up their game. Whatever amount of work we bring into a sprint is law, and they forbid more tickets coming onto the board mid sprint (even if all the tickets are done half way through the sprint). If one single ticket is on the board they will try to block more tickets moving into ready for Dev as they believe we should all be focusing on getting the highest priority pieces of work into the done column. And they take no notice when I’ve expressed the issue with this too many cooks approach. They’re a nice enough person outside of a work context. But in work, it really feels like they’re setting us up to fail (and sort of releshing in it). Dissent is rising in the team, and everyone from all sides feels unhappy. Can you recommend any action I could take to prevent the failures that are inbound? For context, I am a junior developer working for a large company. Within my department we are split up into “SCRUM” teams made up of around 6 Developers, 2 testers, a scrum master, a Business Analyst and a Product Owner. The senior developers within the team have not taken any action other than to complain in secret about the SMs behaviour. Before the tech recession, I would recommend engineers stay at a job for 12 months before looking for a new job in order to avoid having the stigma of being a job hopper. But with the tech recession enabling employers to be more picky, is 12 months long enough? Or should engineers stay at a job for even longer than 12 months before looking for a new job?

Transcript
Discussion (0)
Starting point is 00:00:00 it takes more than doing all the menial work in your company because you're too afraid of the job market in 2024 to be a great hired software engineer this is episode 394 of the soft skills engineering podcast i'm your host jameson dance i am your host dave smith soft skills engineering is a weekly advice show about all the non-technical stuff that goes into the technical field of software development and a lot of it has to do with staying hired yes getting hired and staying hired yeah you want to stay hired i guess it should be employed because technically once you've been hired for one thing in your life then you're hired yeah it's like an event not a state i guess that's right uh that's right it is an event yes emit new job life event
Starting point is 00:00:56 name equals hired I want to thank our sponsor thank you to the red hat compiler show a podcast that you should check out that you'll hear more about later yeah well I want to thank our patrons please please do these generous people
Starting point is 00:01:14 have donated so much that we say whatever they tell us to say every week they are Ramit Dan from drone deploy chase W Norton type hero.dev never is not just a crater on Mars with a flamingo emoji i like chicken i like liver meow mix meow mix please deliver sorry i had to mispronounce that twice trash panda the computer science book.com valentin at datafold santa hopar
Starting point is 00:01:37 kent c dodds jenny kim owen chartle craig motlin the stochastic parrot patreon.com.no just patreon.com we're hiring ira chan the question mark literally just a question mark jonathan king webtau awesome end-to-end testing the unsettling nature of not knowing the content at willangel.net williamangel.net sorry sorry Will Travis
Starting point is 00:01:59 Brayden Keynes John Grant Cody Sale and Nick Kantar if you'd like to join this illustrious crew go to softskills.audio and click the support us
Starting point is 00:02:06 on Patreon button if you choose the level that is high enough and auspicious enough to join the illustrious crew we will say your name or whatever you can type into the
Starting point is 00:02:15 Patreon name field and and is safe for public broadcasting yeah by the way Any dollar amount greater than zero will get you access to our Slack workspace slash community. And we send those out in the first week of every month.
Starting point is 00:02:32 So by the time this airs, you should get a round of those. Thank you to everybody who joins there. It's pretty freaking awesome. There were some great negotiation threads this week about how to negotiate. In fact, I saw a thread where someone got a bunch of negotiation advice. This is in 2024, mind you, people. and was able to increase the offer they received, the equity component of the offer, by 44%.
Starting point is 00:02:54 That is massive. I was going to say it's incalculable value for subscribing, but you could calculate it and then figure out how efficient your contribution is to social engineering. Yeah, especially if you only donate $1 and then get millions of dollars of equity paid out in a few years. It's a pretty good ROI. lot yeah yeah and we promise that will happen yeah that's a guarantee you can take that to the
Starting point is 00:03:21 bank and many other things are what we would say if we could make promises like that yes yes all right should i read our first question yes and this is a long one so we might need to take some bathroom breaks in the middle but we liked it we liked it a lot so we want to read the whole thing yeah it's well written but maybe i'll get tired an anonymous listener asks my team are about four months into transitioning away from a scrum slash kanban way of working toward a more traditional scrum slash sprint way of working i feel like our scrum master is quote weaponizing some of the scrum practices in order to show up weak points and failures in the team rather than working with the team to ease us through the transition and make gradual improvements in private conversations
Starting point is 00:04:05 with me and some other trusted developers parentheses lol jk i clearly shouldn't be trusted as i'm writing into david jameson the scrum master speaks about how little refined work we have in our backlog and how they are looking forward to exposing bottlenecks in the team as they expect this will lead to pressure on our po i think that's product owner and business analyst and force them to step up their game whatever amount of work we bring to a sprint is law and they forbid more tickets coming into the board mid-sprint even if all the tickets are done halfway through the sprint okay do you need a one are you okay yeah we'll just edit the breakout though so i took a long relaxing break just now if one single ticket is on the board
Starting point is 00:04:45 they will try to block more tickets moving into ready for dev as they believe we should all be focusing on getting the highest priority pieces of work done uh into the done column and they take no notice when i've expressed the issue with this too many cooks approach they're a nice enough person outside of a work context but in work it really feels like they're setting us up to fail and sort of relishing in it. Dissent is rising in the team and everyone from all sides feels unhappy. Can you recommend any action I could take
Starting point is 00:05:08 to prevent the failures that are inbound? For context, I'm a junior developer working at a large company within my department. We are split up into scrum teams made up of around six developers, two testers, a scrum master, a business analyst, and a product owner. The senior developers within the team have not taken any action other than complain in secret
Starting point is 00:05:25 about the scrum master's behavior. Nice. Oh man, this is a great story. Okay. First of all, we just talked about... Oh, no, wait. We didn't yet. Oh, this is... I was about to say we just talked about something, but we haven't because we recorded something out of order. But let me just say, stick with this episode because it's going to be just a beautiful thread weaving its way through the thematic arc of this podcast episode. Okay. With that useless information set aside, I just want to say that this may not have come through in the audio
Starting point is 00:05:59 version, but much of the spelling and phraseology tells me this is a British person. And like all Americans, when they hear a British accent, even in written form, I think you are smarter than me. So that's just the thing. How did we win that war with those accents they had? You know, they were so smart. I'll never know. Just the intelligence of this writing. I just loved it. Yeah. All right. I love how the writing sounds when I read it out loud in my head. in your american accent yes oh man okay this there's a few things that just really struck
Starting point is 00:06:37 me here we got the what do we got here uh the scrum master is weaponizing the team to make it look to put pressure on the product owner and business analyst to step up their game and the pressure that i perceived here is that they're saying there's not enough quote refined work or you know well-defined stories in the backlog uh meaning like the team is working too fast and the and or or working faster than the product we're just too good and yeah if only we had more stuff we knew we could do yes is that i have never seen that beat i think you're right and i've never seen that actually be true in real life like yeah i've never seen not having a million more things you could do then exactly and that's
Starting point is 00:07:23 because software is a gas it expands to fill the sprint that it was placed in not in this case yeah it's a solid it occupies 50 of the volume of the sprint yeah oh i just wonder i wonder what these bottlenecks are that they're trying to expose and and why do the developers have to be collateral damage and and how does this manifest in a development team that gets to spend 50 of the time on essentially paid time off and i have many other questions like why are you complaining about this why don't you just sacrifice one member of the team to work on the one remaining ticket in the sprint and the rest of you just goof off yeah and you rotate think of all the that's a real on-call rotation
Starting point is 00:08:07 we call we actually call it the off-call rotation yeah i i have never worked in an environment of strict rigid adherence to the the scrum like sprint based way of working and i'm sure you can make it work but boy would i hate it and part of why i would hate it is the stuff that is being described here it's okay i'm reading a book called um seeing like a state which is about how large institutions in order to make sense of reality impose constraints on reality that that try to abstract and simplify things and those constraints end up like changing how people behave in the real world as well so uh if you're a tax collector in like the 1600s each town had a different unit of currency i'm totally making this up but if you are
Starting point is 00:09:01 it's hard to collect taxes so they just say like good news we'd all use this is how much a bushel is everywhere bam just like slam it down on the populace but there's always this local nuance that needs to exist in order for stuff to actually get done like maybe their bushels are different sizes because everybody has a different plot of land and it sort of like took into account how productive each person's plot was in the in the town and like so you kind of like take these hard and fast rigid rules to try and smooth out a very large area and and you get once you like press them down on the individual team level um it there are always friction points like this issue of everything's done we we literally cannot pull anything into the sprint or add
Starting point is 00:09:47 even if we're done early like that rule i could see it making sense if you have like a thousand engineering teams maybe on average the output will maybe be better if you apply that rule to all the teams but boy can it suck if you're in one of those local teams that is kind of hitting up against this restriction so my point is you are dealing with someone who is enforcing this rigid structure upon you that is trying to accomplish an outcome that is separate from like get your work done for you the developer they're trying to make the work visible and measurable and and you've got to find ways to squeeze in the little local accommodations or you're going to be miserable and how you might ask this is where i turn to my good friend dave i was hoping you would
Starting point is 00:10:40 oh good because all i'm gonna do is sit here and laugh i mean it's even more complicated that the the question asker here is labels themselves as a junior developer which which kind of brings with it a lack of influence to be able to make any big changes here potentially yeah yeah i loved that point at the end the senior developers haven't done anything except complain to each other in secret uh yes there you are seeing the value of experience and all the benefits it can bring yes solving problems like you're just as powerless after 15 years of experience as you are after 15 days of experience. Maybe, yeah, maybe they've learned some helplessness where the experience
Starting point is 00:11:28 has taught them they can't do anything about it. So complaining in secret is the most rational strategy. Like, look, it's cathartic, it's therapeutic, and the situation's not going to be any different, but I feel better. And if we ever get subpoenaed, then there's going to be some like spicy drama this will create when people read these records. So it'll make their lives better yes oh goodness boy what do you do about this you know it's this whoever wrote this i'm just so impressed with your your what's the word your observation skills your ability to put all this together and see what's going on this strikes me as the kind of situation where i would be looking around going something's wrong and i don't know what it is i feel mad all the
Starting point is 00:12:11 time but i don't know why your powers of perception that's the word i was looking for are very well developed now we'll see if your powers of influence are well developed i think you know i i think at this point i'm trying to figure out who are the people i need to talk to and what do i need to say and i might start with this one person i'm going to read a paragraph from the question there's a nice enough person outside of a work context but in work it really feels like they're setting us up to fail and sort of relishing in it. I think I might go out to lunch with this person and sit down, have a nice chat. How's work going? How's the new scrum process coming along for us? Do you relish in our failure?
Starting point is 00:12:57 I was thinking about the phrase nice enough person because it means the opposite of what it sounds like like if you ever describe someone as a nice enough person you mean they're not a nice person oh really or you just say they're a nice person right nice enough oh i don't know maybe this is a britishism you know oh they're nice enough which means they're decently nice it's not crazy nice but but you only say that when there's a problem right like i wouldn't describe you as nice enough i'd describe you as nice i would describe someone who is just really average nice as nice enough meaning you meet the bar for basically acceptable niceness i think it i would use it when it's like there's always a but they're a nice enough person but
Starting point is 00:13:44 all those dead bodies in their trunk like there's always something you're saying you're trying to offset i don't know anyways glad we could help next question this is a rough one bring it up to the person yeah i think so i mean look somebody is a puppet master here somebody has an there's a there's a motivation that might not be clear to you someone said out loud that we want to expose bottlenecks on the team and that means someone is not doing their job and this whole setup is like the most elaborate passive-aggressive approach to solving that problem, which should be solved by direct confrontation by someone who is responsible for the delivery on this team, probably the people manager, to say, someone's not pulling their
Starting point is 00:14:33 weight. Let me go talk to that person. And if they can't improve their performance, then the team needs to, sorry, all I'm getting is like immune system responses here, like to a pathogen. But I mean, really, someone is not pulling their weight and they need to be coached or encouraged out. Because if it's that bad that everyone around them is like, you know what, rather than tell you you're not doing your job well enough and give you coaching on how to improve, we're going to adopt a whole new development methodology that is just designed to reveal your incompetence so that it's apparent to everyone and hopefully you. I wonder if there's some kind of... Yeah, that's really interesting. I wasn't thinking about it from that perspective of
Starting point is 00:15:12 they're weaponizing the team against this person, against the... What did they say? The PO and BA? yeah the poba as i call the duo the poba clearly yeah force them to step up their game yeah boy is that an expensive way to force someone to step up their game is pay a bunch of developers to all work on the same ticket for a week which when it is not a thing that can be worked on by multiple people at the same time i wonder if my instinct in situations like this is always to try to find some shared goal if you go back far enough dig deep enough like what is the shared outcome we are reaching for do they want this person to step up their game because they feel like the team needs to get more done good news the team can get more done if you let
Starting point is 00:16:04 us be a bit more flexible in our sprints because right now we are blocked by by this arbitrary requirement of not pulling in other stuff you could ask them what problem they're trying to solve by doing that as well and i think they sort of have the answer which is like swarm on the highest priority thing but that's not how software always works you can't always swarm on one ticket with a whole team especially if they have different skill sets and i don't know i think i'm saying things that could be true or could not be true in this specific situation but the the point is you're trying to find out like, what are you going for with this? And can we achieve that in a way that makes the senior engineers complain slightly less? Yeah. Totally not your job,
Starting point is 00:16:50 by the way. Not a junior developer's job, but good news. It sounds like you wouldn't be a junior developer for very long if this is the kind of thing you work on. Exactly. And apropos of nothing, but I'm looking at the team composition here. Six developers, two testers, a scrum master, a business analyst and a product manager product owner sorry product owner one two three four five that's six developers and five non-developers one of which is a full-time scrum master to manage six developers this team is kind of top heavy on the org chart i think as well yeah maybe that's why you have so much drama no one's actually fully busy yeah that could be true i wonder if it depends on the area like what type of thing they're building as well like we just need a lot
Starting point is 00:17:31 of scrum mastering. Yeah. Listen, this scrum is unruly. It can't be handled by an ordinary part-time scrum master slash project manager. No. No. The scrum will master you if you don't devote all your time to it. Oh boy. Well, I don't have much more to say here other than what we've already said. I think it strikes me as a passive aggressive approach to a performance problem that should be handled head on instead. Yeah. It is interesting that manager is not a part of this team. Maybe there's like a matrix management thing where maybe the scrum master has their own manager. That's kind of affiliated with that group, not with this specific team, which sucks. Huh? Well, I know if you do what we said, your problems will be solved.
Starting point is 00:18:25 All right. Good luck figuring out what we said. Hey, Jameson, we've been talking about this podcast from Red Hat called Compiler. I guess people might think we're kind of obsessed with it, and we are. What do you want to tell people about it today? I want to tell them about a new episode I just listened to from Compiler called Warning Signs, which is about some red flags or disasters or bad things that have happened in people's careers, which in some ways is the subject of this show. So it felt like it was very synergistic. I don't know. There's something about hearing like a good prod is destroyed story that warms my heart. You particularly like those.
Starting point is 00:19:03 I love them. Yeah. And the compiler is good at storytelling about engineering. I think that's one of my favorite things about it. Yeah. And let's not miss this opportunity to say how much better they are than us at production quality. if we keep saying it then it becomes like a we're doing we're doing bad production ironically i know we know it's bad and we choose to because we're cool i think that's how it works right but seriously if you want to listen to a podcast about software development from people who actually know what they're doing and sound great and tell good stories red hat compiler is the podcast for you yep go check it out dave do you want to read our next question yes i do
Starting point is 00:19:47 This comes from an anonymous listener who says, before the tech recession, I would recommend engineers stay at a job for 12 months before looking for a new job in order to avoid having the stigma of being a job hopper. But with the tech recession enabling employers to be more picky, is 12 months long enough? Or should engineers stay at a job for even longer than 12 months before looking for a new job? This is a terrifying question. I don't know.
Starting point is 00:20:11 This just makes me scared. Because it's long enough. Yeah, just all the implications around it. I mean, would you agree with the premise that 12 months used to be long enough? I think 12 months is long enough for someone in 2021 to look at a resume of someone they think would be good and say, I can fix them. I can make it so that they'll stay longer here. Yes, they'll love me more than they'll love everyone else. There are problems with all those other places. Yeah, yeah. They did it wrong, but we will do it
Starting point is 00:20:35 right. So yeah, I think there's something to that. It feels a little bit short, and if I saw it a bunch then i'd be a little concerned but to me the times the tenure the minimum tenure time is similar to that xkcd equation that tells you based on your age who you can date based on their age have you seen that one um probably i feel like i've don't you just like wake up with all the xkcds in your head uh no there's a formula that basically says take your age divide by two add seven and That's the minimum age of someone you're allowed to date. Ah, I see it. That's like your dateable range.
Starting point is 00:21:12 Yeah. I kind of feel like there's... And so basically, the older you get, the bigger the range of dateable ages you're allowed. Yeah, yeah, yeah. So if you're 50, you can date someone as young as 32. Yeah. If you're 80, you can date someone as young as 47. That's maybe pushing the boundary a little.
Starting point is 00:21:29 But anyway, the point is that the tenure of the people you could date on Earth changes as you become more senior in the dating pool. And I think the same is true for, and it always has been true, for tenure to not look like a job hopper. If you are a 20-year software veteran, someone who has been developing software for a very long time,
Starting point is 00:21:52 12 months is not a long time to stay at a job. But if you are brand new to the industry, this is your first, quote, real programming job, 12 months is possibly plenty of time. You know, in fact, that's great. Yeah. I don't know what the new tenure would be, but I would say like someone who's been around as long as I have, it's like two years, bare minimum. In fact, if I started hopping to a new job every
Starting point is 00:22:14 two years, which I actually did at my last job, I think that would look pretty bad. If I did like four of those in a row right now, people would be like, whoa, job hopper. But you know, when you have a title that's like an executive title or a leadership title, it takes a few years to move the needle on a company in a leadership role. So you're hopping. You look like a hopper if you go shorter than that anyway yeah and it's more disruptive if you leave yeah exactly i mean especially when you're like me and you just make so much good impact that when you're when you're so good at your job and everyone cries when you leave how could i mean the emotional hole that you leave in people's hearts takes years to mend no usually everything falls apart without you but
Starting point is 00:22:56 not because you didn't do a good job of setting them up for success without you because they chose out of sadness to do a bad job once you were gone exactly it's not right in a way that doesn't reflect poorly on you at all it's not that you failed to document literally everything you did yeah it's not that you ran away with all the all the secret keys or set up a whole bunch of processes that depended on you being present and no one else could do and it's not that you totally increased the bus factor of the team single-handedly anyway back to the question at hand. Is 12 months long enough? I think I was just reading some of the words of the question and turning it into a different question in my mind, because it makes sense what you're saying,
Starting point is 00:23:38 and it's very much from the perspective of someone evaluating resumes. I just threw all that away and was like, why would you leave a job after 12 months as is right now? I don't know. It's tougher out there to find a job than it used to be. There are layoffs. Things are kind of grim for some folks. And I think this expectation that you can successfully hop jobs every 12 months is less true than it used to be, certainly. I'm sure there are people who could pull it off, but I think I would be looking for a bit more stability now instead of rapid hopping between opportunities. Yeah. I mean, to me, the question is almost the wrong question. Sorry, not the wrong question. this is a question most people are not asking right now like most people i talk to are saying
Starting point is 00:24:24 how can i hang on to my job and not leave because new jobs are so hard to get right now that they're like i don't care if i look like a job hopper that's not even hopping isn't even an option for me right now i can barely limp i would like to be a job haver not a job hopper exactly yeah i don't know i mean i think like anything when the market is a little bit tougher there's probably a lower employers can afford to be a little more picky now so maybe there's probably some employers on the margins who uh 12 months would have been acceptable and now they're getting enough applicants that they say like nah no thanks at 12 months yeah so i'm sure it would hurt you sometimes but i think i don't know it is it is i'll explain why
Starting point is 00:25:12 i think this question is being asked and it actually makes sense to me and that was that in 2021 and 22, there were so many crazy lucrative offers being thrown at everyone all the time that it was almost silly if you didn't change jobs in that time period. Because it was like, why not? I mean, you could have made like $40,000 a year more. Why are you just sitting in this old job? And so when I look at people's resumes, I'm like, oh, yep, they changed jobs in that time period. Actually, maybe twice. I'm like, you know what? I can't blame them. And if someone asks you about that, you can say, yeah, could you believe it? I got these amazing offers. How could I turn them down. Well, now those companies don't exist anymore. So now I'm looking again.
Starting point is 00:25:52 Yeah. They paid me all their money. Exactly. My salary put them out of business. Who knew? But anyway, now though, I'm like, okay, well, the economy has slowed down. People who can are trying desperately to hold on to the jobs that they have because they know the market is so hard to find a new job in. And so, yeah, it kind of stands to reason that unless you're being forcibly let go, you're going to stay at your job. And so, I don't know. To me, I think everyone is so focused on just retaining their income and trying to be as valuable as possible that I don't really think people are worried about looking like a job hopper right now in this market. And I don't think hiring managers
Starting point is 00:26:33 are worried about that too. By the way, this is another really interesting thing, but one of the attitude shifts that comes in an employer's market is that it almost doesn't matter if someone has a history as a job hopper. You know you've got them now. It's like they don't have as many options, right? I mean, think about it. You're paying the salary. I mean, this is just going to creep into the subconscious of employers. It feels evil. Yeah, it's a little evil. But on the other hand, it's kind of part of the dynamic. It's like, I know these people aren't going to go anywhere because they don't have other options. So you know i'm not actually worried about them job hopping yeah yeah the value of stability
Starting point is 00:27:12 has increased and so they will value stability more yeah that makes sense well we solved that one puzzle is solved um we just have to you know what our goal is to be successful enough that we make the tech market frothy again yeah exactly let's go lower the interest rates dave i actually just need to get on a plane with the head of the u.s federal reserve bank and do a little inception to make him lower the interest rates again was that what the i forgot what the goal was for inception so i'm gonna assume it was to lower the interest rate yeah that's right it was slightly different but close the same same ballpark yeah um but should should we declare a new minimum job tenure for job hopper for job hopper status just write it in stone i don't
Starting point is 00:28:02 want to write anything in stone i want to reserve the right to change my mind about everything but you know what if you declare it i will i will agree okay we could always without even knowing what it is let's let's declare 13 months is a new minimum threshold for not being a hopper i agree all right what can people do if they would like their own questions answered with the replies ready to be etched in stone forever they can go to softskills.audio and click the ask a question button where you can fill out our handy dandy little form there and as always we say to you those who have submitted these questions and taken the time to write them in your beautiful british spelling thank you from the bottom of our
Starting point is 00:28:46 heart also i'm just thinking of all the american listeners who are like oh if i spell optimize with an s does that mean my question will get answered it could it could yeah we don't claim to be impartial just awesome so with a z how do the what's the british spelling yeah no it's brilliant instead that's what they say instead of awesome scintillating yeah thank you for listening we will catch you next week

There aren't comments yet for this episode. Click on any sentence in the transcript to leave a comment.