News
DSDM and Scrum: FAQ's - The similarities, differences and potential inter-operability issues
Contributed by Andrew Craddock: Freelance Agile Practitioner, Consultant, Trainer and Coach.
Introduction
This short article is intended to address a number of ‘frequently asked questions’ around the similarities, differences and potential inter-operability issues related to DSDM and Scrum. It should not be considered comprehensive and reflects the opinions of the author who is a certified DSDM Practitioner and Trainer as well as a certified ScrumMaster.
Agility in a corporate environment
The intellectual case for Agility has been made. The traditional waterfall process for software development is and always has been fundamentally flawed. But there is no single alternative to the waterfall, rather a wide variety of alternatives based around iterative and incremental development practices have emerged, some more popular than others and some demonstrably more successful than others. DSDM and Scrum are both leaders in the Agile world in terms of both popularity and success, the former being more dominant in the UK, the latter more dominant in the US.
Even when convinced intellectually of its benefits, many organisations struggle to adopt Agile software development practices such as Scrum - not normally because the developers and users find it difficult, but rather because of the challenges of fitting the project into an existing ‘corporate culture’ that is usually expecting a project to follow a traditional ‘waterfall’. Processes related to governance and reporting, enterprise architecture and quality management, for example, are simply ignored by many of the Agile approaches with many Agile proponents arguing, often justifiably, that the value of these processes within a given organisation are at best unproven and at worst run counter to the proven best practices of software development.
In many respects, experienced practitioners of DSDM agree with this sentiment, as did many of the thought leaders who created DSDM more than a decade ago. Very importantly though, a decision with regards to DSDM was made in the earliest days of its evolution that is valued as highly today as it was then. DSDM should respect the need that larger organisations have to manage portfolios of projects and programmes, to manage architectural diversity, to mange resources, to make project decisions on the foundations of a fully considered Return on Investment and so on. DSDM, then, had to, and still does, accommodate these corporate pressures more readily than most other Agile approaches by considering a project in a wider context than software delivery alone. It does this by having a more expansive lifecycle, by presenting and operating the agile development techniques in a way that makes as much sense to the wider organisation as it does to the project teams and by defining responsibilities within key roles to manage the corporate dependencies and preconditions.
To give an example… Where DSDM would plan and actively manage communication with senior stakeholders in a way that they were comfortable with, normally by written progress and status reports, Scrum would simply expect those stakeholders to attend daily Scrum meetings if they were really interested in keeping themselves informed. Two approaches, both with their merits but one a revolution in the way of working, the other an accommodation of corporate ‘normality’.
Key Similarities between DSDM and Scrum
-
Both DSDM and Scrum are defined Agile approaches, originally and primarily applied to the business of software development.
-
Both approaches have iterative development and incremental delivery at the heart of their respective software development processes.
-
Neither DSDM nor Scrum attempt to tell developers how to code, although both successfully inter-operate with eXtreme Programming, an agile approach with real weight and value in the software engineering discipline.
-
Representatives of both approaches contributed to the creation of, and are signatories to, the Manifesto for Agile Software Development and demonstrably value:
-
People and Interactions over Processes and Tools
-
Working Software over Comprehensive Documentation
-
Customer Collaboration over Contract Negotiation
-
Responding to Change over Following a Plan
-
And some differences…
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.
|
Scrum
|
DSDM
|
|
The Scrum approach describes a very simple process involving three roles working with a handful of products.
|
DSDM is a more expansive process that is richer in terms of defined products and roles.
|
|
The Scrum process is focused purely on product delivery, providing an elegant and effective means for translating software requirements into a software product.
|
DSDM covers the full project spectrum where required and integrates business process development and change with agile software development within a comprehensive project framework.
|
|
The low visibility of key disciplines such as project management and testing in Scrum present challenges in the implementation of the approach in larger organisations
|
DSDM is a ‘corporate friendly’ agile approach. It makes key disciplines visible in the roles and elements within the standard lifecycle and the product set provide necessary hooks and interfaces for Governance and Reporting.
|
|
The low level of formality in Scrum around Governance and Reporting also present challenges
|
|
|
Scrum strongly advocates self-managing teams in which the ScrumMaster acts primarily as a facilitator, helping the team solidify its roles and responsibilities as well as ‘running interference’ on any corporate standards, customs, practices and politics that may have a negative impact on team productivity.
|
DSDM was designed to fit into a corporate environment. The DSDM Project Manager is expected to provide direction and guidance to the team without stifling the agility that makes the approach so effective. DSDM expects self-management of teams within a defined framework of empowerment.
|
|
Scrum is primarily aimed at projects involving a single small team. It can be scaled up but the mechanisms for doing this are not clearly defined as part of the core framework.
|
Whilst the ‘engine’ of development in DSDM is based around single small teams, scalability is built into the core process by: a) establishing firmer, more formal foundations at the outset than Scrum advocates and b) describing specific responsibilities of key roles to this end.
|
Inter-operating Scrum and DSDM
In deciding whether the DSDM process might be used as an alternative to Scrum, or perhaps to augment it, it is important to look at the drivers within the organisation for the project as well as the corporate environment within which the project exists.
A business change project in a medium to large enterprise that has a significant software development component will probably lend itself more readily to a DSDM approach than a Scrum approach.
A product development project focused on creating or enhancing a software tool for use by external clients might thrive better under the lighter touch of Scrum.
In an organisation already familiar with Scrum but struggling to fit development into a more traditional corporate culture, a blending of the two approaches might be the best solution.
The DSDM process framework
The parts of the DSDM lifecycle related to development, and therefore the parts that overlap with the Scrum process are the Functional Model Iteration (FMI) and Design & Build Iteration (DBI) phases. FMI and DBI phases may be operated discretely, in which case the former is focused on construction of software that demonstrates comprehensive understanding of requirements and the latter is focused on engineering the software to the level of technical quality required for full live use.
FMI and DBI phases may also be merged into a single iterative phase that both demonstrates understanding and produces fully engineered software.
Regardless of whether the phases are combined or not, all iterative development work in DSDM is carried out in a series of timeboxes, controlled at the detail level through daily team meetings. Each timebox takes as an input the output of the previous timebox (if any) and an agreed subset of the requirements and delivers working software as an output, along with any products required to support that software (e.g. design models, test scripts, user documentation)
The Scrum process
The Scrum process comprises two fundamental cycles: The 30 day Sprint, which is a direct analogue of the DSDM timebox and the daily Scrum cycle, the defining feature of which is a team meeting (the Scrum itself). Like DSDM, Scrum takes the output of a previous Sprint and a subset of the requirements (or Product Backlog) and delivers working software.
It would appear then, that the Scrum process can be substituted for the DSDM FMI and/or DBI development cycles but DSDM development process is intended to integrate with and be governed by wider project perspectives and commitments.
One key differentiator between DSDM and many of the other Agile development process lies in the way it embraces the wider project environment. DSDM assumes that the time, resources and quality parameters for a given project are fixed before development starts and defines a software end product at a high level to be delivered within these constraints. The detail of exactly what the requirements are and how they will be reflected in the solution are allowed to evolve over time to create the product agreed in outline at the outset.
With time, resource and quality fixed, the remaining parameter, the scope of what is delivered, is actively managed in DSDM at the level of the timebox.
The requirements for the project as a whole are prioritized at the outset using the MoSCoW prioritisation technique that defines the requirements that Must, Should, Could and Won’t be met as part of the agreed release of the software.
DSDM defines the priorities thus:
-
Must have for requirements that are fundamental to the system. Without them the system will be unworkable and useless. The Must Haves define the minimum usable subset. A DSDM project guarantees to satisfy all the minimum usable subset.
-
Should have for important requirements for which there is a workaround in the short term and which would normally be classed as mandatory in less time-constrained development, but the system will be useful and usable without them.
-
Could have for requirements that can more easily be left out of the increment under development.
-
Want to have but Won't have this time for those valuable requirements that can wait till later development takes place.
The MoSCoW prioritisation technique is also applied at a more detailed level for each timebox thus ensuring that the most important requirements for the project are addressed in the most sensible way to deliver an end product that will be ‘fit for business purpose’ on the day of delivery.
The DSDM Team Leader (who, in the context of a self-managing team, is elected by the team) is responsible for ensuring that the team delivers working software by the end of each timebox that meets at least the Must Have requirements, probably the Should Have requirements and possibly some of the Could Haves too. The DSDM timeboxing technique provides a controlling framework for iterative development with regular reviews for both technical and business acceptability of the solution built into the process.
The MoSCoW Prioritisation and Timeboxing techniques are unique to DSDM and add a dimension of control over development that other Agile approaches either lack or deal with less formally. Anybody considering the inter-operation of DSDM and Scrum should consider carefully how project objectives will be met if these techniques are not applied when the Scrum process is substituted for DSDM’s timeboxed FMI and DBI phases.
In conclusion
Where there is a need (whether real or just perceived) for overt project management of an Agile project, then DSDM is the most comprehensive and safest approach to use. It respects and accommodates the needs of the organisation whilst guarding against corruption of Agile best practice. For development, the iterative and incremental timeboxed process accommodates multiple teams working in parallel, with the outputs of the Business Study setting the parameters for both technical and business representatives who are actively involved in the process. At the project level, governance and reporting interfaces are handled by the Project Manager, business direction is provided by the Visionary and all aspects of technical quality and cohesion across teams is handled by the Technical Coordinator.
If required, the Scrum process can be substituted for the timeboxed FMI and DBI phases in DSDM. This may be particularly valuable for organisations who have already made a significant investment in Scrum and have had success with it but perceive a need for more formality to help position projects in a corporate context and demonstrate the benefits of Agile development in a way that business sponsors and senior stakeholders understand.
Please let us have your feedback on this article