It is very odd that the two week cadence gets referred to as a sprint. Sprints are definitionally not done at a speed that can be kept up for a long period of time, yet we expect our teams to 'sprint' unendingly.

Yet they are sprints by definition. There is no pause to evaluate the work, fix past mistakes, globally plan the system, understand how it will fit when applied.

Scrum only has the part when you get your head down and code. Finished it? Good, let's see what is the next task, get our heads down and code again. "Sprint" is a very apt name.

(Of course, that is because the activities that actually bring product quality got somebody specialized on them. You can't find a best portrait of the Western management culture looking at management, disenfranchise the workers that actually know how to do things, bring somebody with no skin on the game and plenty of conflicting interests to make all the decisions.)

Scrum also has the sprint planning and retrospective phases in between the sprints. Many teams also take time to do "backlog refinement" as a second-order sprint planning process.

My scrum trainer said, with full conviction, "I've never seen a retrospective done well that took less than four hours."

Nobody does Scrum. Everybody just does the part where you have a defined list of tasks for a sprint and burn it down until you get close enough to zero before the next sprint starts. It's called "scrum-but."

You want people to do deep planing in a few hours in a meeting? That's not how people behave.

That's an interesting take. Are sprints sustainable?

you can use agile in a good way here - say you are a dev and somebody wants something from you. your schedule is set, all the tasks for the sprint have been planned and you commited to doing them. you can just say "i have not time for that but you could try to to talk to the PO. the product owner could adjust the prioritization for the next sprint accordingly.."

Working at the shout of other people tends to damage you and the company in the long term (If you are building things and have to maintain them).

I understand that not everyone is a developer and this example does not fit every role. Likewise, an "agile" way of working should not be used for every job.