Floomi

I see your username, but it might be better to leave the advice-giving to his therapist. They're the trained professional who actually knows OP and has context.

What does it take to get tech organizations to actually make the Scrum Master role worthwhile?

I have seen multiple dev cultures where the SM essentially acts as a glorified admin. Responsibilities include:

• Running standup: i.e. saying the name of each developer in turn every morning
• Running retro: i.e. drawing a plus and a delta on a board
• Running refinement / planning: i.e. clicking on each ticket in JIRA and reading the title
• Organizing team lunches, i.e. putting in a reservation at some local restaurant once a month

Frankly, this is demeaning and ridiculous. It doesn't help anyone to hire - typically - a 23 year old young woman with little tech experience to do tasks that everyone knows could be done by developers. Developers are not so important that they must be waited on, nor are they above doing the necessary work to maintain their own team process. Indeed, the original Scrum book specifically says that the SM role can and should be taken by a developer. When the SM role becomes a separate hire whose job is to do the bullet points above, developers often (rightly) don't understand why this person is a necessary part of their team at all - which can bring out some cranky and toxic behaviour that can be hard to deal with for a young woman in a field that's plenty hostile already. (To be clear: developers being jerks is not acceptable, and is also a cultural issue that needs work. [additional edit:] It is also extremely not-ideal that the SM role is as gendered as it is.)

What I'm getting at here is that the role as I've seen it implemented in many software organizations is at best superfluous and at worst leaves everyone unhappy.

I'm convinced it doesn't have to be like this. I've had the pleasure of working with an SM who correctly identified that the job description bulleted above was a waste of everyone's time. Instead, she made it her business to pay close attention to intra- and cross-team relationships, listen for what wasn't being said, provide feedback, and consistently push the team outside the lazy developer comfort zone towards better things: essentially a high-touch, ever-present team coach. Working with her was fantastic and she continues to get rave reviews from everyone she works with. This is a definition of the SM role that provides meaningful value and truly helps make teams better.

But that's not what most SM roles look like; without careful effort they seem to trend towards the "team admin" role instead. How do we push back against this? Is there a way we can shift software engineering culture towards a better definition of the role? Sometimes I think the term "Scrum Master" has become too poisoned, and we should scrap it in favour of Team Coach or something. Curious to hear your thoughts. Thanks!

I've grown to become slightly distracted by the foley that’s added to many of these nature docs

I noticed this on Dynasties especially -- it seemed really overdone. I don't know how much that's because I'm listening for it, but I don't remember it being so loud and intrusive, even on PEII. Obviously it's incredibly hard to get right.

I think what you've been seeing here is pretty common in the software world, unfortunately.

Ultimately, development is a fairly creative act that requires space to experiment and breathe. A software org that has the flexibility to release what it wants, on its own schedule, can push the consequences of that all the way up the org chart. I can imagine that being healthy and productive -- but rare. Usually, there's a sales department, or at least someone whose job it is to write a contract that makes the money happen. Therein lies the problem: "give us a direct line to the customer and enough time to figure out the right things" isn't exactly compatible with "we need to get X done by Y date". So an org can genuinely want to do agile, but at the end of the day, the business side brings in the money - so the deadline will always win.

Thanks for the response!

If your Scrum Master is merely a glorified admin, she's not doing her job correctly!

I agree, but this seems be a cultural issue, not an issue with a few poor SMs. I've seen multiple organisations where SMs are expected to be the team's admin. I don't have enough data points to say for sure, but it seems to happen in orgs that are product-led, distant from customers, and heavily focused on reporting. So SMs end up being the people who wrangle T-shirt sizes into reports, or secretly turn points into time estimates for the business people to use when talking to customers.

If I'm right, then my question isn't really about SMs but about how to change organizational culture, potentially at a fairly senior (i.e. director or VP) level. Is close contact between customers and developers in large, corporate organizations truly possible? Is that desirable to folks outside developer circles? Agile isn't only a developer practice: if developers are doing agile and product/business folks are writing contracts with deadlines, there'll be conflict sooner or later. But pushing agile all the way up the org chain is a huge transformation. How do you achieve it? Is it realistic? Or are we doomed to a hard-to-manage boundary between developers needing flexibility and the business needing certainty?