I don´t see any contradiction between MDD and agile. In fact, I´ll be talking at the Agile Tour in Nantes about the many ways agile and modeling/MDD can benefit from each other (once I have the presentation ready I´ll posted it here but that´s going to be in October).
Why do you think modeling is not agile? Do you think they are not or that they cannot be agile?
excuse me Jordi, my post title its tricky ;) , i think they are agile, but if you look for example in http://en.wikipedia.org/wiki/Agile_software_development http://www.agile-spain.com/
or similar webs, you wont see many references to mdd (maybe someone) or code generation (you will see no one), i would like to change this and it was the key to this post. I want to put mdd and code generation in their place in the agile movement...
Agile is rooted in the challenges we have with specifying software systems. Rather than putting too much effort into specification the idea is to build the real thing and get user feedback. It is all about getting something the user can really evaluate. What some coders miss is that code is also a model and not guaranteed to be the most efficient one. Other types of models have the potential to be superior to text but tool support is really not yet adequate for mainstream developers. Developers that get the tools in place to support higher levels of abstraction will out-produce those who stick with good old textual models (source code). Until that becomes mainstream, the Agile community will stick with textual models because the developers know how to transform textual models into the real product.
It is possible that more abstract models will solve also the problem of specification. If we could could present the customer with a model that is accurate and understandable then perhaps it won't be as important to build the real thing in order to get approval (still have to do that part to get paid :)). But MDD is currently about building the real thing more quickly based automatic code generation from a more accurate and understandable, but not exactly perfect, specification. In that sense, MDD is very much aligned with Agile development. When creating that specification and converting it to a real product takes significantly less time than doing the same with source code MDD will be all anyone uses.
this is an overdue question and I agree with you and Dan.
Though actually practising "agile" ourselves, I disagree with certain (advocating) opinions. Three years ago, in a technical speech I gave in the context of modelling, I referred to object oriented principles, then a developer (!) stood up and asked harshly, whether I haven't heard that object orientation failed and is dead now and whether I don't know about agile practices. For the moment, that left me speechless.
While there is some truth in this rivalry between agile/modelling it is clearly a matter of "throwing out the baby with the bath-water", too. The truth behind it is BDUF (http://c2.com/cgi/wiki?BigDesignUpFront), a term, wiki-word and anti-pattern coined in the context of XP/agile in it's early days. And of course, BDUFs in that sense are "evil", "Schrankware", best-case of no use, worst-case burning time and money.
More elaborated thoughts followed, see e.g. http://c2.com/cgi/wiki?WhatIsSoftwareDesign, but the "agile movement" more or less came to the conclusion and basically still sticks to it, that "design == code == something like textual 3GL source code". The basic idea of eradicating all redundancies between specs/design/model/source/docs in favour of one single lively source is a good one, whereas the question remains where this source shall reside. And - to be honest - todays MDSD models still now and then share this "Schrankware" fate.
So, just from this perspective, it seems a technical matter of finding the best fitting way(s) of expressing a software system, and the rivalry should be (and is) resolvable.
But there is another non-technical aspect: practising MDSD means new concepts, new tools, new dependencies, probably a paradigm shift - that provokes fear and refusal. Unfortunately the agile position can be misused as a protection against such change: all strategic planning, all complexity, all foresighted modelling can be easily put in that "evil BDUF box", and it is often more convenient to put problems aside and stick to little steps ("we can refactor that later").
Of course, thanks to marketing, that strong agile position is very effectively watered down, today everything is selled as a little bit agile, MDSD amongst it.
I think it is a good thing to support that convergence of agile and MDSD in a constructive way - prospects are bright, in my opinion.
micuentadecasa posted it already, as far as I got it it's not his opinion, that MDD isn't agile and infact, it is. Another fellow ahead said, that coding is in another point of view modeling as well, and mostly coding via modeling and MDD ist more efficient. Yes, I do think so for myself. But on the other side in agile projects you rarely will find models beside code representation. In my experience the argument of agile development is often used to omit some modeling in analysis and design, even to omit analysis and desing. They have an idea, sprint into coding the idea and deliver some - whatever - code artifact at the end of the sprint. Yes, they are fast, extreme agile, always deliver some product and anybody says "wow". But as far as I have learned, the code isn't in better shape (quality), on the contrary, it is mostly pretty poor. So, combining MDD into agile development is the better way - that's the bible, the reality is something else.