Add Some Empirical, Add Some Transparency, Uphold the Quality . . . What Do You Have?
A thing I learnt today in the ScrumMaster certification course was that Waterfall is good . . . . when you are using it to control a defined process for predictable software development (maybe an oxymoron). A very rare state and situation to find yourself. Rather professionals in our trade find themselves in the situation where they fool themselves into thinking that they have a situation where they know what is going to happen with 100% certainty, but really they do not.
What to use in those situations? An empirical process like Scrum instead. One where you can closely monitor what is happening through the life of the project. This by itself is not that valuable, at least not for anyone but the team that are doing the monitoring. What you also need is transparency for the product owner. Do not attempt to assume the risk that belongs to the product owner. Rather provide a clear view of the decisions that they need to make and the affect of those decisions, and then let them make it.
What do I mean by risk? If there is a situation where project slippage is occurring, rather than try and mask that in some way, be open with the product owner and make them aware of the situation, and let them make the determination on how to move forward.
How would we be able to mask it? Well, reducing the quality of the delivered code is the usual suspect. Okay, we need to deliver a higher velocity so lets stop performing code reviews so that we can take more time to implement more features. 
Wouldn’t the product owner realize this is happening? Only if the ScrumMaster was able to ensure that the team did not go against the definition of done that they gave to the product owner at the start of the sprint.
What if the Product Owner forced the quality change? Once again, the ScrumMaster is responsible for upholding the tennants agreed to at the start of the Scrum and trying their best to stop this in its tracks. Allowing this to continue for any amount of time will mean that software problems may slip through and get exposed by the customer. There is no good time to try and add quality back to a product and always pressure to deliver features more frequently. I think Ken described it as the product Death Watch.
