Agile (regardless of SCRUM, Sprints, LEAN, KANBAN etc) only works where the whole project breathes it from business client to support. The contract can't be fixed term, fixed price and fixed scope and be agile. The closer you get the client to the project, the higher the chance of success because only they truly know where to cut scope or what minimum viable release looks like. There should be no surprises, fast loops ("I don't love that feature but I can wait until next release, it's good enough for now") and financial realism.
How you then organise yourselves doesn't really matter. Right now I'm at a company that's multi-tenant kanban, we release when the code is ready. That could be every 2 days, it might be once every 3 weeks. The product manager, who is very close the customers, decides when to push what's been coded out. It gets merged and then into the test/UAT pipe. Releases are cheap, test has a lots of regression automation. I describe it to management as a river. Keep the tickets flowing like water. Get rocks out the river, make it wider with more people or faster with better tech/stack/devops/etc.
Everywhere I've worked that has had a strict SCRUM ended up being micro-waterfall where devs might story point 1 sprint but the management would plan out the next 5 to get to a release date, story points were converted into estimates, which were converted into deadlines, guesses became promises and scope could never be cut. Developers end up burning out and that vital domain knowledge is lost (the worst companies think devs are interchangeable). It was almost worse than waterfall because with waterfall the project managers got the blame, with SCRUM, it's the devs that carry the can. As one colleague said after a ridiculous meeting where our story point estimate was being compared with another team on another project in another country "it's just a stick to beat developers with". And he was right.
You mileage might vary! My experience only.