At a first look, Agile development and Domain-Specific Modeling share many things in common, yet are in conflict on some central points. The popularity of both is in some ways a reaction against fixed tools, languages and processes like UML and RUP, and both eschew writing reams of documentation and models that don't contribute to the actual implemented product. But isn't the whole idea of Agile to avoid limiting the creativity of developers with tools and modeling languages, and the whole idea of DSM to narrow down development possibilities with tools and modeling languages?
Below I'll go through and comment the Principles from the Agile Manifesto - whilst Agile means different things to different people, these are a good selection of common themes. For the sake of brevity, I won't explain DSM here - see the DSM Forum's Why and How links - nor justify its 500%-1000% improvements in productivity - see here. (That link, like a couple of others below, is from my company's web site: sorry for the plug, it just happens to say what I want.)
Having written the comments, I feel less than satisfied with the principles and the comments: these things are hard to pin down, and easy to misunderstand when pinned down by the process of trying to write a concise description. Perhaps face-to-face communication (one of the principles) would help - let's hope there's plenty of that at the workshop!
Who could disagree with the first part? Whether early and continuous delivery is appropriate does vary, though. The first increment would generally happen around the same time with DSM as without, because of the initial effort of creating the DSM language and generators. After that, DSM will be delivering higher value more rapidly.
This is a strong point of DSM: it is much less brittle with respect to changes. Normal code always has function names etc. copied several times throughout the code, so changes must always be made to each place. With DSM, there will be one element representing that name etc., and the generator will use that one element in all the appropriate places: change it once in the model, and it will be changed in all the places it is used.
On a larger scale of granularity, projects often make assumptions about things such as target platform, language etc. If at a late stage of the project one of these assumptions changes, the results are often catastrophic. With DSM, the models will describe the system, not its implementation. If the language and platform change, the models will often stay the same, or require only minor changes. Moving the whole system to a new language and platform requires only a new generator - a non-trivial amount of work, but much less than everybody having to rewrite all their code.
More about change and DSM here.
The main constraining factor in these timescales is development time, thus DSM allows significant improvements.
An interesting assumption behind agile development: the customers and/or end users are "business people". Perhaps a better way to express this is that there should be frequent meetings of stakeholders. DSM is often used to build product families, and in these cases the product end user will have less direct input.
Unsurprisingly, I believe DSM is the best possible environment and support (more on this here). It allows the developers to build the system they need, and rules out most classes of broken system that could be built by hand-coding. In line with the items above about change, the environment and support needed is something that may change, so the DSM toolset must support changes during the project.
Face-to-face conveying of information is not always the most efficient or effective method of communication. If it were, I doubt we'd have various written, audio and visual media. But certainly one of the least efficient forms of communication known to man is the hundred page Word document that nobody ever reads. With DSM, instead of writing such specs documents then coding, the specs are expressed naturally in the models, readable by all stakeholders. And the resulting code is always 100% in sync with the specs.
Obviously a good point for DSM because of its higher productivity.
So often I hear from people that DSM would be the right way for their project, but they just don't have the time to get started, as they are under such pressure to get the next release out of the door. DSM is certainly sustainable development: our earliest projects are now approaching their tenth anniversary and still going strong.
I would imagine these would enhance any positive abstract noun you choose! In DSM, technical excellence is embedded in the language design and the generators: an expert developer makes them, allowing all developers to share that expertise. The rules and constraints in the DSM language guide the developers towards good design.
DSM removes the maximum amount of unnecessary effort: code repetition, patterns, product family commonalities etc. are all taken care of with zero effort from the developer. Anything that can be removed from the developers work should be removed, up to the point of zero return, where the effort to automate is greater than the benefit of automation.
I'd say that very much depends on who is in your team. But if I read is as a statement of fact, rather than guidance to always use self-organizing teams, it does agree with my experience. Perhaps I would rephrase to say that the best teams are a) self-organizing and b) produce the best architectures, requirements and designs.
Absolutely vital, up to the point of zero returns, where introspection takes over from implementation. With respect to DSM this is a clear call to make sure that the DSM language in particular evolves with the domain and the team's understanding of the domain.