Why prefer DSDM to Scrum?

Ultimately practitioners know that there is no need to choose between Scrum and DSDM, of course: they can be integrated into a hybrid that suits your specific requirements. However, it is helpful to have a clear idea of what the different flavours are and what they are capable of, because it is not only purists who want to know exactly what you are doing: so will the people who are shelling out the cash to pay for the change. Being able to give them a clear choice between clerly defined options, plus clear criteria for choosing, is essential to selling any form of agile.

So, here are some reasons for preferring DSDM to Scrum, in direct proportion to the size, complexity and innovativeness of the project and the difficulty of the technical and compliance requirements.

1. The Foundation stage makes sure that everyone ‘gets’ what you are up to. Without this, something very bad is likely to happen to your project. Adding a 'Sprint 0' isn’t the answer unless it looks very like DSDM’s Foundations anyway.


2. DSDM is a true end-to-end process, not just the middle, development snippet. Since most of the mistakes in IT are made before the ink is dry on the contract (internal or commercial), this is a crucial consideration.


3. Defining the roles as completely as DSDM does can be extremely helpful in any but the most trivial of projects. After decades of IT neglecting this issue, it is refreshing that DSDM includes it. Very hard to do well (and the sell to the business and operations alike), but absolutely essential.


4. Defining a few basic products – BAD, SAD etc. - is also very helpful. Given the complexity of most real projects, it can be impractical to rely too heavily on prototypes and the authority of empowered teams, powerful though they are.

As this list suggests, DSDM is much more suited to a corporate environment, where the playfulness, autonomy and spontaneity of Scrum clashes rather sharply with the demand for formal definition, accountability and predictability. It's hard to get the full benefits of Scrum while adhering to corporate formalities dictates concerning governance and accountability, investment prioritisation, intelligibility and visibility to a wider group of stakeholders, quality management, reporting and architecture.

Anders Larson has kindly pointed me to this good comparison of DSDM and Scrum from the DSDM Consortium site. Its author, Andrew Craddock, summarises the position very well: after listing the principles of the Manifesto for Agile Software Development, to which both Scrum and DSDM practitioners contributed and subscribe -

• People and Interactions over Processes and Tools
• Working Software over Comprehensive Documentation
• Customer Collaboration over Contract Negotiation
• Responding to Change over Following a Plan

- he notes that 'DSDM recognizes value in the items on the right of the Manifesto statements more than Scrum does, whilst still putting the highest value on the items on the left. This allows DSDM to fit more comfortably with the normality of larger organisations and gives rise to some of the differences between these two Agile approaches.'