Documentation, it's often a curse word among developers, the Word document you have to put together to satisfy some process or another which you know almost no-one will ever read, that the next person will be unlikely to update (because it's Word, it's too long or both), and will probably be out-of-date after 2 releases or so. But it doesn't have to be that way.
Most open source projects maintain some documentation along with the code base (see Parquet .NET for an example of this), sometimes it's some basic instructions and an overview, others put detailed documentation on there. Others, such as Microsoft, maintain all of their documentation as it's own repository on Github for anyone to modify (following a proper pull request process of course). This is a process which can be adopted inside organisations as well and is made easier if you are using tools which support easy to use documentation tools, like Markdown, such as Github or Visual Studio Team Services.
Using tools like these developers can stick with things they know, such as Markdown and Git and they get to work alongside the code. In my experience this has made it more likely that they will update the documentation as they go. And if you keep the documentation in the same repository as the code base you can even make it part of your peer review process. For the auditors and QA people, they get more relevant documentation, a process for seeing how it's updated and other niceties such as a full history of changes to the documentation, including who made what change and when thanks to the version control system (as opposed to long winded Word document header pages). There are even tools out there which will convert Markdown into Word documents or PDFs if you still need them.
Being Agile isn't just about the code, you can bring other processes like documentation along for the ride as well.