Like the wider agile family of methodologies, dynamic systems development method is an iterative approach to software development but adds additional discipline and structure to the process. Central to DSDM is the principle that “any project must be aligned to clearly defined strategic goals and focus upon early delivery of real benefits to the business.”
DSDM advocates refer to it as a 'grown-up' version of agile for the corporate world.
In the 1990s, the rapid application development (RAD) approach was becoming increasingly popular, which enabled developers to show their users and customers possible solutions quickly with easy to build prototypes.
However, this approach was often unstructured, with no common processes between RAD teams. This led to each organization building their approaches and frameworks, splitting standards and making it difficult to recruit experienced RAD practitioners.
To solve this issue, the DSDM consortium was founded with the objective of "jointly developing and promoting an independent RAD framework" and DSDM was born.
Since then, there have been numerous versions. The most recent version was released in 2014 and is called the "DSDM Agile Project Framework" and will be the focus of this article.
DSDM is structured around eight key principles:
Focus on the business need: DSDM teams must establish a valid business case and ensure organizational support throughout the project
Deliver on time: Work should be time-boxed and predictable, to build confidence in the development team.
Collaborate: DSDM teams must involve stakeholders throughout the project and empower all members of the team to make decisions.
Quality: To ensure high quality, the level of quality should be agreed with the business at the start of the project. This is enforced through continuous testing, review, and documentation.
Build incrementally from firm foundations: Teams must do enough design work up front (EDUF) to ensure they know exactly what to build, but not too much to slow development.
Developer Iteratively: Take feedback from the business and use this to continually improve with each development iteration. Teams must also recognize that details emerge as the project or product develops and they must respond to this.
Communicate continuously and clearly: Holding daily stand-up sessions, encouraging informal communication, running workshops and building prototypes are all key DSDM tools. Communicating through documents is discouraged - instead, documentation must be lean and timely.
Demonstrate control: The project manager and team leader should make their plans and progress visible to all and focus on successful delivery.
Projects are delivered on time, whilst still allowing flexibility
Progress can be easily understood across the organization
Business cases are at the core of the DSDM model, ensuring delivered projects have real business value
Large management overhead and costly implementation makes this unsuitable for small organizations
DSDM can be restrictive and inhibit developer creativity. Projects are likely to be completed exactly as specified, even if more elegant solutions are available.
Both DSDM and Scrum are methodologies created to bring the principles of the agile philosophy to life. At a glance they can look similar:
Both take an iterative and incremental approach to completing difficult projects or developing complex products.
Both break up larger tasks with defined deadlines into a list of subtasks to complete within the given timeframe.
Both clearly assign distinct responsibilities based on separate roles
But the two methodologies implement the agile principles very differently. Here's how:
The DSDM methodology focuses on projects with a clear scope and an obvious start and finish date. Scrum focuses instead on products with a growing list of desired features and are constantly in development. Products never need to be thought of as finished, dealing instead with product releases.
DSDM has 13 defined roles, many more than Scrum which only has 3! Some of these roles overlap. Scrum developers and DSDM solution developers are similar. However, the Scrum product owner role incorporates three different DSDM roles: Business Sponsor, Business Visionary, and Business Analyst.
Scrum requirement lists start small and leave room to grow, building in constant reviews to accommodate new and changing requirements. DSDM establishes boundaries at the beginning of the project, iterating towards the agreed solution.
If you’re working on a product that will keep being developed, have a smaller team with fewer stakeholders, and are willing to add features throughout the development lifecycle then try Scrum.
Otherwise, if your project has a defined end date, has many stakeholders who hold distinct roles, and has a clear idea of success at the end of the project, then the DSDM methodology might be the better solution.
Every development methodology has its strengths and weaknesses. If your team values predictability, consistency and tight control of costs, DSDM might be a good fit. However, you'll lose creativity and flexibility, which may not be best suited to smaller startups.