Decouple your planning cycles and development cycles. You develop at a constant pace, release whenever it is time/convenient to release. You plan regularly.
Planning is hard. Not doing it is not a great plan. Conflating development cycles and planning cycles, which is what a lot of teams end up doing with sprints, either sets the pace too aggressively or not aggressive enough. If it's too aggressive you end up shipping stuff that isn't ready. If it's not aggressive enough, you end up sitting on ready to ship code for too long.
In a company with multiple teams, planning gets harder. Especially if they span multiple timezones. Company sprints are a thing in some companies. But it's not necessarily very effective or scalable.
Calendar driven planning cycles where you ship whatever is in a shippable state is much more scalable and predictable. A lot of large OSS projects practice this (most of them) and it works in large companies too. It allows teams to self organize around known deadlines and work towards them.
That doesn't mean there is no planning but it is acknowledged that plans sometimes don't work out and that that's generally not a reason to stop a release train. If some planned thing isn't ready, park it on a branch and try to get it in the next time. Many OSS projects are very strict on this actually and ship regular as clockwork at a scale and quality level that puts most enterprise teams to shame. A lot of large companies that are typically involved with such OSS work as well do this internally as well. They are too large to orchestrate company wide sprints. So they rally around the calendar instead.
It doesn't actually exclude some teams in such contexts using e.g. Scrum or other agile methodologies. It just doesn't require it. And if you know your agile history, a lot of the Agile manifesto signees were very much into teams electing to use an Agile methodology rather than that being imposed, like is the practice in a lot of companies. It's just that a lot of OSS teams don't seem to bother with that.