Agile Documentation: Is There Clarity?

"Working software over comprehensive documentation.", The Agile Manifesto, 2001.

Agile documentation is not exactly the most clear cut subject in the community?  How much documentation should we create?  What works?  What doesn't?  How do we transform from a traditional process to an agile one with regards to documents?  This is an area that lacks clarity in the agile community.

A recent blog entry on Zen Agile asks the question "How Much Documentation is Enough?". The writer talks about his experience with government agencies and the reasons behind their very document-heavy processes:

It’s been suggested to me that all of this documentation is required “because we’re government”. When probing a little more I’ve generally found the following reasons are given:

1. The business needs comprehensive information to sign-off and approve the build
2. Developers need to know what the system is designed to do
3. Other developers need to know how the system was built in order to do improvements
4. Other developers need to know how the system was built in order to do maintenance
5. The government requires sufficient information in order to know why money was spent and how it was spent

In my experience, however, very few people in the business understand requirements documentation. They tend to read through the project background to make sure the current state and rationale for the project is clearly articulated, they might go through the business process maps because as a graphical depiction of the project it’s easier to understand than a use case. But overall, getting them to sign-off and approve something they’ve not seen is a bit … well … it’s just not logical.

The blog then goes onto report an alternative for documentation that consists of:

1. Articulating the context via personnas, scenarios and context diagrams,
2. describing the requirements with process maps, and tracability matrices,
3. documenting the solution with data models, site maps, navagation design, and UI design,
4. validating the solution via prototypes, signoff happens here, iteratively, and
5. documenting the system build which includes code, testing regime, and physical data model.

This above process has been thought out and comes from experience.  But is it anything close to what we all do in the community? 

There are conversations about stories, use cases, and tests as specification.  But is that all there is?  There is a full book on Agile Documentation that this reporter had never heard of until researching this topic. There is a chapter in a book about evocative and representational docs.  And there is even an InfoQ news article written over 3 years ago on the subject.

Do we have a consensus or even a few cohesive 'schools of thought' when it comes to documentation?  It is really difficult to tell because so little is written on the subject.  Maybe the subject is just too simple to write about.  Or maybe it is too complex and we really don't have a good idea what to recommend.  Thoughts, good reader?