you don't have to have a million useless meeting, most of the things can be prepared before and it won't waste the time of everyone.
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.
>on a business you need predictibility, and even more than that: predictibility across teams, for which sprint is better at.
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.
The issue with scrum is that every 2 weeks you are supposed to decide next steps based on customer feedback, not a "business roadmap." Business thinks in terms of quarters, not 2 weeks.
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.
It’s more of a collection of projects than a sequences of sprint. I think the project perspectives (the reality) is more beneficial to the mental health of the devs (which are makers). But managers (bad ones?) love the routine of the sprints, which are then imposed on the teams. At the end, they have all these numbers (story points, issues count, velocity,…) to say that it’s the fault of the devs that nothing has got done.
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.
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.
Zero distractions is a nice thought, but I’ll settle for fewer.
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.)
I'm not sure if you're confusing Scrum with Kanban. In Scrum, the team can (and should) absolutely assign tasks based on skills of individual members. There is no requirement that everyone can do everything.
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.