Scaled Agile Framework or Unified Process?! Some people might call it Scrum-fall.
Working in a big org on a big product I can see why somebody would suggest mixing both. The problem is - taking the "good" things from both rather than the bad things.
For example, If you want telemetry data sent back to a repository (to track feature usage) - you might want the architecture of that figured out "up front" rather than retrofit. I say "you might." In Agile it might be an important spike to get closed up front. You have to think beyond code design and think about the whole business - when you have 200+ people working on code there are some things to take care of earlier rather than have them happen organically. Agile says that the architecture can morph and be refactored - true. But I've seen projects go into extra innings because the architecture needed to be refactored for a must-have feature. Why? Because the feature is structural across the tiers and the organic architecture didn't have this in mind.
Agile trainers would say that in Scrum you do more planning than waterfall. Waterfall you control the plan, in Agile you're always making a new one up. It is finding the time to breathe in Agile - you can't just have 200 people start coding next week. Esp if there are "big" architectural questions that haven't even made it to the drawing board - somehow you need to turn "hey - that's a good idea would should do it" into something that people can understand.
Best advice - define what "always shippable code" means to you. And do it. Every feature needs to track usage? Or be scalable? or be secure? or....? This is your Definition of Done for a story and your "control."
Of course not every good idea gets done. There's always next time.