The sprint goal is a team target. If you're sick that shouldn't endanger the sprint goal because anyone in the team can pick up any work. Of course in mediocre or low-performing teams that's almost never the case but still not the fault of a product framework
What you say works 100% for trivial CRUD applications. Which is also, where SCRUM is still a bad framework, but at least SCRUM works on this trivial level of software development.
When a project is about non trivial projects, people, especially developers can not be easily replaced, because no one can replace a specialist with several years of experience on the spot. What I can archive in one day and what somebody else can archive on a day highly depends on what it is. Write a field to the database? Works. Write a rule engine? I'll probably be a factor of 10x more productive than an average developer. Write some GUI/CSS? A frontend developer is 10x more productive than me.
This seems like a disingenuous answer to me - the rest of the team will take up the slack? And if they can't they must be a low-performing team?
The OP may have some things wrong, but the 'constant grind' aspect of scrum sprints is spot on, there is no slack.
Add to that the 'radical transparency' aspect of scrum. That works great among a tight-knit team, but it can be insidious and actually self-defeating when certain types of manager get involved and weaponize it.
I'm sure there are many people who love programming, but hate being a programmer as a job, and to some extent that has always been true, but scrum seems in many cases to make it much, much worse, IMHO. The attitude displayed here is exactly the problem.
This doesn't apply for pod-based systems though, does it? They were everywhere for years there and are still very common. Basically by definition there's only one or two people that can do each task.
