I was once attached to a group doing an early flavor of CAD in the Cloud. I was THE documentation person for a dozen or so developers. I was writing the HELP as a series of JSPs, with just emacs as the authoring tool. I never got any notice of what had changed, I just saw some of the new stuff, which was fluid to say the least. Once, I was told, "Just look at the program," to see what had changed. Really, a dozen programmers changing everything and I had no notes at all? And at every single meeting I heard the twin refrain, "Don't change the docs, we have to localize it," and "The docs really s_ck." Which statement was true and what should I have done about it?
The kicker was that as a favor to users (as expected, the product was real bear to use), I created a cheatsheet in the form of an index. This was an alphabetical listing of the commands and each entry had a short explanation of what each command did and a showed a command stream with the most common options. All the command streams were cut-and-paste from an "approved" manual. This index sat on a boss's desk for about three or four revision cycles. If you count the number of real revisions, you have the first pass and then the second pass to "fix" bugs created by the first pre-release. QA was so backed up checking releases that they had not reviewed the docs in MONTHS.
Anyway, when the boss finally looked at the index, all the COPIED command streams were somehow wrong. How do you carefully explain that fictional docs are really hard to create? So now, the problems with unreviewed docs based on amorphous code become MY problem. The product died soon thereafter, but as the doc person I was blamed for poor work habits and being uncooperative.
It is worth noting that not a single email, note or conversation was ever held to tell me what changes had been made. Both QA and development kept me isolated. And I was uninvited from all meetings. Yup, QA did not look at the docs for months, the developers issued about 8 total rewrites of the code, I was struggling to document just the new stuff I was told about (yes, the pre-release flavor was always different for every single "new" part of the code). In reality, I created a draft flavor for each feature, reviewed the changes made since the developer did the first show-and-tell (round 2 or of corrections), and then I would fix the docs after the developer made more fixes. And this was just for the stuff they TOLD me about.
Please keep me out the loop forever when the code is agile. Agile means no one ever tells what they have changed