Dynamic systems development method (DSDM) is an agile project delivery framework that first came about in 1994 and was, at that time, used for software development. It was meant to be an improvement on Rapid Application Development (RAD), which prioritized rapid prototyping and iteration based on user feedback. As with many agile project delivery methods, the DSDM Agile Project Framework eventually moved from being a software-specific solution to a more general project management tool.
Elements of the Dynamic Systems Development Method include:
Set apart from other methods by a reliance on a strong foundations and governance
Incremental, iterative approach to progress
User or customer feedback is key to ongoing improvements
Relies on strict costs, quality, and time constraints
Prioritizes scope according to Must Have, Should Have, Could Have, or Won’t Have
Besides the practice itself, DSDM also gave way to the creation of the DSDM Consortium in 1994. Software engineers and other experts banded together to develop and improve the framework as a valid alternative to the more common Rapid Application Methodologies. At the time, the group included representatives from the likes of British Airways, American Express, Oracle, Logica, Data Sciences, and Allied Domecq. The group now rebranded and now goes by the Agile Business Consortium.
RAD methodology was hugely popular in the early 1990’s as a systems development methodology for software development and other IT projects. During this time there was a shift from the traditional “green screen” UX to the graphical user interfaces that have now become synonymous with all tech. This change meant that the development cycle could change, too, using this new type of visual UI for communication, rapid prototyping, and iteration.
The RAD methodology was a bit of a chaotic agile system development. It had no single agreed-upon approach or definition. Agile DSDM was a more structured approach to this type of software development model. The dynamic systems development method was hyper focused on time and cost budgets through strict scope prioritization. It also prioritizes communication (and resulting action) between all stakeholders.
Not only is DSDM strict about deadlines and budget, it also tends to have a firm order of events: Pre-Project phase, Project Life-Cycle phase, and Post-Project phase. RAD software development methods are more about free-form work, letting creativity and independence reign even at the cost of resource depletion.
Scrum vs DSDM
Scrum and DSDM share many similarities but also have a few important 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 are also building towards a finished project, which Scrum flags once the project reaches the “Definition of Done.” However, there is no specific point within the project when this “Definition of Done” is agreed upon. This is a key 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 yet unfounded assumptions color the planning process. To account for this, the definition of “finished” work is to be reviewed periodically across the project lifecycle. A sticking point, too, is that team leaders are to avoid Big Design Up-Front (BDUF), which is more of a feature of Waterfall Methodologies and not Agile.
The DSDM agile principles are the guiding force behind every project. There are 8 principles in total.
Focus on the business need
Deliver on time
Never compromise quality
Build incrementally from firm foundations
Communicate continuously and clearly
DSDM Techniques & Practices
What makes DSDM stand out amongst other system development methods are the following # techniques and practices.
Timeboxing: DSDM adheres to strict deadline standards. To do so, one must break down the whole of the project 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.
MoSCoW: This is the prioritization groups used to rank items from highest level of importance to the lowest. The priorizations groups are Must Have, Should Have, Could Have, and Won’t Have. Configuration management helps to navigate all of these competing deliverables, often being developed at the same time.
Modelling and Iterative Development: 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.
Prototyping: 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.
Workshops: 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.
1. 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.
2. Visionary – 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.
3. Ambassador User – 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.
4. Advisor User – 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.
5. Project Manager – A project manager is anyone who manages the overall project.
6. Technical Co-ordinator – They will design the system architecture and be responsible for quality control of all technical elements.
7. Team Leader – The leader of the team, responsible for coordination and facilitating collaboration.
8. Solution Developer – Navigate any system requirements, model the system, develop the deliverable codes, and create prototypes.
9. Solution Tester – Tests the product and provides comments and documentation when errors arise. They also re-test after corrections are implemented.
10. Scribe – Records the requirements, agreements, decisions, and any other useful information for the progress of the project.
11. Facilitator – They are in charge of motivating and preparing the workshop to keep progress consistent and steady. They must be a master communicator, keeping everyone on track.
12. Specialist Roles – These are roles filled by specialists in their field or industry, providing extra support depending on the needs of the project. They may vary from project-to-project and team-to-team. Roles like this may include Business Architect, Quality Manager, System Integrator, and more.
DSDM Project Management Tips
These tips can help to get the most out of your DSDM project, although all Agile systems can also benefit from using parts of this knowledge.
1. Senior management and all employees must understand and be onboard with the methodology chosen for a project.
2. The team heading the project must commit to user testing, feedback, and involvement across the whole process—from conception to launch.
3. There must be a stable and empowered core project team. Members of the team must have decision-making power to ensure the process doesn’t get tied-up in needlessly obtuse proposal and approval processes. The team must also have everything that they need to function, like the right technology, a healthy development environment, project management tools, and more.
4. There must be a supportive and proactive relationship between the customer and the vendor, whether the projects are internally developed or contracted out.
5. The team must show fearlessness when it comes to honestly prioritizing project needs and scrapping low priority items as needed. This is how things stay on time and within budget.