The pressure to get ever more sophisticated and flexible products into users’ hands ever more quickly has made extreme programming (XP) the king of lean-and-mean development methodologies.

Older development methodologies, such as Waterfall, are tiered and sequential (read “time-consuming”), and they tend to compartmentalize 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 prioritizing 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 minimize 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.

DSDM and XP hold user involvement and frequent revision in common, of course. DSDM’s winning features in larger and more complex environments are its business fitness focus and the reversibility requirement—a somewhat costly feature, but one that pays for itself by minimizing the damaging effects of inevitable implementation errors and user backtracking. And some features of XP, such as pair programming, are rendered unnecessary by the DSDM testing philosophy, which accomplishes the same thing.

DSDM’s five phases
In place of XP’s “do-over” design doctrine, DSDM requires five distinct project phases:

  • A feasibility study phase, to gauge the business appropriateness of the proposed system, its technical realization, and the costs and duration.
  • A business study phase, to generally define the primary functions of the system and set the reliability and performance goals.
  • A functional model iteration, with prototyping to determine user requirements and gather information, demonstrate intended functionality, and gather nonfunctional requirements (this phase is repeated as often as necessary).
  • A system design/build iteration, which may begin before the previous phase is complete, for refining and detailing the functional prototype with the goal of delivering a design prototype that meets the functional and nonfunctional requirements (this is a repeatable phase).
  • An implementation phase, in which the system is delivered to end users for evaluation and a project audit is conducted that will either release the system for live use or return it to an earlier phase.

Interphase activities
Continuity is maintained during this process by several interphase activities: project management, prototyping management, configuration management, risk analysis, testing, and quality assurance. Diligence in these areas appears on the surface to create a time cost to the project; however, that same diligence repays the project in reduced iteration time.

The benefits of DSDM
Many of the benefits of DSDM are also benefits of XP. For instance, both methods involve the user deeply in the development process, resulting in strong user identification with the system—cooperation in the process will break down the users’ resistance to change before it has a chance to grow. And the final system is more in line with the ultimate user requirements.

However, DSDM has the edge, with several deliverables that recommend it over other methodologies. Reversibility in every iteration avoids the optional scope contract trap of XP. There’s no corrective design when any misstep can be rapidly eliminated. The five-phase project structure makes missing delivery windows less likely. And while XP’s methodological emphasis is programming, DSDM delivers the most comprehensive final product, with a continual focus on business processes—where the customer needs it to be.

Will DSDM work for you?

Have you used the DSDM approach? How did it work out? Post a comment below or e-mail us.