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.
However, it implies that large parts of the applications code are not covered by tests. Why? Because if you have units (and you need a lot of units to get your Unit Tests right) you need code that wires the units together. This code, IMHO, will get complicated enough that it deserves to be tested on a more granular level that integration tests while it probably falls into "Dirty Hybris":
Your assumption is faulty because you are neglecting a layer of testing - acceptance testing.
Your unit tests cover individual units - the classes and methods that compose them. This enables you to test methods and classes in isolation to ensure that they are behaving as expected. Above this lies your integration tests, which tests the collaboration between classes and ensures that larger modules (packages and even inter-package collaboration) work as expected. Finally, your acceptance tests are used to verify and validate your entire system, as assembled, against the user requirements.
Assuming that you have the appropriate unit and integration tests that correspond to requirements and well-defined acceptance criteria and acceptance test plans, then everything in your system is tested. Other aspects of testing - smoke tests, regression tests, and so forth, are simply an appropriate subsampling of the unit, integration, and acceptance tests.
TDD is a robust way of designing software components (“units”) interactively so that their behaviour is specified through unit tests
That particular quote is also missing something. As I was taught, TDD isn't just about unit tests, but developing all tests first. That includes not only unit tests, but the necessary acceptance and integration tests as well.
Best Answer
To be pedantic, nothing in the Agile Manifesto or the Scrum Guide make any reference to technical practices, like unit testing or TDD, at all. So, yes, in theory you could deliver early and often with a focus on collaboration and value without them and call yourself Agile, you might even actually have agility.
In practice however, it's nearly impossible to consistently deliver value (into production) every few weeks without a good test suite. This includes integration tests as well as unit tests. Unit tests only go so far. There's a reason it's s pyramid and not a rectangle after all.
Without the tests as a safety net, you'll either introduce lots of regression bugs in each release, or be terrified of refactoring. Both will greatly impact your ability to continue on at a sustainable pace. If you can't sustain your pace or change course (redesign) when required, then you don't have agility. Agility, after all, is the goal we're striving for.