It seems to me that more and more ceremony is being added to software development which distracts from the actual work. This only benefits 2 groups of people: people that don't like the actual work but still want to fulfill a role in the process, and the agile 'industry'.
YMMV here. I've much more often encountered situations where I had to interview the maintainer of a repo (if there even was an official one) to find out how to contribute, whether they were even interested in contributions, and how to make sure my change didn't break anything.
A lot of these tools, processes, and special words are as much about good passive communication as anything else. That being said, tooling that doesn't fit development use cases is often worse than no tooling (presuming devs can make their own productivity scripts as needed).
Some of that is needed, though. If you're going to just shut one or two people in a room for 9 months, then you probably don't need it. But today usually you're going to have bigger teams, and the business is going to need more visibility into the project, while also giving developers a degree of autonomy and ownership of it.
When the business is willing to let it work, Agile can be kinda nice. But if the business doesn't buy in, if they keep interrupting, changing priorities and tasks mid-sprint, then it's just going to make everyone miserable.
The most important thing you need to make sure is that developers talk with end users. That is one of the biggest point of Agile.
Now, if you look again at the article, you'll notice this one interaction is completely missing. Not only that, but Scrum de-emphasize it too by creating middle-men, and most formal "Agile" methodologies don't even think about it.