I have had the good fortune of managing Agile (scrum) implementations at a number of different companies over the years. I have had some great success and some implementations that were not so great. While not unique, my experience is such that I have enough data points to start seeing patterns, especially patterns of failure. That is, while I cannot confidently tell you what will most certainly work in your particular situation, I am eminently qualified to tell you what will not work.
In all my failures there is one common theme (one that is borne out by studies), but before I unveil the theme, it is important to understand what one means by Agile since labelling something as a failure implies one knows what consititutes success. While it can certainly be debated, for the pupose of this blog I choose to define success as the ability to quickly and frequently deliver quality functionality to our customers. Perhaps the best way to measure this is by asking at the end of an iteration or sprint if the team has produced quality code that could be delivered into production (though it might not be released due to many factors). In other words, at the end of your two week sprint did you deliver code that could be put into production?
With that as a backdrop, those who do well at Agile can and do deliver production-ready code at the end of an iteration, those who do poorly cannot and do not. The inability to do so is merely a symptom, but if your organization truly wants to adopt agile, then your first, second, third and final priority should be to provide your teams with the people, software, hardware, expertise, time, etc. that are necessary in order to do this. In other words, your team needs to have a code repository, continuous integration, automated testing (unit, regression, functional, integration,security, acceptance), continuous builds, automated deployment, etc. If you are not aware of these things, no problem, buy a few copies of the book Continuous Delivery: Reliable Software Releases Through Build, Test and Deployment Automation.
While doing the above might not make you completely Agile, if you do not do the above I guarantee that you will never become agile. I believe that when people complain that they are not getting the support that they need from upper management, what they really mean is that upper management does not have the sotmach to make the investment in making agile successful. A large part of that investment is understanding the criticality of being able to continuously deliver and making sure that the work necessary is done.