It is even more difficult to realize this when you are also, in part, documenting some of the right things. The fact that you can later go back and grab the manual and find that important but obscure setting configuration when the mail server has imploded and you get it back on line before anyone notices can seem to make the whole effort worthwhile. The chaff is justified by the wheat. You tell yourself that you didn't know ahead of time what it was that was going to be important, so you wrote it all down and had what you needed and a little more when it counted.
But I am increasingly skeptical about those justifications, and in the realm of agility, it seems even more important to avoid doing anything that isn't absolutely necessary in the first place. CMDBs, improved logging features, and other methods of automatically harvesting configurations and settings have reduced or eliminated much of what I use to insist on documenting manually, but I still struggle with what is appropriate to put into a document and what can be reasonably expected to be inferred from the shape and function of the final product.
Into this internalized debate, a single sentence of McGovern's helps crystallize the perspective:
I am of the belief that documentation should explain decisions taken and not taken.
And that's it, really. As long as I have kept things simple, produced systems that are otherwise easily understood and self-documenting, it's really the decisions that lead to the implementations that I need to write down. Malik calls his version of this a "Technical Policy and Advice Document" and describes it as a document that "...includes both a business decision and a technical approach for executing it."
I may need to use this in practice for a while before I fully understand all the implications, but I am posting this as a reminder to myself to do so.