1) UML is documentation. Quibble about inputs or formalization ... whatever, it's documentation 2) No organization pays for proper documentation. In waterfall

1) UML is documentation. Quibble about inputs or formalization ... whatever, it's documentation 2) No organization pays for proper documentation. In waterfall requirements gathering always consumed 90% of the budget, then the next 90% was development, then the final 90% was QA. Then the release-beta-and-fix later. Agile may help a bit with communication of undocumented requirements and undocumented functionality fixing and maintenance, but it's not much. To underline, companies don't pay for documentation, the documentation they DO generate in the BA -> programmer -> QA is vastly inferior to what's needed typically without extensive communication. Related: this is why outsourcing doesn't work well except in certain situations. 3) Therefore, every developer and every business analyst and every QA person, since they aren't paid for good docs, will avoid it. If an imposed software dev process is imposed by the gods of architecture, it will be resisted outright or by innumerable subtle ways (good people quit, make minimal (bad) docs but check the delivery list, etc). 4) what remains is point-to-point verbal and informal comms, and (actually high value meetings), which are very efficient but very very hard to capture into formal documentation. How many times is a ticket in various ticket tracking have its high value data in the COMMENTS on the ticket, and the body of the ticket is worthless? Overall I'd say it was over 50% of tickets were like that. Honestly, probably more like 80% for difficult tickets, and AT LEAST that captured the dialogue/information in some way, as opposed to Slack and meeting minutes. 5) UML also implies waterfall and "requirements are ready, finalized, and set in stone". I'm sure some UML zealot would disagree, but it does. But there are vanishingly small number of projects like that. What Agile does get right is an acceptance that software is a convergent evolutionary process / dialogue between business, business analysts, and developers. Notice the three tiers there, there are TWO levels of miscommunication, so Agile essentially accepts this while UML pretends it doesn't exist. QA is likely a third one, but they are the lowest on the totem pole.