Great software was produced before agile became a thing and lousy software continued to be made after it. And agile is of course not a thing but an adjective. Everybody wants to be seen as doing things in an agile fashion. It's an aspirational goal. The opposite of doing things with some agility would be sluggishly. There's a difference between what people say they do, what they would like to do, and what they actually do. But generally, sluggishness is not something you call out as a good thing. Hence world+dog is doing agile now. Even when they are obviously being ineffective and slow.
Any time you see a product manager plan 10 sprints ahead, you know that whatever that is supposed to be, it involves a lot of pre-planning before anything has actually happened. We used to call that waterfall. Planning is not actually a bad thing. It's just when those plans are unrealistic, infeasible, or very rigid that they become a problem. That was always the problem with waterfall. The plan was treated as set in stone and two months into the project it became a bad plan. That still happens a lot. People come up with bad plans all the time and then get sucked into believing in that plan. Being agile means having the tools to adjust the plan when it needs changing. If your PM sells a six month 12 sprint project four months before engineers even look at it, you know it's going to be a mess. The plan is probably wrong and the clock started ticking long before engineers got involved. But on the other hand, when you sell a project, there needs to be more than a "we'll see what we do and how long it will take". This fundamental dilemma was never really solved by agile.
I'm less concerned with agile as a noun or adjective these days. Everybody does some form of that; so there's very little point in splitting hairs over it. I'm more concerned with processes and practices. And as an engineer, cto and product manager, my observation is that processes are introduced when automation and common sense fail. Getting rid of unnecessary process is form of agility that is good. I'm always on the lookout for those.
When it comes to sprints, I treat them exclusively as planning horizons. Checkpoints where we assess where we are relative to the current plan and decide on what to focus on in the near future. We practice continuous integration and continuous deployment. The life cycle of a sprint and of a feature bear very little relation to each other. Work might start one sprint and then a few sprints later the change might get merged and deployed. Or the work is planned, executed, and shipped during a single sprint. Or even in between sprints. I define work here to cover the whole process of inception, business requirements gathering, design, implementation, and deployment. It's fundamentally an asynchronous thing. Features ship when they are ready, not when a sprint ends. Work on features starts either when planned or when prudent/urgent. Some things just can't wait and generally, I like short cycle times for work.
There is no need for synchronization bottlenecks in the form of meetings, commit freezes, sprint reviews, or other things we had to do in the past. Because we have asynchronous tools now. Up until the merge, the feature is not interacting or interfering with the software. After the merge, the CI/CD is fully automated. There's just one manual step: clicking the merge button. Doing this in an agile way means doing that without unnecessary delay but with all the due diligence of testing, reviews, etc. And it's nice if that goes according to a plan.