Now, after two similarly sized Agile projects, all I can say is it seems to be an excuse for developers to skip QA/QC procedures "because we're already into the next scrum" and end up with a mess that doesn't come close to matching the original specification at the end blaming changing requirements and "developmental issues" during the scrum process. I just turned down a contract that explicitly required Agile coding because I don't have any confidence that the end user will be satisfied with the results.
It's important to note whatever it is you think you were practicing, that's not actually Agile.
In Agile a task can't be done until it's passed QA. You're not allowed to say "Whoops we're in the next sprint guess we can't do QA hur de hur hur." You have to bring the task into the next sprint, and it's considered a failure in estimation (which then should be dealt with by the group.) You then have to bump something out of the next sprint to fit the extra time to finish QA.
Most of the time people say that Agile sucks, I've found that it's usually because engineering or management is abusing faux-Agile practices to ignore all the safeguards. Here it sounds like engineering was ignoring a Agile safeguard (task wasn't done) to cut corners, possibly aided by management who didn't want to hear about any delays or wanted to make a certain date. The honest truth with process is that a process is as only good as everyone's willingness to follow it.
Agile should really be administered by a neutral party for a team for this reason, someone who's not a member of management for that team (common mistake) or an engineer on that team. That way you avoid engineers closing tasks while breaking the rules.