Principles of DSDM

There are 9 underlying principles of DSDM consisting of four foundations and five starting-points for the structure of the method. These principles form the cornerstones of development using DSDM.

* User involvement is the main key in running an efficient and effective project, where both users and developers share a workplace, so that the decisions can be made accurately.

* The project team must be empowered to make decisions that are important to the progress of the project, without waiting for higher-level approval.

* DSDM focuses on frequent delivery of products, with assumption that to deliver something "good enough" earlier is always better than to deliver everything "perfectly" in the end. By delivering product frequently from an early stage of the project, the product can be tested and reviewed where the test record and review document can be taken into account at the next iteration or phase.

* The main criteria for acceptance of deliverable in DSDM is on delivering a system that addresses the current business needs. It is not so much directed at delivering a perfect system addressing all possible business needs, but focuses its efforts on critical functionality.

* Development is iterative and incremental, driven by users’ feedback to converge on an effective business solution.

* All changes during the development are reversible.

* The high level scope and requirements should be base-lined before the project starts.

* Testing is carried out throughout the project life-cycle. (See Test-driven development for comparison).

* Communication and cooperation among all project stakeholders is required to be efficient and effective.

DSDM is also supported by some other principles (or so called assumptions).

* No system is built perfectly in the first try (the pareto principle-80/20 rule). In the process of developing an information system, 80% of the business benefit comes from 20% of the system requirements, therefore DSDM starts implementing this first 20% of system requirements to meet 80% of the business needs, which is good enough as long as the users are intimately involved in the development process and in a position to ensure that the missing 20% would not cause any serious business consequences. Implementing the entire requirements often causes the project to go over deadlines and budgets, therefore it is most times unnecessary to construct the perfect solution.

* Project delivery should be on time, on budget and with good quality.

* DSDM only requires each step of the development to be completed far enough for the next step to begin. This way a new iteration of the project can commence without having to wait for the previous to be completed entirely. And with every iteration the system is improved incrementally. Recall that the business requirements are changing over time at any rate.

* Both Project Management and Development techniques are incorporated in DSDM.

* DSDM can also be used in both in new projects and for expanding current systems.

* Risk assessment should focus on business function being delivered, not on the construction process nor on development process artifacts (such as requirements and design documents).

* Management rewards product delivery rather than task completion.

* Estimation should be based on business functionality instead of lines of code.