The intersection space in that Venn diagram is generally anotated as "$$$".

The difference I was trying to highlight is that UML (at least in my experience) was still very much focused on "big design up front" and production of design artifacts (vast numbers of diagrams) that agile and TDD approaches explicitly rejected.

I don't remember rapid iteration being a part of any UML-based methodology that I ever used. By the time the diagrams were complete enough to capture implementation details, they were too unwieldy. Did any UML tools support common refactorings, or would you have to manually change potentially dozens of affected diagrams?

But that's the point - how are the same group recommending massive complex paper designs up front, and also agile methodology?

Opinions and ideologies change over time, here's an hypothetical timeline that explain your question

===A====B==C=======>

A: (around 1997) We are hopeful that the methodology called UML will solve the software engineering problem.

B: We have tried that UML methodology and it doesn't solve the problem it said it would. We should try something else

C: (Feburary 2001) We have an ideology based on what we have found to solve the problem in practice, let's make a manifesto.

Maybe I'm cynical, but it seems like these people are in a farcical cycle of repeatedly inventing some new master theory of programming only to find it's actually a disaster a few years later and then to switch to something apparently diametrically opposed.

Of course, they have a book on sale to explain the new idea...

How much time was wasted and how many projects were damaged by the bad idea of UML and design up-front that they were pushing as hard as they could less than two decades ago? How many developers are being stressed by endless manic sprinting and micro-managing processes under the name of Agile?

Maybe they should stop? Or apply some actual science? Some of this in-group call themselves scientists but all they do is pontificate. I'm not really sure many of them spend much time actually programming.