Dynamic systems development method
The Dynamic Systems Development Method (DSDM) is an agile project delivery framework originating in the UK in 1994, making it one of the earliest agile approaches. DSDM emphasizes delivering business value through iterative development while respecting fixed constraints on time and budget. Unlike some agile methods that flex on scope and schedule, DSDM fixes time and cost while allowing requirements to adjust.
Why it matters
Many organizations operate under genuine constraints. Budgets are fixed, deadlines are real, and "it'll be done when it's done" isn't acceptable. DSDM addresses this reality by building flexibility into what gets delivered rather than when or at what cost.
The framework's maturity and emphasis on governance also makes it suitable for contexts where Scrum or Kanban feel too lightweight. Large organizations, regulated industries, and projects with significant business stakes find DSDM's structure reassuring while still gaining agile benefits.
Core principles
DSDM is built on eight principles:
Focus on the business need. Every decision should be evaluated against business objectives. Features that don't serve business needs don't belong.
Deliver on time. Time constraints are real and should be respected. Meeting deadlines matters.
Collaborate. Teams, stakeholders, and users work together throughout. No over-the-wall handoffs.
Never compromise quality. Quality is built in, not inspected in afterward. The agreed level of quality must be maintained.
Build incrementally from firm foundations. Start with solid understanding before building, but build incrementally rather than all at once.
Develop iteratively. Embrace iteration and refinement. Accept that you won't get everything right the first time.
Communicate continuously and clearly. Ongoing communication prevents misunderstanding and keeps stakeholders aligned.
Demonstrate control. Maintain visibility and governance throughout. Projects should be controlled, not chaotic.
The moscow method
DSDM popularized MoSCoW prioritization, which became widely used beyond DSDM itself:
Must have - Requirements essential for project success. Without these, the project fails.
Should have - Important requirements that are not critical. Their absence is painful but survivable.
Could have - Desirable requirements that are easy to leave out. Nice to have if time and budget permit.
Won't have (this time) - Requirements explicitly excluded from this iteration but potentially included later.
MoSCoW enables the fixed-time-flex-scope approach. When deadlines approach, Could-haves are dropped first, then Should-haves if necessary. Must-haves are protected.
Dsdm lifecycle
DSDM defines a project lifecycle:
Pre-Project - Before formal project start, assess whether DSDM suits the project and whether the project should proceed.
Feasibility - Quick assessment of whether the project is technically and organizationally feasible.
Foundations - Establish project fundamentals: business case, requirements outline, architecture approach, and management approach.
Evolutionary Development - Iterative development through timeboxed cycles. Most project time is spent here.
Deployment - Release to production, including training, documentation, and transition.
Post-Project - Assess benefits realization after deployment. Did the project deliver expected value?
Roles in dsdm
DSDM defines specific roles:
Business Sponsor - Senior business person with ultimate responsibility for the project.
Business Visionary - Owns the business vision and ensures the project aligns with it.
Technical Coordinator - Ensures technical consistency and quality across the project.
Team Leader - Coordinates team activities (similar to Scrum Master but with more project management responsibility).
Business Ambassador - Business user embedded with the team, providing day-to-day business expertise.
Business Analyst - Facilitates communication between business and technical team members.
Solution Developer - Interprets business requirements and creates technical solutions.
Solution Tester - Tests that solutions meet requirements and quality standards.
Dsdm vs. scrum
Both are agile, but they differ:
| Aspect | DSDM | Scrum |
|---|---|---|
| Scope | Full project lifecycle | Development iteration |
| Flexibility | Flex scope, fix time/cost | Often flex on everything |
| Governance | Detailed roles and phases | Minimal prescription |
| Documentation | Structured approach | Whatever works |
| Scale | Built for larger projects | Requires scaling extensions |
Organizations often use both: DSDM for project structure and governance, Scrum or Kanban for development iteration.
When dsdm fits
DSDM works well when:
DSDM fits less well when:
DSDM represents a mature agile framework that takes organizational realities seriously. Its fixed-time-flex-scope approach and emphasis on governance make it valuable for contexts where lighter agile methods feel insufficient.
