Agile, SCRUM and Technical Writing

[Peter Neilson]

Lemme try to think through what might be going on here. We can divide 
software projects up into various binary categories:

1(a/b). Have (or do not have) a good insight on a product and a good team.
2(a/b). Perform (or do not perform) early documentation of plans and 
designs.
3(a/b). Produce (or do not produce) a successful product.

1b rarely leads to 3a, I'm sure, regardless of what is done with 2. 
Including a large number of badly conceived projects in a study will 
indeed show that documentation efforts do not help. "You can't wash 
sh*t," as a fellow TW once said.

So a proper study on the effectiveness of early documentation should 
focus mostly on projects that were started by experienced and/or 
cohesive teams working towards a reasonably well understood goal. But 
how would one select those, the "1a" subgroup, from the entire 1a+1b? 
How could one tell which is which?

The only way that I could imagine is by reading the planning and process 
documents. Those are hard to come by for successful projects, because 
they are generally proprietary. For failed projects they (if any) are 
either going to be pieces of crap that are part of the failure, or 
after-the-fact memoranda that show why someone else was to blame for the 
failure. Once in a while they might be gold that was set aside in a vain 
attempt to use the precious dross.

What have I come up with? Am I right, or am I instead all out of focus, 
or involved in petitio principii, or perhaps merely echoing someone 
else's much more erudite and well constructed research?