Unlike most people here, I have read the Scrum Guide https://scrumguides.org/scrum-guide.html and I actually worked in a team that did Scrum almost by the textbook. And it was a great experience! But then higher management decided that the entire company needs to switch to "Scrum", so we were told to stop doing what we did, and switch to the corporate version of "Scrum"... which was exactly the kind of experience most of you are complaining about. (Then, gradually, the disappointed developers quit.)
The sad truth is that managers do what managers want to do. They may be happy to adopt a new buzzword, but they will keep doing the same old thing. Anyone who says "agile is great but scrum sucks", please realize that it's merely because managers decided that "scrum" will be their favorite buzzword. If tomorrow they decide that "agile" is their favorite buzzword, soon HN will be full of people saying "agile sucks". You should be happy that "agile" is not a popular buzzword, because it means you still have something to dream about.
In other words, it is not the fault of the Scrum process being somehow incorrectly designed. It is the fact that the design does not matter in practice, because almost no one is going to follow it anyway! It's the same thing as with ISO 9001 -- most companies have the certificate, but when you actually read the standard, you will find out that it does not resemble what actually happens in your company at all. You can't fight against people who decide to use the name of your idea, but ignore the content; which is the standard thing that happens in companies.
If I was a manager, I would probably be happy when people say "Scrum sucks", because it means they are looking in a wrong direction. It's the way how companies are managed that sucks. Scrum or no scrum; agile or no agile; ISO or no ISO; the buzzword or a different buzzword... it's still the same thing, we are just pretending that it is something else than it was yesterday.
Back to the article:
> There is no time to breathe, no time to collect yourself.
First, let me ask you: who decides how much work you should do in a sprint? Because if that person is you, they you only have yourself to blame if as a result you have no time to breathe, and you keep making the same mistake over and over again. Why don't you discuss this at the retrospective?
Ah, let me guess. It's the management who decides how much you should do, and when are the deadlines. But they generously let you choose whether you do A in the first sprint and B in the second one, or the other way round. Or they let you do the cute game of poker planning or whatever, and then say: anyway, you must have all of this ready by the end of the month.
Also, let me guess: you probably have no retrospective, because those are just a waste of time. No one is going to listen to your feedback anyway, so what's the point?
> If a development team were to sit down and decide to deliver code every two weeks, based on a process of their own design
Okay, let me stop you right in the middle of the sentence: it's not supposed to be two weeks! Two weeks are for beginners; for an experienced team, three weeks are generally recommended, but anyway that is a thing that the team should decide during the retrospective! Which you probably don't have, because no one is going to let you decide anything about the way you work.
This may seem like an unimportant detail, but it's a red flag. If the management tells you it has to be two weeks no matter what, you don't really need more evidence that their "Scrum" has very little in common with the Scrum according to the textbook.
> Every aspect of a sprint is prescribed: its duration, its meetings, its tasks, and even the roles of its participants.
Yes. Specifically, the meetings are prescribed to be short. And the managers... wait, there are actually no managers in Scrum. And no, it's not because they were renamed to "Scrum masters" and "Product owners" and whatever. Those are completely different roles. The product owner should actually be someone from the customer's company. And the Scrum master is not supposed to be your boss.
So, yeah. Every aspect is prescribed... and then ignored regardless.
> This happens because no time is set aside for proper engineering prep work. There's far more to a task than simply typing out a solution.
Exactly. So why don't you put the prep work as a task in your sprint?
Ah, let me guess: your manager said no. So much for self-organizing.
> The only remedy is to restore autonomy and professionalism to software development.
Ah yes. If only there was some system that would say "no more managers; the developers decide for themselves how long the tasks are going to take; the meetings should be 5 minutes at most; and every few weeks the developers will reflect on whether they are happy with the rules, and will adjust them if needed". If only.
I am sure your manager would allow you to do so. As opposed to e.g. using the name of your system as a buzzword, and saying "yes, we will do it... but we will do it my way: the managers will stay, you will be told what to do and how long should it take, the meetings will remain long, and the company is not really interested in your feedback. But we really like the name you invented for your system, so from now on our company will be using it officially. If someone later complains on Hacker News, we will tell them it was all your idea."