The problem is even scrum doesn't give the predictability and observability better than kanban. It's extremely hard to predict what we need to do in next 2 weeks and what we can achieve in next 2 weeks. At my current company, half, if not more, of the tickets come in mid-sprint.
So even though the current company is using scrum, in my team I treat it as kanban with story point limited, meaning I start with a certain amount of story points, then add / remove as the sprint is going.
I have seen a very predictable scrum, but the tradeoffs with productivity were comical. In this very large corporation, most developers could do most of the tasks in their 2 week sprints in 3 days of actual work. But they don't know if they are going to get 3 days of actual work, or some other team is going to keep master broken for a week. Therefore, your typical sprint involves mostly fictional standup updates, as to make sure that, when things go more than a little too well, the shameful levels of sandbagging aren't visible in jira or in git.
If you ask me, that level of predictability is a poor tradeoff, but hey, it's the same kind of organization that decides that SAFe scrum is a serious methodology.
Someone who's not a technical junior needs to make it very clear that breakages will keep happening and support staff will need increasing if no one has the time to figure out a test harness or similar for the software in question. If people are literally blocked because someone else has broken master then they should be working on a test harness right now, in fact. That would actually be useful.
But the reality is you cannot hope for management to realize it, and for a good reason. If reprioritize a new feature can bring more revenue compared to original plan, or if a better flow is now available due to other team's completed task, or if a severe bug is discovered someday, it's just logical to reprioritize.
Things changing as a complete 180 mid sprint every single sprint doesn't mean Kanban is more suited as a process. It means your company is not using any process but rather is just a chaotic "who screamed the loudest most recently".
If you do Kanban right you have to have predictability through tasks of roughly equal size. If you will you can think of Kanban as Scrum where all tasks have to either be sized 2 or 3, else they don't make it into a sprint.
New items get added to the end of the backlog by default and stakeholders know when they can expect their request to be done because you know your velocity and queue length.
Putting every single request that comes in at the top of your Kanban backlog is orthogonal and bad.
This is for product dev team though, not ops. Don't get me wrong, it's easy to plan works that take less than 7 work days or more than 14 work days, assuming the sprint is 10 work days.
Planning one that's near to 9-11 work days is the hard part.
So even though the current company is using scrum, in my team I treat it as kanban with story point limited, meaning I start with a certain amount of story points, then add / remove as the sprint is going.