Good point, but for me, this seems pretty normal.

I am myself a Scrum Product Owner and Project Manager and I am one of the very view Product Owners who can code. And I know a lot of Scrum Masters who cannot write a single line of code, even do not understand what a variable is.

For me, a Scrum Master is a coach and the main task is to ensure, that the scrum process flows and the scrum team can work without impediments. And most impediments are not of technical nature I think, but more a problem of processes, psychology, social components and over all wrong business objectives. Of course it depends heavily on the individual situation, of the team and the company, but in most cases, technical skills are not required for a Scrum Master in my eyes.

But anyway, I think Scrum is not the only key to improve software development. In my eyes, interdisziplinarity is more important and pretty underrated. In publishing companies there are sometimes job descriptions like "editorial-dev" and the task of this job-holder is to mediate between editors and devs. Not the topic of this post, I know, but I would always vote for interdisciplinary teams of devs and non-devs and more communication between them ...

I don't think you have to know how to code to manage people who code. In fact it's arguably an asset -- it removes the temptation to jump in and fix things yourself. You do need to understand the process and establish mutual trust with your team so they can help you get your head around the technical issues they encounter and in turn organize things to help them avoid those problems in the future. But you don't need to have written code to know what a merge conflict is or how technical debt impacts team velocity.

The single best product manager/scrum master/whatever you want to call it I've ever worked with didn't write a lick of code. He understood his job was to facilitate the development process and relied on us to help him understand what worked, what didn't, and how to keep things moving forward.

My view is that it's just like the old job titles like "project manager" or "program manager" minus the "manager" title part. This eliminates direct reports and other HR-ish manager duties (hiring, firing, etc) along with a matching reduction in pay.

I think it helps if your organization has the budget to hire someone to do things like managing project workflow, dealing with Jira or whatever, insuring meaningful user stories and epics are put together and so forth. It's easy for a developer to get overwhelmed by this if they have to do this in addition to regular coding duties. Of course, this depends on the size of the project.

Agile is an idea that originated for software development but can be easily adapted to other types of teams. If you take the Agile Manifesto and its principles, only a few reference anything related to software. Any team, be it a software, marketing, or finance team, could benefit from focusing on individuals and interactions over processes and tools; on customer collaboration over contract negotiation; etc.

One of the functions of the Scrum Master is to be a change agent for the organization to adapt to a different way of software teams do their work. After your software department matures in agility, other departments become impediments (I'm looking at you, finance department, and your budget-requesting process). The SM role includes helping other teams to also be agile. After that, the whole organization can become agile.