Well, I would not consider hiding dysfunction a good thing. Successful waterfall tends to meet the schedule and budget and fail at providing what the customer actually wanted because customers generally don't know or can't describe what they really want until the see it.
But, setting that aside. Waterfall is fragile to change. Agile is resilient to change but will expose a lack of discipline in other areas. But, there are two fundamentals that change that fragility to resilience. The first is that short iterations exposes problems quickly. Second, that continuous improvement is embraced to correct the top problems exposed every iteration. So, "fail fast" and correct the problem. Pretty much every other practice involves ways to fail faster or correct typical failures. And, some may not work within your organization, if it doesn't you find out quickly and try something else.
This is a huge weakness of the waterfall process. It typically takes a long time to get through the whole process 6 months to years. So, you can't tell if you got the requirements phase right until quite a long time after going through that phase and you don't get to correct it until the next project and assuming there is a correction it is often more process for the sake of process.
In an Agile iteration you cycle through a significant chunk of the process, and try to do a production deployment of something in as few iterations as possible to expose all the problems. And, especially when switching an existing application development to an Agile process, you are not going to get everything into the iteration all at once. Make sure you are honest and accept that you don't have fully automated end to end integration test, yet and set aside an iteration to do that and correct any problems before deploying.
I will tell you a little secret. Every time my group has made a significant change towards being more "Agile" we have generally had some fairly significant problems in the first sprint. What some might even call a failed sprint. But, we take our hits and figure out what needs to be fixed and the second sprint is generally successful, and 3 and 4 are better and better.
One could argue that waterfall is good at the extremes. Perfect organizations where everything it locked down which makes the process work, and horrible organizations where the process rigidity provides the discipline that would not otherwise exist. Agile works better in that space in the middle where people are generally good and trying to do the right thing, and you just need a framework for discovery. Whether that discovery is of the customer's real needs or internal development problems or whatever...