If I were re-writing the Agile Manifesto and I wanted to express agile values in terms that spoke positively to the project manager's realm, rather than defining agile in opposition to it, I'd state the third value ("Working Software over Comprehensive Documentation") like this: The best documentation is the product itself.
How did I get here? We had a fantastic yesterday, delivering our Agile Project Management workshop to 13 quite knowledgeable individuals from all sorts of backgrounds. When the group is this experienced, we always learn as much as they do, and one of my "ahas" came when Lisa Winter expressed a pain point PMPs often experience during agile adoptions, especially when the organization is large and long in the tooth:
What do you do when you're caught between the rock and the hard place? ie, you need to run an agile project in an agile manner, but you also need to provide traditional reporting upstream. Do you make like Allen Stanford or the Mafia and keep double books? Or clone yourself and give the waterfall stuff to your evil twin? I hope not!
What Lisa wanted to know was, how can I cut down on this particular form of overhead? Where do agile metrics map to traditional metrics and where don't they?
So how do these things map? Take documentation. A great deal of confusion surrounds the nature of requirements and documentation in Agile, and it’s often put forth—mistakenly—that Agile eschews documentation. While it is true that in Agile development, working software is favored over extensive documentation, this doesn’t mean you don’t document requirements—it means that you and your team document these requirements quite comprehensively indeed at the end of every sprint–but you document them in Ruby, Perl or C++, not English!
This isn't some crazy cowboy agilista indulgence. In fact, there are industries built upon this notion of product as documentation, aka copyright law. And with the recent extension of copyright law to cover software it's no longer mere analogy. The code itself is the sole document on which basis protection is granted–just as the text of The Shining is the only documentation Stephen King produced to obtain his copyright. This is why I think that, while I heartily endorse it's intended meaning, the agile manifesto's implication that comprehensive documentation is frowned upon isn't an entirely accurate statement–what more comprehensive documentation is there, after all, than working software? And if it's proof enough for Uncle Sam, it might need to be proof enough for the VP of Product Development.
But, you say, this isn't documenting requirements exactly, because it comes after the fact. Does it really? Your first working software will be delivered months, possibly years, before a traditional requirements document would have, so maybe the working software really does fulfill the requirements model after all.
Maybe the answer to Lisa's question lies in translating Agile concepts and mapping them to traditional values, if not practices. It might be worthwhile to demonstrate to people who are, quite reasonably, invested in their own histories and bodies of knowledge, that despite radically different approaches, the actual values–quality, timeliness, transparency, value, etc., are the same.
Or am I getting it all wrong by implying that Agile means wrapping your ankle behind your ear to make a point?
Many well-intentioned managers have a fundamental misunderstanding about velocity. They think it is a measure of how hard the scrum team is working or how much they are producing. Neither of these is correct. Velocity is a tool for predictability. 
