Perhaps XP and traditional docs would be a better title. This is from a developer who attended RonJeffries's talk and tutorial at the March 20, 2000 San Jose Software Developer's Conference/Expo:

''It was admitted that eXtreme Programming is not designed to get a software house to reach any of the five CMM levels. I still remain very skeptical on the whole methodology. Replacing formal and detailed design documentation with User Stories just ain't right. Question to the panel: "How do you integrate design with UML into the eXtreme Programming methodology?". Panel answer: "Wash your hands after using UML.".''

XP seems to forget the one fundamental advantage of docs - in and out of UML - which is that they give a contractual undertaking to people who can't read source code. There are a very large number of these folks in most middle to large organizations, and they're incapable of satisfaction with a "wash your hands" answer. It just comes across as glib and thoughtless - it's not meant that way, but it's heard that way.

In fact, for many internal customers, UserStories aren't enough (see LimitsOfUserStories). They want things in black and white, damnit. That way, they can file them away and check them without racking their brains. The CMM refrain is, "if it's not written down in English, it's not engineering". CRC be damned. Source be damned. 

So when a team-lead at a former employer, JimColston, bless his heart, sat down and produced a traditional design slab recently, a number of internal customers almost wept with relief. It was the first time they'd seen information that lived in the solution space that seemed contractual. It was like a train schedule to them - hooray! Throw that pesky steering wheel away! The train stops at these stations!

In the ExtremeUnifiedProcess, I've suggested that some UML docs be used when external communication is necessary. But what I'm seeing here makes me think that some extra structure is required to make these kinds of customers feel love. In particular, producing and reviewing at least a collaboration diagram for ''every'' user story before unit tests, and a class diagram generated after refactoring occurs, seem a necessary minimum. -- PeterMerel hoping this heresy can be quashed asap.

----

Maybe I am wrong. But all these papers are important for customers while they don't understand what you are doing. That's why XP involves customer in the process itself. When the user understands the process, he will stop asking papers which give them illusion of protection. Customer asks papers while nothing happens, but when the solution breaks during the middle of the business day, they want a solution, not papers. Papers which describes the problem and solution won't solve problems with idle bank servers. And in most cases all the papers turns against the users and protects the engineering coz they mostly are written by engineering.

''Documentation and Diagrams are also needed to support contracts in the case of disputes or legal matters with the customer. You hope it does not happen but you are definitely in a better position as a vendor if things are not all verbal. Keeps everyone honest if the customer knows things are ambiguous they can take advantage of it and have you working long hours at no extra charge because what you have delivered is just what they asked for but not what they want. PaperTrail is always important and good (signed off on by the customer) diagrams help clarify what the deliverables are. You may or may not want to use UML, but since it has a relatively clear semantics it is not a bad idea. Even internally there is usually enough office politics that you need to be able to back up yourself and your staff if necessary to upper management or other departments. Department X asks for Y, your area delivers Y and they say they wanted Z. If there is documentation signed off on, they can't complain if it can be shown that was what was delivered. Requirements may change but that can be handled in the next iteration, not arguing it is not in the current phase because it was not clear what was needed.''

----
'''XpAndUml QuickQuestions'''

'''Q''' Correct me if wrong. If we have traditional documentation for the user, it becomes easier for him to pass this to other IT practitioners for comment. There are more people fluent with the ins and outs of traditional specs with DataFlowDiagram than UnifiedModelingLanguage. Deliverables produced by methodologies like SSADM have established reputation. See also my questions in ExtremeProgramming. -- DavidLiu

'''A''' Responses?
----
The comments on this page seem to be based on the assumption that UML is useful only for documentation. UML is primarily useful for visualization - which is helpful even if the person drawing the model is also going to be writing the code. Agile approaches to modeling can be found on http://www.agilemodeling.com and http://www.parlezuml.com - where there is a paper on a test-driven approach to analysis and design using UML.