First, Agile is not a process so it's not directly comparable to Waterfall (which is a specific process). Agile is an umbrella term for a set of concepts (processes, methods, philosophies) some of which can be compared to Waterfall, at least in part.
Second, don't pick a specific process. Develop a process. Select from the broad collection of ideas that go into processes, the components that you want based on their effectiveness or utility.
The key things to decide when developing a process:
Feedback loops or no? If you don't like reality, then don't use feedback loops. For the rest of us, reality is what we live and work in so incorporate feedback loops. Don't use hard boundaries between phases with an assumption the previous work was correct. This means likely pushing for automated, regular testing (verification) and regular "customer" (whatever that means in your context) feedback (validation). Use the results to update plans, designs, requirements, and the system itself.
Small batch or big batch? The larger the work you deliver at once, the higher the risk. Delivery is when you get validation (that you built the right thing). If you have a team of 1k people building out your hot new shit and deliver after 2-3 years, you may find you spent a lot to build the wrong thing. Deliver smaller batches incrementally and you'll get validation (and verification, but critically validation) along the way. This also means you have to rollback less if there's an issue, if you have to roll anything back. Deploy a new validated (right thing) service after 2 years but find out you have a critical design flaw so it doesn't handle more than 1k concurrent users, well you may have to eat the scaling costs or rollback the release and fix the design. Smaller increments, better feedback, lower risk.
BDUF or no? Big design up front means committing (it's a design) to a lot of unknowns. Is the design even going to be relevant when you release? Is the time spent on it worthwhile? If you're delivering in smaller batches you get feedback and can adjust the design, but then why spend so much time designing everything? Design just enough between releases, how much is enough? Judgement. You know your team and market, you figure it out.
Waterfall: No feedback loops, big batch, BDUF. It's basically the highest cost, highest risk approach. It's stupid for any project that's going to last more than 6-12 months. (Any project that length or shorter that's not totally novel is likely to succeed or fail regardless of chosen process.)
Incremental (Classic): Waterfall with 6-12 month increments. Fixes the feedback loop and partially addresses batch size problem. Still has BDUF. Reasonable, but not great because you're still spending a lot of time on the design that could be invalidated.
Spiral (Classic): Incremental without BDUF. Some design and requirements at the start, but mostly done at the start of each increment which is still usually in the 6-12 month (maybe shorter) range. Addresses many of the issues of the above.
V-Model: Waterfall with much stronger emphasis on V&V, permitting some feedback as you go through the V&V portion of the work. Pair this with Incremental or Spiral and you actually have a somewhat reasonable model. Stick to V-Model as Waterfall with better V&V, you still have the big batch risks and BDUF problems.
If you look at the actual ideas in Agile and not just Scrum, you'll see that it ranges from somewhere along Spiral (just enough design and requirements to hit an MVP, evolve that toward your final product using feedback along the way) to the more extreme form of Kanban style where you work and deliver very, very small batches (potentially delivering every small change many times a day).
The big things to take away from every one of the models: Feedback loops reduce risk and increase the chance of success. Small batches reduce risk and increase the chance of success. Design up front, but not BDUF, reduces cost and some risks (that you build the wrong thing because the decision was made before it should have been).
Take those three things and then figure out the specific techniques (wherever they come from) that help you out. TDD is basically the tightest feedback loop you can get for software verification. Is it appropriate for everything? Maybe, maybe not. Things of that nature.
NB: Spiral and the various Agile methodologies and techniques work even in critical and safety systems. In aviation for a new aircraft, building a safety-critical LRU the first deliverable might just be a form and fit check that supplies canned messages over the avionics network (this is used in initial integration testing on the ground). The next deliverables will push toward meeting flight safety requirements for the first flight tests. Then the next series will add capabilities required for certification but not for flight test. The final series will be further "quality of life" refinements that the customer wants, or maybe to work with specific variants for specific carriers or nations.
Second, don't pick a specific process. Develop a process. Select from the broad collection of ideas that go into processes, the components that you want based on their effectiveness or utility.
https://en.wikipedia.org/wiki/Software_development_process
The key things to decide when developing a process:
Feedback loops or no? If you don't like reality, then don't use feedback loops. For the rest of us, reality is what we live and work in so incorporate feedback loops. Don't use hard boundaries between phases with an assumption the previous work was correct. This means likely pushing for automated, regular testing (verification) and regular "customer" (whatever that means in your context) feedback (validation). Use the results to update plans, designs, requirements, and the system itself.
Small batch or big batch? The larger the work you deliver at once, the higher the risk. Delivery is when you get validation (that you built the right thing). If you have a team of 1k people building out your hot new shit and deliver after 2-3 years, you may find you spent a lot to build the wrong thing. Deliver smaller batches incrementally and you'll get validation (and verification, but critically validation) along the way. This also means you have to rollback less if there's an issue, if you have to roll anything back. Deploy a new validated (right thing) service after 2 years but find out you have a critical design flaw so it doesn't handle more than 1k concurrent users, well you may have to eat the scaling costs or rollback the release and fix the design. Smaller increments, better feedback, lower risk.
BDUF or no? Big design up front means committing (it's a design) to a lot of unknowns. Is the design even going to be relevant when you release? Is the time spent on it worthwhile? If you're delivering in smaller batches you get feedback and can adjust the design, but then why spend so much time designing everything? Design just enough between releases, how much is enough? Judgement. You know your team and market, you figure it out.
Waterfall: No feedback loops, big batch, BDUF. It's basically the highest cost, highest risk approach. It's stupid for any project that's going to last more than 6-12 months. (Any project that length or shorter that's not totally novel is likely to succeed or fail regardless of chosen process.)
Incremental (Classic): Waterfall with 6-12 month increments. Fixes the feedback loop and partially addresses batch size problem. Still has BDUF. Reasonable, but not great because you're still spending a lot of time on the design that could be invalidated.
Spiral (Classic): Incremental without BDUF. Some design and requirements at the start, but mostly done at the start of each increment which is still usually in the 6-12 month (maybe shorter) range. Addresses many of the issues of the above.
V-Model: Waterfall with much stronger emphasis on V&V, permitting some feedback as you go through the V&V portion of the work. Pair this with Incremental or Spiral and you actually have a somewhat reasonable model. Stick to V-Model as Waterfall with better V&V, you still have the big batch risks and BDUF problems.
If you look at the actual ideas in Agile and not just Scrum, you'll see that it ranges from somewhere along Spiral (just enough design and requirements to hit an MVP, evolve that toward your final product using feedback along the way) to the more extreme form of Kanban style where you work and deliver very, very small batches (potentially delivering every small change many times a day).
The big things to take away from every one of the models: Feedback loops reduce risk and increase the chance of success. Small batches reduce risk and increase the chance of success. Design up front, but not BDUF, reduces cost and some risks (that you build the wrong thing because the decision was made before it should have been).
Take those three things and then figure out the specific techniques (wherever they come from) that help you out. TDD is basically the tightest feedback loop you can get for software verification. Is it appropriate for everything? Maybe, maybe not. Things of that nature.
NB: Spiral and the various Agile methodologies and techniques work even in critical and safety systems. In aviation for a new aircraft, building a safety-critical LRU the first deliverable might just be a form and fit check that supplies canned messages over the avionics network (this is used in initial integration testing on the ground). The next deliverables will push toward meeting flight safety requirements for the first flight tests. Then the next series will add capabilities required for certification but not for flight test. The final series will be further "quality of life" refinements that the customer wants, or maybe to work with specific variants for specific carriers or nations.
You don't need Waterfall or BDUF for anything.