Many engineering orgs just give lip service to scrum, which is as good as not doing it, which is good and works better. Meaning, in my experience: You work in a priority queue, that priority queue is re-synced with stakeholders (at least) once every two weeks, retros may be there as an opportunity to get other business verticals into the room to see what engineering finished recently, and the concept of "a ticket going over to the next sprint" doesn't raise blood pressure, because the system is designed for this and sprints aren't deadlines. Features might have deadlines, absolutely, but that's independent of the sprint.

I've worked at ~three places that operated similar to this; "minimum viable scrum" is a good name, or even better, "emergent scrum" because it isn't a process that's designed, its the process that emerges when someone toggles the "agile/scrum" button in Jira, but no one really cares one way or the other. Its a good process.

I've worked in one environment that was hard scrum, had scrum masters, extremely strict. To be honest: I felt almost no stress, but the company also delivered very little. There was a lot of "we can't get to swapping the color on that button until Sprint 18 in three months, but we'll schedule it for then". Missing a sprint was life or death, so every estimate got padded like crazy. When you took vacation, it was common knowledge that you needed to leave halfway through a sprint and come back halfway through another, sprint planning would basically forget about you. That (public tech) company doesn't exist anymore, and it radicalized me against agile/scrum: The entropic end-state of perfectly executed agile/scrum is an extremely well-lubricated machine that actually does very little.

Some teams use Kanban which is a way to manage the number of tasks/tickets and doesn’t generally use sprints. It’s mostly a bug queue of work.

We don't do scrum. We release major versions once a month, and bugfixes daily. New features go into the next major version when done, bugfixes gets released as soon as they're done.

We use Kanban boards to get an overview and prioritize work. Apart from that devs mostly manage their own work.

We're a small shop though, perhaps that's why it works well.

There are plenty. All you need is a competent team that trusts each others.

I work for a huge corporation. My team plans and commits to quarterly OKRs and has a team meeting once a week to check in on how folks are doing. There are no sprints and no 2-week deadlines. Once a month or so we update the progress scoring on the OKRs.

From what I've heard, aerospace and automotive are still largely using waterfall.

To be fair, waterfall was always non-existent. It was a hypothetical invented for illustration purposes.

some places are cheating and doing design sprints and eventually implementation sprints. better than doing mythical pure implementation.