Not all non-deliverables cause frustration. For instance, I enjoy writing unit tests because I see the great benefit they bring to the end product. Most up front documentation is useless, and the useful parts end up buried amidst the unnecessary bits.

The only documentation our QA create before testing are their test scripts, and since they see the benefits from these in the immediate future, they don't consider it painful (or if they do, I don't hear about it, and I'm pretty close with our QA). All project planning is done together- QA and devs identify tasks together at the beginning of each iteration,

The truth is, documentation usually serves as a false sense of security (someone can pick up where you left off), a contract to bind customers (I don't care if you don't like the way that button works- you signed this document saying it's what you wanted and clearly you have the ability to envision how a feature will work in your mind), or a metric for achieving marketable buzzwords/certifications (CMM). Creating documentation that is never read by anyone and never impacts anyone positively in their ability to help deliver a product is tiresome when your mind knows you can actually be doing something useful- or it is to me. Fortunately, I don't have to write much documentation on my current project (and when I do, it's generally useful so I enjoy it). What drives me nuts is the time our project managers requires from our TAs before each sprint to do design work. They never get to code because they are figuring out stuff they should be able to trust us peon developers to do. Once you've put together a database table create statement to illustrate the fields I'm going to need, just run the thing- don't send it to me in a document. If you can't trust your developers to do they everyday design work, get new developers.