Older development methodologies, such as Waterfall, are tiered and sequential (read "time-consuming"), and they tend to compartmentalise expertise. Managers are turning to methodologies like XP to deliver speed and user satisfaction without compromising quality. However, the bigger the system, the harder it is to create and maintain it with nontraditional methods, due to the sheer volume of expertise to be shared between users and programmers and the increasing complexity of the business processes being captured in code. In many environments, XP and its cousins just don't have the robust framework needed to do the job. The enterprise resource planning (ERP) software development community found a Rapid Application Development (RAD) methodology solution in 1995. It's called the Dynamic Systems Development Method (DSDM), and it's supported by a worldwide consortium that includes IBM, Oracle, and Hewlett-Packard. Though originally created in Europe to accommodate large systems with broad and complicated user communities, its principles can be applied broadly. DSDM's basic assumptions
DSDM is based on a set of core assumptions driven by the requirements of RAD. First, it assumes that no system is perfect on initial release; however, 80 percent of a perfect solution can be produced in 20 percent of the time it would take to develop a perfect system. So rapid development is a question of prioritising a development project so that most of the system can be delivered to a satisfied user in a relatively short time. DSDM further assumes that users simply can't define requirements for a perfect system until a new system is in place and in use for some time. "Perfection," or complete satisfaction, can only be clearly defined as a set of requirements after what was imagined has actually been used -- in other words, the users have to use it to know what they really want in a system. Finally, DSDM differs from Waterfall approaches in assuming that the current phase of a project -- for instance, functional prototyping -- need not be complete before the next phase (e.g., system build) can begin. Nine principles are at the core of the DSDM methodology. Some clearly overlap with XP and similar approaches. However, DSDM's principles are sufficiently robust to minimise damage to schedules and resources when a business process radically changes or a major component's design is faulty -- problems that could cripple an XP project. The nine principles are:

• Active user involvement is a must.
• Design groups are empowered to make system development decisions.
• Frequent and regular delivery of components is a priority.
• The primary acceptance criterion for a system or component is its fitness for business purposes -- the design driver is business benefit.
• The business solution is the goal, and iterative and incremental development is necessary to converge on that solution.
• All changes made during development are reversible.
• Initial requirements are defined very generally.
• Testing is not a specific project phase; it occurs constantly.
• It's essential to have collaboration and cooperation between all project participants.