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

AI Snips

Chapters

Transcript

Episode notes

INSIGHT

Weaponizing Scrum Against Team

The Scrum Master enforces rigid rules aimed at exposing team bottlenecks rather than easing transition or supporting developers.
Strict sprint limits and blocking more work mid-sprint frustrate the team and harm morale.

INSIGHT

Rigid Process Causes Friction

Applying rigid, top-down process rules to individual teams creates friction and local frustration.
Large organizations simplify reality but must allow local accommodations to avoid misery among teams.

ADVICE

Talk Directly With Scrum Master

Engage the Scrum Master personally to understand their motivations.
Have open conversations about the effects of their methods and explore shared team goals.

Get the Snipd Podcast app to discover more snips from this episode

Get the app

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?