The difference is that Kanban won't require a million useless meetings and will actually help you plan and get stuff done.
You can do bad things with any process, just some make it easier to the the bad things.
from a developer perspective, sure, kanban is the king, nobody bugs you... but on a business you need predictibility, and even more than that: predictibility across teams, for which sprint is better at. in a well run company, the managers are not the enemies of developers, they work together to make the entire process better. there are many teams involved in a project, not only development... think about legal, accounting, warehouses, etc.
also, sprints help you avoid keeping unreleased code, which has a very high cost.
i would add that you should pick one or another depending of your type of business. for example, we use scrum, but before black friday we partially switch to kanban because we don't know all we have to do in advance (there's much more to do than we can), we just know the resources available and we need do switch/move/reprioritize faster. each has it's own strength.
It isnt. Not really. It gives the illusion of predictability.
Businesses do crave predictability but when a problem space is naturally chaotic it's unrealistic to assume that you're going to get it just by switching development methodologies.
Thus - how does one get predictability out of a process that is designed to be able to change direction within a small increment of time based on unknown customer feedback? I believe the answer is you don't. Business predictability is therefore an issue.
Yeah you'd think after several decades of software development that curmudgeon-y developers would finally realize that writing software for a living is a team sport but nope, we're still having the same complaints of "wHy cAnT i JuSt WrItE cOdE iN PeAcE?" every time the discussion comes up. If you want to code with 0 distractions, do it on your own time.
My main issue with Scrum is that it’s designed to boil often complex tasks down into tiny pieces, such that anyone can pick them up and do them. The administrative and mental overhead with slicing tasks up (and holding meetings to do so) is significant, and frustrating. In a high-performing team where you have specialists, let people do what they’re good at. If someone doesn’t know Terraform, jumping into a complicated task involving it isn’t a great idea; instead, have them take on things they can do, and occasionally shadow the expert doing it to pick some knowledge up.
I’m also a big believer in gating off chunks of your day explicitly for learning. Your manager has to be onboard with this obviously, but dedicating an hour to increase your knowledge pays dividends over time (now there are two TF experts, etc.)