It's a bit of a pity that the waterfall model of software development is out of fashion, not? But maybe it's possible to tweak scrum/agile development to be almost like waterfall? What would be necessary?
First, introduce cycles and milestones to more or less replace the continuous delivery. Adult supervision requires setting goals. It's okay to run CI tools, as long as you have at least a couple of future magic dates, call them
next step along the waterfall and
final arrival at the ocean or call them
internal/partner alpha launch and
public launch date.
Do it right instead of the continous improvement. The waterfall model says that it's cheaper to fix bugs earlier, so do it right once and it'll stay right. This too is simple to integrate into Scrum, just boost the code review and pre-implementation consultation. Talk about how important it is to have the right design and to avoid technical debt. Make technical debt seem worse than the many other kinds of software deficiencies. With luck noone will notice that Scrum is being hollowed out.
Deemphasise the product owner. The waterfall model doesn't have a product owner. But it's quite simple to have a daily standup meeting even if the product owner is mostly blocked by another meeting.
Stories are key to the agile process, but they're not quite what responsible adults prefer. Playacting and roleplaying and foo. So forget to concoct stories at the start of each sprint. Mostly the product owner does that, so if you allow the product owner to fade out this may happen effortlessly.
Clear, well-defined goals is one thing agile programming doesn't have. The goals in an agile process are to have a happy product owner and deliver on tiny stories often. So to make scrum be like waterfall, try to introduce clear goals.
Longer-term focus. Something must replace the product owner, and that's the Plan. The goals, the delivery date, the milestones, the final product to be shipped or deployed. You can have occasional meetings to make sure the sprints don't add digressional features and that the product is approaching the declared goal.
Do all this, and you can have implemented the best waterfall development process in history, with both agile bugfixes and a stately procession of thoroughly planned features. Actual agile development would give you a good product instead of a well-planned one, but who am I to denigrate well-planned software?