Linux kernel is more like Kanban than an Agile project, you can't really compare it to a project with an actual client who pays money to receive features in a timeframe. Stuff gets done when it's done and the BFDLs decide when the feature gets into the actual kernel.

Waterfall-style projects had 3 to 6 month timeframes of delivery and we all know how that goes. The result is always either out of date due to changing requirements or not what the customer wanted because there is no way to change course after the project specification was locked.

...or you spend so much time doing an exact specification that the Agile team has already delivered 3 incremental versions.

I don't see what use a "scrum master" is. That sounds like a small task for the software engineer or their real manager. There is nothing showing that heavy agile actually leads to features being developed earlier. In my experience it's the opposite as you build up heavy tech debt by micro-managing and optimizing for a 2 week return instead of the long term.

Waterfall were 1 to 2 year projects with heavy up-front administration. 3 to 6 months is well-balanced and that's what the "elite" companies and research groups tend to use. Two weeks is the current fad at non-tech enterprise.

The task of the Scrum Master is to make themselves redundant. They just make sure the team follows the structure they agreed on + runs interference for external issues.

After the team is mature enough, one of them can take the SM duties in addition to other tasks because the actual process runs without extra management.

Sounds like they were redundant from the very beginning. Those sound like small tasks for the engineers or the actual manager.

In my experience on a scrum team, the scrummaster was basically a coach. They helped deal with external issues as the other responder said, so the manager (team leader) didn't waste his time with that and could use his time dealing with team members and doing engineering work too. In my case, the scrummaster had this role for a bunch of parallel teams, not just one, so it was a full-time job for him. The org structure seemed to work very well for the type of work we were doing.

Yea, pretty often scrum masters are hired coaches that are let go when the team knows how to self-manage - or like you said - they coach multiple teams at the same time.

What qualifications does a "scrum master" have that a software engineer does not have when it comes to creating a self-managing team? The "scrum" pamphlet can be read on a lunch break and I don't think the certs even have exams.

In my experience, there's a couple: 1. The scrum master actually has a personality that facilitates talking to people both inside and outside the team, getting people to participate in meetings, etc. The software engineers do not. 2. The scrum master has time to spend on dealing with external stakeholders, coordinating between teams, etc. The team members have better things to do with their time, like write software.

So it's contempt for engineers again. They need a layman to communicate for them. I don't think so, engineers communicate just fine at FAANG. I don't see why they need an agile helper in non-tech enterprise. Lawyers don't need agile, and doctors don't. There is no reason why engineers would.

The team members are too busy with agile meetings to write software. That's a more common problem.

Maybe giving the tech lead a technical secretary is a better idea if you have a lot of administration to be done.

Obviously you have some kind of axe to grind and haven't worked in a place that uses the scrum process decently. We never spent much time in agile meetings.

No, that is not obvious, more than you making money from corporate agile, which few software engineers seem to actually like. Too many meetings is one of the most common criticisms.

If the "scrum master" stopped booking meetings that should have been an e-mail, the engineers would deal with those issues with time to spare. What issues really? I don't even see how a technically weak "scrum master" could deal with any real issue in a software product.