>These days, it's not rare to see lead developers manage kanban-like boards very effectively, releasing on time, with grace, without the need of a scrum master to coordinate efforts.

Sadly, it's also common to see such kanban teams endlessly winging it and slowly losing sight of what they were trying to accomplish, at the same time burning out their teams on an endless stream of tickets and testing without ever taking time to reflect and course correct on their goals.

It's almost as if the process was not the most (not even close) important thing to ship value consistently.

True. But given a team of average ability, good process (ie, good habits and conventions) can definitely mean the difference between success and failure.

I'm sorry if I'm splitting hairs a bit here, but I'd argue 'good enough' process is all you need even with average teams. Keep them focused, limit their in flight work, unblock them, iterations with feedback, etc; I just feel some people spend inordinate amounts of time trying to optimize process when process hits diminishing returns pretty quickly.

>I'd argue 'good enough' process is all you need even with average teams.

That's sort of a tautology, right? If it's 'good enough', that implies it's a good process. In my experience, Scrum is a good enough process, with very little wasted overhead. It keeps the team focused, limits their in-flight work, unblocks them and offers regular iterations with feedback.

I'd agree that over-optimization is sometimes a problem, but when something as simple as scrum fails, it's usually down to the basics, like poor meeting practices, or micromanagement, or something outside of the development process entirely, like badly underbidding the project. No amount of process will save a project that was doomed from the start due to poor budgeting of time or money.

I think 'good enough' is just an expression to mean it doesn't need to be perfect or very elaborate. Unfortunately the term scrum these days is far from precise and does not guarantee it'll be lightweight, but the principles I definitely agree with. I've seen all sorts of things, including people over-focusing on the scrum process and nitpicking about all sorts of irrelevant things. I've worked with and without scrum masters in teams as an IC and manager. I think having a scrum master is often unjustified overhead, but having an experienced SM in new teams or teams with an inexperienced manager or lacking in soft-skills, it can help fill the gaps.

And yeah you said it well at the end. There are many other things that I believe are more relevant than the process, but you do need a process teams can follow.