DSDM’s process contains a number of phases, which in turn have a number of activities. In other words, the process tells you what to do and when to do that.
These are the phases of the DSDM’s process:
- Pre-Project: making sure the project makes sense and is set up properly
- Feasibility: investigating the cost-effectiveness of the project
- Foundations: creating a firm foundation for the project (e.g., high-level plans)
- Evolutionary Development: building the product
- Deployment: putting the product into production
- Post-Project: evaluating the business benefits of the project
These phases don’t have a sequential relationship, but one that offers a lot of flexibility to suit the project environment:
This process contains both the project management level and the project delivery level. To compare, a methodology such as PRINCE2® is only about the project management level, and a method such as XP is only about the project delivery level. Scrum is usually known to be in the delivery level, but the fact is that it covers a bit of delivery and a bit of project management layer.
Both of the mentioned levels are inside projects, while there are levels above projects: programs and portfolios. It doesn’t matter how good your project management is, your full success also depends on the quality of your program and portfolio management layers.
A DSDM project can have different lifecycles based on the way you configure the process.
A simple example is demonstrated below, where the initial phases are run, followed by a few iterations of development, and one deployment at the end:
This example is not extremely adaptive; we can be more adaptive by having more deployments because when real users use the product, the feedback will be more useful. A product that is not deployed is only used by user representatives.
It may take more iterations before having the first deployment, but after that, there can be more frequent deployments; e.g., every five iterations.
Do you feel brave? Then you can deploy every increment:
If the project is too large, you may want to revisit the Foundations phase too; e.g., once every five deployments. It means that you may make fundamental changes to your overall plans, such as your management plans or the high-level architecture.
There are many possible combinations (especially when there are multiple teams), which give you a lot of flexibility in tailoring your lifecycle.
Written by Nader K. Rad
This is (and will be) a work in progress: More details will be added in the future, depending on the feedback.
This wiki is developed and managed by an accredited trainer, independent of Agile Business Consortium and APMG. While aligned with their guidelines, it’s not an official resource.