A methodology is DocumentationCompliant when it produces the sort of documentation required by large bureaucratic clients. Some lightweight methodologies are not very DocumentationCompliant, which makes it hard to use said methodology to satisfy such a client.

''Note that this "definition" isn't very useful. Being compliant to a requirement that a process produce documents isn't about the documents -- it's about the ''process'', and ''that'' needs to be compliant. The resulting documents are a product, not a means.''
----
Not impossible though. You might use your methodology to write the specified program, then write the necessary amount of design documentation required by the client, ''from the program''.

Apply this to XP and you almost (but not quite) get reverse waterfall:
	*Analyse
	*Test
	*Code
	*Design
''But keeping in mind that it's not a mirror image, because of the iterative / evolutionary characteristics of XP.''

'''Hmm.''' You ''might'' be able to get the required documents from the code, but prolly not. Many, many times in the last 38 years I have seen clients' engineers try to retrofit a document to a collection of code only to produce a mess that makes references to specific implementations of that code, often lifting variable/entity names right out of the source. What they end up with is a description of how they implemented a particular approach to a particular design, ''not'' a generalized description of the problem and its solution. The original term and its definition is still not useful.
----
CategoryRant