My friend Jim says, “Have to say, if I were a customer I would stipulate that you left me documentation. I wouldn’t buy services from a company that didn’t ;-)”
One of the responsibilities of an Agile Coach (or perhaps this the role of a ‘Business Coach’ or ‘Client Principal’ – but a role isn’t the same as a person) is to find out what it is that the customer really wants. In the example I gave, it’s maintainability, not documentation. If documentation is the only way to provide maintainability – for instance, if the customer hasn’t been able to provide any in-house staff for pairing on the project – I might suggest writing it in the weeks before handover, so that it’s accurate and up-to-date. There’s no point doing this as you go along in Agile, because you know that the customer requirements, the application and therefore any processes / documentation are subject to rapid and frequent change. A pragmatist might document the more stable aspects of the project, such as architecture or persistence mechanisms, but even they’ve changed during the lifecycle of the project I’m on.
Another reason why customers like to see documentation is because it gives them some idea of how the project is going. Agile development provides other ways of measuring this. Most particularly, the customer can see progress in the number of stories (requirements) implemented, and by sitting down and playing with their new toy as it evolves.
Some projects may not be suitable for Agile development (mission critical?). Even so, I bet my lunch that there are still Agile practices which can improve the quality and speed of code production.
When someone wants something that doesn’t make sense to me, I usually ask, “Why?” Sometimes it helps that person clarify what they really mean, and sometimes I learn something new from the answer. It’s always a fun question to ask, and often the most important one.