In his talk at Domain Driven Design Europe 2016, Paul Rayner made the case for incorporating domain-driven design (DDD) into the agile software delivery process. He views agile as a way of organizing work, not as prescribing how to do the work. He believes agile practitioners often don't pay enough attention to design, and promotes DDD concepts as a way of addressing these failings. Going further, Rayner believes that combining agile with DDD can accelerate product delivery.
In Rayner's experience as a consultant, he has seen many teams doing agile who stress the importance of MVP (minimum viable product) to the detriment of design. He quoted Douglas Martin on the inevitability of design: "The alternative to good design is bad design, not no design at all." In trying to avoid waterfall's "big design up front" and do the minimal work needed, these teams end up with bad design. The Agile Manifesto actually says "Continuous attention to technical excellence and good design enhances agility". The purpose of agile is not speed and only speed, but agility. Agility can be achieved through good design. It is in fact the purpose of design according to another quote Rayner offered up from Venkat Subramaniam: "A good design is not the one that correctly predicts the future, it's one that makes adapting to the future affordable."
He pointed out that design is fundamentally iterative, and as such, can be incorporated easily into agile. Design is a process of discovering what you don't know and expressing complex ideas simply. Since you never know all the facts up front, your design will necessarily change over time. Taking the time to do the discovery, and to express new knowledge in the delivered code will pay dividends in time saved later, as the code itself will be more agile. One method for doing this is the whirlpool process of model exploration, in which you iterate between challenging your existing model of the domain with a new scenario, proposing a new model, and writing the code to implement it.
Rayner also listed other ways agile teams he has worked with often fail from a DDD perspective. One is viewing continuous refactoring to a good design as good enough. This may clean up the code, but DDD emphasizes introducing new concepts. These new concepts are not emergent from the code, and therefore cannot be created solely through refactoring, but rather are concepts modeled from the business. Which adds business value, whereas refactoring, by definition, does not change the functionality of the software.
Having a defined "product owner" role in Scrum can easily cause others on the team to view that person as the sole conduit for all business needs/knowledge, noted Rayner. DDD advocates that everyone know the domain. This is where the complexity lies, not in the technical aspects of the problem. So in order to achieve a good design, thereby increasing agility and business value, everyone on the delivery team needs to know the domain.