DO NOT USE THIS SITE


Site is under construction - things will be added, but completion ETA is sometime in 2026.
Do not expect it to have much content or act correctly yet. Expect broken links & weirdness.
It was only put up to show what to expect & how it fit into AgileFieldGuide.com.

Origins

The Dynamic Systems Development Method (DSDM) was created in the mid-1990s by a consortium of British vendors and experts aiming to bring order to the chaotic world of Rapid Application Development (RAD). While RAD emphasized speed, it often neglected structure, leading to projects that either delivered the wrong solution, suffered from technical debt, or collapsed under shifting requirements. DSDM sought to rescue the best of RAD's ideas while correcting its failings through formalized governance, predictable delivery patterns, and strong business involvement.

In 1994, DSDM Version 11 was published. Unlike other Agile approaches that would emerge years later, DSDM positioned itself as an Agile project framework that spanned from initial idea to benefits realization. It evolved into DSDM Atern in 2007, and today its practices are folded into the Agile Project Framework managed by the Agile Business Consortium. Though newer frameworks like Scrum and SAFe have become more visible, DSDM's structured approach remains influential, especially in industries where discipline and auditability are essential.

Core Principles

DSDM is founded on eight principles that act as its moral compass. These principles are not optional: they must be honored for a DSDM initiative to succeed.

  • Focus on the business need: Delivery must be tied to clear, prioritized business objectives. Features without business value are discarded or deprioritized.
  • Deliver on time: Predictability is king. Delivery dates are fixed, and scope flexes to meet the agreed timeframe.
  • Collaborate: Success depends on active cooperation between business and technical people. Isolation between "the business" and "the developers" is unacceptable.
  • Never compromise quality: Quality levels are set at the beginning of the project and must be preserved, even if scope must be reduced.
  • Build incrementally from firm foundations: Solutions grow in manageable steps, but not without first understanding core business needs and setting architectural foundations.
  • Develop iteratively: Learning unfolds as the product evolves. Early increments inform and improve future work.
  • Communicate continuously and clearly: Face-to-face communication is preferred. Progress, risks, and issues must be made transparent.
  • Demonstrate control: Visibility and governance are achieved through regular status checks, timebox reviews, and agreed standards.

These principles guide the day-to-day practices of DSDM teams, helping them balance business agility with the need for control and predictability.

Roles

DSDM defines a robust and balanced set of roles to ensure that all viewpoints and responsibilities are covered. Roles are categorized across three major areas: Business, Solution Development, and Management.

Business Roles:

The Business layer ensures that development work remains anchored to organizational goals.

  • Business Sponsor: This person is the ultimate project champion, ensuring alignment with strategic business objectives. They provide funding, remove organizational roadblocks, and signal that the project has top-level support.
  • Business Visionary: Responsible for interpreting the sponsor's goals into a clear, unifying vision that guides the team. The Visionary maintains alignment and ensures that the project does not drift away from its intended purpose.
  • Business Ambassador: Acting as the "voice of the user", the Ambassador works closely with developers, articulating detailed requirements, providing rapid feedback, and validating deliverables during development.
  • Business Advisor: These are subject matter experts who contribute their specialized knowledge when needed. They may join for particular features, regulatory guidance, or deep business rules.
Solution Development Roles:

The Solution Development roles focus on shaping, building, and testing the evolving product.

  • Solution Developer: Developers in DSDM are not just coders. They are active collaborators who interpret requirements, design solutions, and build them in close partnership with business stakeholders.
  • Solution Tester: Testing is continuous in DSDM. Solution Testers work alongside developers from the beginning, validating features within each timebox and ensuring that new increments integrate correctly.
Management Roles:

These roles enable coordination, governance, and support across the project.

  • Project Manager: Guides the process without micromanaging. The Project Manager ensures that timeboxing is respected, risks are addressed, communication flows freely, and that DSDM principles are upheld.
  • Team Leader: Oversees the day-to-day activities of the Solution Development Team, ensuring that collaboration, technical excellence, and progress happen at the right pace.

Additional roles such as the Technical Coordinator (ensuring technical architecture coherence) and Workshop Facilitator (running focused requirement and solutioning sessions) are drawn in when needed.

DSDM places emphasis on empowered teams with clear decision-making authority at every level.

Key Practices and Events

DSDM's project lifecycle consists of clearly defined stages that guide teams from concept to solution delivery:

Pre-Project:

The Pre-Project phase determines whether the project is worth pursuing. It assesses if there is a real business need, available funding, and organizational commitment.

Feasibility Study:

A lightweight exploration into whether the desired solution is technically feasible, organizationally viable, and valuable to the business. Feasibility Studies are fast-paced and intended to prevent organizations from wasting time on impractical ideas.

Foundations Phase:

While Agile discourages heavy upfront design, DSDM insists on building "just enough" foundation. Teams define the project scope, high-level architecture, project approach, risks, governance models, and business case here. Good foundations enable fast, focused evolutionary development later.

Evolutionary Development Phase:

This is where timeboxed iterations happen. The product is built incrementally, with each timebox resulting in tested, integrated features. Frequent business feedback and prioritization are vital. Flexibility around scope and features is managed through the MoSCoW prioritization technique.

Deployment Phase:

The Deployment phase assembles increments into a deployable release. It may involve user acceptance testing, final documentation, or packaging the system for delivery. Some projects deploy after every increment, others wait until after multiple increments.

Post-Project Phase:

Finally, the project team assesses whether the business benefits predicted in the business case are being realized. Lessons learned are gathered to improve future initiatives.

Timeboxing and MoSCoW prioritization are critical disciplines throughout these phases, ensuring that fixed time and cost targets are met by adjusting scope intelligently.

How DSDM is Used by Agile Teams & Organizations

DSDM is favored by teams that must work within clear governance structures while still seeking to benefit from Agile principles. It is particularly attractive in highly regulated sectors like finance, insurance, government, and healthcare, where demonstrating control and accountability is mandatory.

Organizations use DSDM when:

  • Business change must be tightly coupled with technical delivery.
  • Fixed deadlines or budgets are non-negotiable.
  • Cross-functional collaboration is culturally supported.
  • Agile initiatives must align with enterprise portfolio management.

Teams within DSDM are often cross-functional, blending business, analysis, development, testing, and management skills into a single working unit. Transparency, timeboxing, empowered decision-making, and rigorous prioritization form the backbone of their operations.

When to Use It, and When Not to Use It:

DSDM is a good fit when the environment demands discipline without sacrificing agility. However, it carries real demands in terms of organizational maturity.

Use DSDM when:

  • Business and technical stakeholders are available and willing to engage daily.
  • Projects must deliver reliable value within fixed time and cost constraints.
  • Organizational sponsors are committed to empowering the team rather than micromanaging it.
  • Project governance and compliance reporting are non-optional.

Avoid DSDM when:

  • Business engagement is poor or fragmented.
  • Requirements are completely unknown and require extensive discovery and experimentation.
  • The organization resists variable scope thinking.
  • Teams are culturally unprepared for disciplined timeboxing and incremental delivery.
Comparison to Other Agile Frameworks:

DSDM offers a broader, more structured project framework compared to most Agile approaches. Scrum, for example, is a lightweight team-level framework that assumes a Product Owner and stakeholders outside the team will manage business prioritization. DSDM, on the other hand, brings the business fully inside the project.

Where XP emphasizes technical craftsmanship and continuous integration, DSDM stresses business ownership and managed timeboxing. It shares Lean's disdain for waste but demands more upfront groundwork.

Compared to Crystal Methods, which adapts itself fluidly based on team size and criticality, DSDM is much less flexible in structure but much stronger in providing a clear path for large or critical projects.

DSDM's closest modern cousins would be frameworks like Disciplined Agile Delivery (DAD) and SAFe Agile Release Trains, which also seek to balance Agile and enterprise needs.

Key Takeaways

  • DSDM focuses on business needs as the anchor for all delivery decisions.
  • Fixed time, fixed cost, and variable scope are core to controlling projects.
  • Business representatives must be fully engaged and empowered.
  • Timeboxing and MoSCoW prioritization are non-negotiable disciplines.
  • DSDM spans the entire project lifecycle, not just the development cycle.
  • It is best suited for complex, high-stakes, or regulated environments.

Summary

The Dynamic Systems Development Method remains one of the most structured and complete Agile frameworks available. It provides a disciplined yet flexible approach for delivering business solutions quickly, ensuring that projects do not spiral out of control as requirements evolve.

However, DSDM places real demands on organizations. Without committed business participation, disciplined scope management, and a willingness to embrace iterative delivery, DSDM initiatives will falter. When well-implemented, though, DSDM stands as a gold standard for balancing the competing needs of agility, predictability, and business value.

Coaching Tips
  • Secure Business Sponsorship Upfront: Insist on gaining an engaged Business Sponsor and Ambassador before starting full-scale development.
  • Normalize Prioritization Skills: Spend time educating stakeholders on MoSCoW thinking. Without a shared understanding of what "Must" versus "Could" means, projects will suffer.
  • Coach for Discipline in Timeboxing: Many Agile teams resist fixed deadlines. DSDM thrives when timeboxing is respected. Use lightweight tracking and visualizations to coach adherence.
  • Anchor Teams in Business Value: Constantly ask: "What business outcome does this feature serve?" This keeps developers and business people aligned around the real purpose.
  • Educate on Evolutionary Development: Combat "big bang" thinking early. Show stakeholders how incremental delivery reduces risk, accelerates feedback, and builds trust.
  • Treat Foundations as Enablers, Not Bureaucracy: Help teams understand that lightweight architecture, governance, and scoping are accelerators, not anchors.