DSDM vs Scrum
Agile software development has been growing in usage and popularity for many years now. There are of course a number of different approaches you can take within the agile camp. Agile has formally been around since 2001, when a group of people gathered in Utah and wrote the Agile Manifesto. But agile is just a philosophy, a set of values and principles. To actually enact it you need to apply some kind of rules of framework. In this article, we will look at and compare two of those frameworks: Scrum and DSDM. Let’s see how they relate to each other.
DSDM
DSDM is an acronym for Dynamics Systems Development Method. It is quite an old framework, having been around since 1994. It started as an attempt to improve and build upon the RAD (Rapid Application Development) method. According to its website, it is “an agile method that focuses on the full project lifecycle”.
DSDM is still around today, though it never took off to the extent that Scrum did. It is currently managed by the Agile Business Consortium.
There are eight basic principles of any kind of DSDM work that are crucial to the framework. Those concepts are:
- Focus on the business need
- Deliver on time
- Collaborate
- Never compromise quality
- Build incrementally from firm foundations
- Develop iteratively
- Communicate continuously and clearly
- Demonstrate control
Many of the common issues in software development such as late delivery, cost overruns, or deliverables not fulfilling the requirements are solved with DSDM by developing a flexible environment that still focuses on hitting key milestones and maintaining high quality.
It uses an iterative lifecycle to include stakeholders and gather feedback. Clear functions and also responsibilities are included in the tasks, and teams operate in timeboxes to enforce adherence to routines and checkpoints.
Core steps and techniques of DSDM
DSDM is based on seven core steps:
- Pre-project
- Feasbility study
- Business study
- Functional model iteration
- Design and Build iteration
- Implementation
- Post-project.
These phases are sustained by the following methods:
Timeboxing
A technique utilizing periods no more than 2, 4, or 6 weeks, during which a provided set of tasks are finished. A timebox can include any amount of work, and at the end a product is required to be delivered. Tasks can also be changed during a timebox, allowing fast reaction to changing needs.
MoSCoW prioritization
The MoSCoW system considers the value of requirements by classifying them as must have, ought to have, could have, and would have. MoSCoW is a common and popular system that is also used outside of DSDM.
Prototyping
Prototypes satisfiy the DSDM principles of constant shipment and incremental development by delivering critical features quickly and discovering issues early in the development process.
Testing
DSMS emphasises the importance of continually integrating and testing, to ensure a stable product. This is especially important when working in an agile environment, with frequent changes and new features.
Modeling
Diagrams and models of specific system or organization elements are important to provide transparency and build understanding.
Scrum
Scrum is a framework within Agile that enables product development under conditions of uncertainty.
It encourages teams to learn through experience, self-organize, and continuously show their successes and failures. It is designed to deal with changing requirements and prioritises continual learning and improvement. Scrum is structured in a manner to acknowledge that we don’t know everything at the beginning of a project.
Teams adjust to changes in problems and also user requests. There are short launch cycles to allow groups to learn and improve (both themselves and their product).
Key elements of Scrum
At the core of Scrum are Scrum values, the Scrum framework, Scrum roles, Scrum activities and artefacts. The Scrum values are focus, courage, openness, commitment, and respect. These values act as the foundation for the Scrum team’s behaviours and interactions.
The Scrum structure enables a team to develop a product and focuses on value and transparency. A vital advantage of the Scrum structure is that it is consistent across all items. It does not have to be changed relying on what item is being created. Scrum cycles consist of Scrum functions, activities, and also artefacts interacting. A Scrum team is made up of three roles, or accountabilities:
Product Owner: they own then vision and value proposition of the product
Scrum Master: Guides and supports the Scrum team (and the organization) and helps improve their effectiveness.
Developer: The development team builds product increments.
Scrum consists of four key events (and one continuing activity). The events are Sprint Planning, Daily Scrum, Sprint Review, and the Sprint Retrospective. The continuing activity is called Backlog Refinement.
These activities together are used to generate tangible deliverables or artefacts. Scrum includes three concrete artifacts: a product increment, a product backlog, and a sprint backlog, which is an actionable plan of work for the current sprint. A Scrum cycle repeats every sprint, and roughly goes as follows:
The team discuss and negotiate a sprint goal (an objective for increasing the value of the product)
The team select and agree to a number of backlog items that could enable the team to meet that sprint goal, and a rough plan for how they will complete these backlog items (this is the sprint backlog – this concludes the Sprint Planning event)
The team works collaboratively during the sprint to deliver a product increment that reaches the sprint goal
The product increment is shown to stakeholders at the Sprint Review – feedback is collected and there is a discussion about how best the team can progress in the next sprint
The team concludes the sprint with a Retrospective, where they discuss how they went well and how they can improve..
DSDM vs Scrum
Despite the fact that they are both agile frameworks, there are some key differences between DSDM and Scrum.
Project vs product
One of the main differences is that DSDM is based around projects, while Scrum is based around products. This is in fact an important distinction.
Scrum does not assume there is a project. A project usually has a fixed scope and a fixed ending. There is a list of things that need to be built, and a time they should be finished by, and that’s locked in at the start. The problem with that idea is that we usually don’t know all the things we need from a software product when we start building it. And we usually want to keep adding more features and enhancements to it, so it can grow in value.
Scrum solves this by having a dynamic Product Backlog rather than a scope list. This is a list of features but it starts small and is continually added to and changed. It also assumes the product exists in perpetuity, i.e. will continue to be worked on indefinitely.
DSDM assumes there is a project, and tries to manage it in an agile way. So if you do have a project and want to try agile, DSDM could be the right framework for you. But before you start, have a think about whether a project approach really is the right approach. If you are building a software product, the project management approach might not be the right one in the first place.
Roles
The roles in Scrum and DSDM are quite different. DSDM has many more roles identified than Scrum does. DSDM in fact has the following roles:
Business Sponsor, Business Visionary, Project Manager, Technical Coordinator, Business Analyst, Technical Advisor, Business Advisor, Business Ambassador, Solution Developer, Team Leader, Solution Tester, Workshop Facilitator, DSDM Coach. Phew! That’s 13 roles, compared to three in Scrum.
It is important to note that not only does DSDM have many more roles than Scrum, but that it is missing the Scrum roles. A Scrum “Developer” maps pretty closely to a “Solution Developer”, and a Scrum “Scrum Master” is pretty similar to a “DSDM Coach”. However, crucially, DSDM does not have a Product Owner. And does not have a role that neatly maps to a Product Owner.
DSDM splits the Scrum Product Owner role between several roles: Business Sponsor, Business Visionary, and Business Analyst. I think the Product Owner construct is crucially important to success in Scrum. I recommend most organizations attempt to create this role and empower it accordingly.
But if you are in a context where that Product Owner role simply cannot exist and has to be split between several people, you might want to try DSDM. And see if you can map those three DSDM roles to people in your context.
Conclusion
As you can see, Scrum and DSDM might both be agile frameworks. But they are quite different to one another. Scrum is more for a product development context, where you are building a new thing with uncertain requirements. And you need to quickly respond to feedback to update your backlog. DSDM is more suited to a project context, where you have tighter scope control and governance needs. Scrum has the famous empowered Product Owner role, while DSDM splits that across a few different people. So which one to choose depends on your needs!
What do you think? Have you had experience with one or another of these frameworks? Let me know how you think they compare in the comments! I will read and reply to each one.
