Episode 394: Scrum master, weapons master and minimum tenure to not look bad

Feb 5, 2024

Transitioning to traditional scrum, scrum master weaponizing practices, dissent in the team, benefits of joining slack community, success story of negotiating equity, team composition, scrum mastering, addressing performance problems, discussion of 'Compiler' podcast, ideal tenure in tech recession, minimum tenure debate in software industry

Ask episode

Chapters

Transcript

Episode notes

Introduction

00:00 • 2min

Benefits of Joining the Slack Community and Success Story of Negotiating Equity

02:23 • 15min

Team Composition, Scrum Mastering, and Performance Problems

16:59 • 1min

Discussion of 'Compiler' Podcast and Ideal Tenure for Engineers

18:28 • 2min

Minimum Tenure and Job Hopping in the Software Industry

20:16 • 7min

Lowering interest rates and setting a new minimum job tenure

27:32 • 2min

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?