I’ve highlighted a few key points from the DSDM Agile Project Framework for Scrum. I’d strongly recommend reading the 2014 White Paper produced by Andrew Craddock, Keith Richards, Dorothy Tudor, Barbara Roberts and Julia Godwin for the DSDM Consortium. Download the 22-page white paper. (DSDM is ‘The Dynamic Systems Development Method’.) The paper provides a useful summary of Scrum and Agile methodologies, and reflects on the integration of more granular sprint-focused methodologies with larger strategic project governance frameworks.
The usefulness of combining Scrum with DSDM
The Agile Project Framework for Scrum “brings together the strength of DSDM at project level and the streamlined simplicity of Scrum at the delivery team level”
Scrum is focused on the product rather than the project, “so more emphasis is placed on incremental release of a product in the context of a product lifecycle than is placed on formally ending development work after an agreed period of time.”
Documentation
DSDM ‘Foundations’ phase covers the full breadth of the project, but deliberately avoids going into detail. This is very different to the ‘Analysis and Design’ step in a waterfall approach.
The Agile Manifesto values values working software above comprehensive documentation.
The DSDM Agile white paper follows this: “break the illusion of security and stability that comes from document-driven, predictive processes. Specification of every detail of requirements, solution design, plans etc. in documents that get ‘signed off’ by stakeholders before work is allowed to progress is now widely accepted to be both wasteful, in terms of time and effort, and ineffective as the basis of governance and control. AgilePF for Scrum embraces the need for high-level versions of requirements, design and planning artefacts in the early phases of the project to frame development and delivery and to support governance.”
Collaboration over contract negotiation
“Typical commercial contracts assume that a traditional Waterfall process under-pins development and, accordingly, ‘a fixed price for a fixed specification’ is the standard for project contracts. Agile projects emphasise collaboration, and therefore contracts need to reflect this.”
Contracts should be “‘light touch’ and ‘guiding’ rather than being ‘detailed and prescriptive’.” “the Product Backlog may represent a contract, effectively defining the scope of a project. But it is cast at a high level and requires customer collaboration with less formality to flesh out the detail of requirements throughout the iterative development of the solution during the project lifecycle.”
Principles
- Focus on the business need
- Deliver on time
- Collaborate
- Never compromise quality
- Build incrementally on firm foundations
- Develop iteratively
- Communicate continuously and clearly
- Demonstrate control
Variables
Traditional approach:
Fixed: Features
Variable: Time, Cost, (in practice) Quality
AgilePF Approach:
Fixed: Time, Cost, Quality
Variable: Features
One of the four project variables must be flexible: “With proper planning, any three of the four project variables can be fixed provided one is allowed to vary.”
Agile PF fixed time, cost and quality and varies the scope of the features delivered.
To reach this point in the foundations phase, “an understanding of the high level features is required, sufficient to provide a sensible estimate for those aspects of the project that are fixed. At the same time, it is normal for a subset of the features to be identified as mandatory.”
Feasibility phase
Quickly established whether the project is likely to be technically feasible and cost effective from a business perspective before proceeding.
“The effort associated with Feasibility should be just enough to decide whether further investigation is justified, or whether the project should be stopped now, as it is unlikely to be viable.”
Plan for organisational/business change
“In the context of a project, the solution will include both the Product (often software) and any associated changes within the business wanting to exploit that product.”
Role of the Project Manager
“Managing an empowered team requires a facilitative style rather than a command and control style. It is usual that the Project Manager takes responsibility throughout the duration of the project. This must include both business and technical delivery aspects of the project, from establishing the foundations of the project through to the deployment of the solution.”