Agilists have rediscovered the concept of literate programming, of writing high-quality, easy-to-understand source code that contains embedded documentation. Furthermore, teams that take a behavior-driven design (BDD) approach consider their test suites to be executable, detailed documentation. Agile acceptance test suites forms a significant portion of the requirements documentation and developer test suites the design documentation. We follow AM's Single Source Information practice by having our tests do double-duty as specifications and therefore we require significantly less external documentation.
The "documentation is in the source code" philosophy covers the vast majority of technical documentation, but system overviews will still be required as will documentation for non-development staff. Andreas Rueping's book Agile Documentation: A Pattern Guide to Producing Lightweight Documents for Software Projects (John Wiley and Sons, 2003) defines a wonderful pattern language for improving the efforts of technical writers. Good documentation is conciseit overviews critical information such as design decisions and typically provides visual "roadmaps" showing the high-level relationships between things. Agilists focus on this style of documentation, and only write detailed documentation when it is needed and no better alternative exists.
Agile software developers travel as light as we possibly can, creating just enough documentation for the situation at hand in a just-in-time (JIT) manner. We believe that the benefit of having documentation must be greater than its total cost of ownership (TCO), that our stakeholders should decide whether to invest their money in it, and that we should strive to maximize the return on investment (ROI). Agilists are really smart about the way we write system, user, operations, and support documentation and as a result we tend to write significantly less documentation than our traditionalist colleagues. If you're interested in learning more about agile strategies for writing documentation, I highly suggest www.agilemodeling.com/essays/agileDocumentation.htm.