Dynamic System Development Method or DSDM is a long-standing approach that’s been used successfully since 1994 for rapid software development and delivery.
With its iterative and incremental approach it was agile well before the Agile Manifesto was written and went a lot further than the team level, making it an agile scaling methodology (not just a framework) long before the term ‘scaling agile’ was coined.
Like SAFe, it gives you a lot of guidance, much more than other scaling frameworks. That’s a huge advantage when you’re still finding your agile feet — you’ll have a lot more to hold on to.
So, read on to get a firm grounding in its philosophy, principles, roles, and focus on successfully delivering value to your business quickly.
DSDM considers the need to react quickly throughout the development of the product while incorporating the constraints often imposed by corporate cultures and processes.
Managing projects using DSDM helps resolve many of the problems we face when running projects more traditionally.
For example, DSDM uses regular facilitated workshops and encourages the team to interact, which helps resolve the natural communication problems faced by many projects.
DSDM focuses on delivering on time because delivering 80% of the features working and on time is better than trying to deliver everything late.
Customers are human. As their knowledge of the product increases throughout the development phase, they tend to change their mind. Therefore, DSDM’s approach to understanding customer requirements is to involve a customer in the solution development.
Early customer involvement helps avoid problems, stop unwanted features from being built, and ensure the business gets what it needs. It also helps to prevent over-engineering or gold plating the output.
All of these positive impacts ensure the customer gets a return on its investment as soon as possible.
DSDM is an iterative and incremental approach that embraces Agile development principles, including continuous user/customer involvement.
DSDM was first released in 1994. And it was created to provide some discipline to what was at that time the rapid application development method(RAD), another method in use.
The first DSDM practitioners recognized that sequential development models like a waterfall and rapid application development had strengths and areas to improve.
They aimed to combine RAD’s ability to develop valuable solutions quickly with an understanding of the broader project context and the need for stakeholder engagement.
In 2007, the DSDM project framework was revised. It became a more generic approach to project management and solution delivery rather than explicitly focused on software development and code creation.
In 2014, DSDM released the latest version. The new DSDM manual recognized the need for DSDM to work alongside other frameworks used for service delivery like ITIL, PRINCE2, and the Project Management Institute’s Body of Knowledge (PMI-BOK).
The DSDM philosophy is that any project must be aligned to clearly defined strategic goals and focus upon early delivery of real benefits to the business.
This is achieved when all stakeholders:
The DSDM philosophy is supported by eight principles that build the mindset and behaviors necessary to bring the philosophy alive.
The principles are themselves supported by four Ps:
The eight principles of DSDM bring the agile values to life by guiding the team in the attitude it must take and the mindset it must adopt in order to deliver consistently whilst still remaining flexible.
Principle 1 – Focus on the Business Need
Every decision taken during a project should be viewed in the light of the overarching project goal – to deliver what the business needs to be delivered, when it needs to be delivered.
Principle 2 – Deliver on Time
Delivering a solution on time is a very desirable outcome for a project and is quite often the single most important success factor.
Principle 3 – Collaborate
Collaboration encourages increased understanding, greater speed and shared ownership, which enable teams to perform at a level that exceeds the sum of their parts.
Principle 4 – Never Compromise Quality
In DSDM, the level of quality to be delivered is agreed at the start. All work should aim to achieve that level of quality – no more and no less.
Principle 5 – Build Incrementally from Firm Foundations
DSDM advocates understanding the scope of the business problem to be solved and the proposed solution first, but not in such detail that the project becomes paralysed by overly detailed analysis of requirements.
Principle 6 – Develop Iteratively
DSDM uses a combination of Iterative and Incremental Development, frequent demonstrations and comprehensive review to encourage timely feedback. Embracing change as part of this evolutionary process allows the team to converge on an accurate business solution.
Principle 7 – Communicate Continuously and Clearly
Poor communication is often cited as the biggest single cause of project failure.
DSDM practices are specifically designed to improve communication effectiveness for both teams and individuals.
Principle 8 – Demonstrate Control
The use of well-defined Timeboxes, with constant review points, and the preparation of the Management Foundations and Timebox Plans, are designed to assist the Project Manager and the rest of the project team to follow this principle.
In the traditional approach to managing a project (left-hand diagram), the features content of the solution is fixed whilst time and cost are subject to variation.
If the project goes off track, more resources are often added (which varies the cost), and the delivery date is extended (which changes the time).
However, adding resources to a late project often makes it even later, and a missed deadline can be disastrous from a business perspective and often damages credibility.
Under such pressure, quality often becomes a variable due to introducing compromises that have not been thought through, reducing essential quality control steps, or cutting back on testing.
DSDM’s approach to managing the project (right-hand diagram) fixes time, cost, and quality at the end of the Foundations phase. At the same time, contingency is controlled by varying the features (the requirements) to be delivered. As and when the contingency is required, lower priority requirements are dropped or deferred, with the full agreement of the business stakeholders following MoSCoW priorities.
The DSDM has a five-phase life cycle as shown below.
In the feasibility and study phase, the problem is defined and technical feasibility of the desired application is verified. It is also checked whether the application is suitable for the Rapid Application Development (RAD) approach or not.
Only if the RAD is found as a justified approach for the desired system, the development continues.
The main focus in this phase is on building the prototype iteratively and getting it reviewed by the users to bring out the requirements of the desired system.
The prototype is improved through demonstration to the user, taking the feedback, and incorporating the changes. This cycle is repeated generally twice or thrice until a part of the functional model is agreed upon.
The end product of this phase is a functional model consisting of an analysis model and some software components containing significant functionality.
This phase ensures that the prototypes are satisfactorily and properly engineered to suit their operational environment.
The software components designed during the functional modeling are further refined till they achieve a satisfactory standard.
The two phases, as a result, may simultaneously continue. The product of this phase is a tested system ready for implementation.
Implementation is the last and final development stage in this methodology.
In this phase, the users are trained, and the system is put into the operational environment.
At the end of this phase, there are four possibilities, as depicted:
The DSDM Agile Project Framework describes a set of products to be considered as the project proceeds. These products describe the solution itself (the main deliverable of the project) and anything created to help with the process of evolving it, and anything that is required to help with project governance and control.
DSDM identifies two distinct types of product:
Type of Product
Terms of Reference
It is a high-level definition of the overarching business driver for, and top-level objectives of, the project. ToR scopes and justifies the Feasibility phase.
It provides a snapshot of the evolving business, solution and management products.
It provides a vision and a justification for the project from a business perspective.
It describes how the benefits have actually accrued, following a period of use in live operation.
The Prioritised Requirement List
It describes, at a high level, the requirements that the project needs to address and indicates their priority.
Type of Product
Management Approach Definition
It reflects the management approach of the project as a whole. For instance, how the project will be organised and planned, how stakeholders will be engaged in the project and how progress will be demonstrated and, if necessary, reported.
It provides a high-level schedule of Project Increments and, at least for the first/imminent Increment, Timeboxes that make up that Increment.
It provides depth and detail for each Timebox identified in the Delivery Plan.
Timebox Review Record
It captures the feedback from each review that takes place during a Timebox.
Project Review Report
It is typically a single document that is updated, incrementally, at the end of each Project Increment by the addition of new sections pertinent to that Increment.
Type of Product
It provides a high-level design framework for the solution. It covers both business and technical aspects of the solution to a level of detail that makes the scope of the solution clear but does not constrain evolutionary development.
Solution Assurance Pack
It provides a high-level definition of the tools, techniques, customs, practices and standards that will be applied to the evolutionary development of the solution. Importantly it describes how the quality of the solution will be assured.
It is made up of all appropriate components of the final solution together with any intermediate deliverables necessary to explore the detail of requirements and the solution under construction.
This is a baseline of the Evolving Solution, which is deployed into live use at the end of each Project Increment.
What makes DSDM stand out amongst other system development methods are the following techniques and practices.
DSDM adheres to strict deadline standards. The project is broken down into smaller items that each have a firm budget and timeframe. To navigate this, requirements are prioritized. If time or money is running out, lowest priority requirements are removed. A finished project then comes from only the most essential requirement items.
This is the prioritization group used to rank items from highest level of importance to the lowest. The prioritizations groups are Must Have, Should Have, Could Have, and Won’t Have.
Modelling helps to visualize different aspects of the project along the way. This helps to present each item in development and allow for iterative development by providing regular feedback and implementing improvement.
Like many agile methodologies, prototyping is essential to test run the project at an early, conceptual stage. It is a way to map out the basic functions, discover glaring weaknesses, and allow users to test run the software.
Users and stakeholders are brought together to discuss requirements, issues, results, and testing. DSDM relies on high levels of user interaction, right from the get-go. Testing is hugely important for DSDM, as it ensures high quality results.
Any agile systems development will have a list of roles that must be filled. DSDM is the same. According to their handbook, these are the essential roles in any DSDM environment.
Executive Sponsor (the “Project Champion”)
The user organization and/or the customer will provide someone for this role. They are also the one who can allot funds and resources, as needed. They are the “final say” when it comes to decision-making.
Armed with concrete objectives and an understanding of the user business, the Visionary initialises the project by locking on to the highest priority requirements early on and guiding the team based on this.
An ideal “test user” who brings the point-of-view of the user community into the project. They become a key source of feedback throughout the entire process.
Another type of user that should bring essential viewpoints to the project at hand. They may have unique insights or other expertise that makes them the ideal candidate.
A project manager is anyone who manages the overall project.
They will design the system architecture and be responsible for quality control of all technical elements.
The leader of the team, responsible for coordination and facilitating collaboration.
Navigate any system requirements, model the system, develop the deliverable codes, and create prototypes.
Tests the product and provides comments and documentation when errors arise. They also re-test after corrections are implemented.
Scrum and DSDM share many similarities but also have a few critical differences.
Some are merely terminology-based; for example, DSDM divides work into the “engineering activity” (AKA the development phase) and the “emerging solution” (AKA the output). Whereas with Scrum, the output is known as the “potentially releasable increment.”
Both methods have lists of subtasks that are completed based on adherence to tight deadlines. Both methodologies build towards a finished project, which Scrum flags once the project reaches the “Definition of Done.” However, the project has no specific point when this “Definition of Done” is agreed upon, which is a critical difference between Scrum and DSDM.
In DSDM, there is a set phase when the definition of work (and finished work) is agreed upon: the Foundation Phase of the project. This happens relatively early on, which can sometimes mean that assumptions color the planning process. Therefore, the definition of “finished” work is to be reviewed periodically across the project lifecycle to account for the assumptions.
The sticking point is that team leaders avoid Big Design Up-Front (BDUF), which is more of a feature of Waterfall Methodologies and not Agile.
DSDM has a broader focus than most other agile approaches in that it deals with projects rather than just the development and delivery of a product (typically software).
DSDM has a long track record of successful agile project delivery in all types of corporate environments and has proved to be fully scalable, working effectively in small, uncomplicated businesses, large, complex organizations, and highly regulated environments.
That said, DSDM’s project focus shines when it comes to creating new complex products that take more than a few months and teams to deliver.
For example, a solution to integrate data from many separate solutions to get you the unified view on performance needed for effective executive dashboards up and down your organization.
DSDM helps you reduce the risk of these endeavours.
DSDM may also be used to supplement an existing in-house agile approach. For example, DSDM is often used to provide the complete “project” focus to complement Scrum’s team-focused product development process.
Dynamic System Development Method is the dynamic method that fully and maturely helps you navigate the complex and dynamic business of developing a software product.
With DSDM you’ll work toward a clear business outcome, involve business users continually, and execute in a controlled manner. Your people will deliver value quickly and with the expected quality.
So, go for it. Get agile with DSDM.