Agility and Low Documentation Coupling 
Agile developers strive to produce value through working software, which is widely agreed upon as the primary metric of productivity. The cycle time to produce a unit of working software, gain feedback from the user, inspect the results, and produce another unit of working software is what makes the agile developer tick. Agile teams love to write working software, but they do not love to write documentation. Documentation (of any sort), in my experience, is often deemed as something secondary that should only be moving the iteration of work towards producing another working unit of software. Business constituents love working software but they also love to communicate business processes effectively. Being guided by agile values and principles does not grant license to ignore all that is not source code.
It is important to note that there is a difference between business-centric documentation and technical documentation. Business users generally do not care about UML class diagrams but they do care about user stories or perhaps use cases described in textual and/or graphical formats. It is this type of documentation that any self-respecting agile developer should be happy to collaborate on with business users, as well as assist in evolving as shared understanding grows about the business process that is being supported through software. Artifacts such as use cases, user stories and business process maps, when kept alive, can be extremely helpful to any organization in terms of process improvement. When a developer needs to understand the intricacies of the system, well-crafted unit tests (preferably created through TDD) can serve as much better technical documentation than various UML diagrams.
The need for business-centric documentation is being championed by many through pragmatic tools such as FIT (
http://fit.c2.com). An increasingly popular topic is that of "executable documentation" and how business requirements can be actively linked to working software. David Hussman has been doing a great job of preaching that sermon on the No Fluff Just Stuff tour (
http://www.nofluffjuststuff.com/speaker_topic_view.jsp?topicId=534).
All this being said, I feel it is increasingly important to focus on reducing coupling between business documentation and technical documentation. If a technical change forces cascading changes through many uses cases or user stories then it is possible that these artifacts may be focusing on the wrong thing. If a change in business process causes inaccuracies in a multitude of technical UML diagrams then it could indicate that implementation (technical) documentation and abstract problem (business documentation) are tightly coupled.
Agile development should deliver working software that addresses the right problems as well as facilitate effective communication about those problems. When an agile team is asked to explain or improve the business processes and functions of their software they will be happy to have timely documentation to fuel that effort.
