Development Driven Development (DDD), not to be confused with Domain Driven Design, is a fairly new software development process that’s been gaining a considerable amount of traction in the last few months. While DDD stems from the core lean and agile methodologies, it takes a slightly different approach, which I’ll be summarizing here, to project management than the practices that currently fall under the agile umbrella.
DDD’s sole focus is on the development of software being development. Instead of focusing on the domain, features (FDD), behavior, quick development/test/release cycles, or the customer, focus is placed solely on development. The best way to explain this is via a short example. You have a customer or marketing team saying exactly a, b, and c are required. This is your requirement list. It should be conveyed to the development team very casually, preferably when they are still busy with their current round of DDD. This may sound like it would be highly ineffective, however, it avoids distracting developers (all of which are potentially in the flow/zone) and keeps from providing them with a direction or amount of information that could inhibit creativity.
A core principle of DDD is that other project management and development models entail too much mental overhead to implement successfully. By omitting these overheads the development team is free to quickly and blindly develop whatever is dreamt up on any whim. With all of the saved brain cycles they will be able to develop at such rapid pace that when the software is finished and potentially completely unusable the team will have plenty of time to start over with a much better idea of what the end result should actually be. Since they will be using DDD for the next iteration they will most likely finish in a similar situation as they were in at the end of the first cycle, but with an even clearer idea of the scope of the problem and will be that much closer to a working solution.
Since DDD is extremely rapid and involves many, many iterations, it is clearly more agile than even agile is capable of being, hence earning the name aagile. Aagile (pronounced by extending the amount of time spent saying the a) is the only proper way to refer to DDD and will help keep it from being clumped into the bucket of common agile development techniques.
If you have any DDD success stories I would love to hear about them and what key DDD principles helped make them a success.