I think it's a myth that Agile project teams don't document their applications and this is the first point of resistance you get in companies that are certified to have the best documentation as per their standards.
I work in an ISO-9001 certified company, but we ALSO do Scrums on a large number of our projects. In our case, the change came in from the Project Delivery heads (i.e. quite senior folks) and that's why it gets adopted - as opposed to a Project Manager or Developer trying to push in this change.
One useful practice we follow is Document Enough but Continuously . This obviously means we do not follow all the templates prescribed for the project, but there is a conscious understanding and agreement over which sections/documents are needed vs those that are just pointless overheads.
You'd then need to socialize this point of view and get the approval of the Quality group or Standards division or whatever it's called.
The Agile principle is 'just enough' documentation. Can you try and push it from the Customer to express to the team how much is just enough? The project manager could talk to the customer and understand what their expectations and organizational needs are and then both document the decision and meet those expectations. If it's good enough for them (i.e. the paying customers), then it can be what you follow.
If they think Agile doesn't scale up to large projects, convince them it can - by decomposition and parallel effort.
In large organization, control and oversight for large programs are accomplished by running a Project Monitoring Offices (PMOs) that conduct conventional planning for costing/accounting/resource management etc - hence they demand a lot of documentation, but they can monitor progress using Agile practices (the SCRUM burn-down chart for one). They need to know how techniques such as continuous integration help them earlier rather than later, and hence it's better for everyone's productivity to get overhead docs out of the way.
Agile is a set of skills that a team can learn which is largely orthogonal to our traditional technical skills. But if you add this to their existing skills, of course you can become a more effective team. Daily standups (i.e. Scrum meetings) are not going to be possible overnight - but you would have regular team meetings (say bi-weekly) at present? I'd say start by converting those into following the Scrum question agenda (not too sneakily ;) and convey to the wider team why this approach can work and does not mean lax documentation / poor standards or whatever other myths.
