One gets easily the impression that waterfall-style or agile projects are something completely different and cannot be managed out of the same portfolio.
This is not necessarily the case. The main difference between the two from a portfolio perspective is that in a waterfall environment the scope is more or less fixed whereas the timelines and costs are more flexible to a certain extend. On the other hand, agile projects do have cost and time limits that are given but the scope is not 100% set. Quality for both approaches is however never a question and needs to be applied, especially in regulated environments.
Other attributes are in common as well, for example both have a start and an end, called the project initiation and the project closure, where the activities for both are the same.
If we only look at the project phases and not the project team, then a waterfall project can be considered as an agile one but with only one iteration or sprint. The process below gives an overview. The agile activities are marked in red; the other activities are applicable for both types of projects.

The process above also shows that we have more activities and tasks in the agile process, which means that we need to carefully estimate in which direction we want to go and if a waterfall project would not be the better (and leaner) option.
In a waterfall project, one big release is planned and developed. It all ends in a final step where the deliverables are implemented in the organization and the project sponsor is signing the acceptance report.
If the scope could not be defined at the beginning or it makes sense to release the deliverables in shorter time, then an agile project is a very good approach.
A good way to evaluate to go agile or not is the so-called Stacey Matrix, which is basing on two parameters; the project scope and the technology.

If the Technology that is going to be used is known and for a certain time on the market then we can get the needed knowledge for our project either within organization or it is available on the market. Also the quality of the underlying technology improved over the years. The result is a more stable environment where we have the knowledge to manage it well. This increases the predictability of the project. On the other side, if the technology is brand new, we are missing these aspects of knowing how to use it and the quality is rather lower than of a well-established product.
The second parameter is the project scope. Here it is quite obvious that if it is well defined and aligned with the stakeholder, the number of change requests will be lower which increases the predictability of the project. As a matter of fact, scope changes are the worst threat of a project and the more you can reduce these changes the smoother the project will be executed. If this alignment is missing, then going agile is the best way (if you don't have the option to not start the project). In my opinion the project scope is even to be rated higher than the technology. The missing knowledge can be overcome by learning how to use the tools or technology. The missing alignment of the project scope can only be re-established by negotiating with the stakeholder and from my experience this is much harder than getting familiar with new technologies.
This is why the project initiation phase is so important in the project lifecycle. The understanding of the as-is state, the identification of the relevant customers (if not done correctly you will have difficulties in the scope alignment), the definition of the benefits and the corresponding KPIs is paramount for creating the project charter and the decision to go agile or not.
From a portfolio perspective waterfall and agile projects are no contradiction at all. They are just a different approaches to handle risk and uncertainty.