It is great to see people approaching the Pipeline model, but of course the more people adopt it the more we need to go deep into the products we use to get the very best value for us.
An example of this is when you start getting comfortable with pipelines. If you get too comfortable too soon, it is because your pipeline looks like this:
I am not saying it is wrong. There are countless situations where you want or need to keep it that way. What I want to stress is that it isn’t the only way to shape the pipeline!
For example, let’s say you are facing performance issues while deploying because of some reason, or you want to do something else (like initialise the database with real data while deploying your PaaS application, running certain tests while deploying other non-core components of your application, examples are countless here really) – can you do that?
The answer is a strong and definite yes.
Let’s say you want to do this:
“QA – deploy DB” happens first, and then I would like to execute “QA – initialise DB” and “QA – deploy app” in parallel. How? With a proper management of triggers in Visual Studio Release Management 
The first environment is automatically triggered by a build, what is interesting is that you can set more than one environment to be triggered by another successful deployment:
Also, you can set an environment to be triggered by all of the previous environments:
So you aren’t forced to use a Niagara Falls pipeline, but something more akin to the estuary of a river