Purpose of this Guide
DSDM is a proven framework for Agile project management and delivery, helping to deliver results quickly and effectively.
Although DSDM works easily and effectively on small, simple projects, it has always maintained a strong focus on the corporate project-based environment to provide a “grown-up” approach to Agile in the complex, corporate world.
Choosing DSDM as your Agile Approach
Ever since its launch, DSDM has been at the forefront of scalable Agile projects and solution delivery. It is equally effective on small straightforward solutions or large complex corporate projects. DSDM has been used effectively on non-IT solutions and is not just about development of software.
In DSDM, the iterative approach encourages detail to emerge over time; therefore, the current step needs to be completed in only enough detail to allow the project to move to the next step with any shortfall in detailed understanding being dealt with in a subsequent iteration of development.
As a result, solutions are more likely to have a better fit with the true business need and are easier to test and easier to integrate into existing and emerging business processes. The development cost of most solutions is only a small part of the total cost of ownership; it therefore makes sense to build simpler solutions that are both fit for purpose on the day of delivery and easier to maintain and modify thereafter.
DSDM requires basic foundations for the project to be agreed at an early stage.
DSDM also describes a broader set of roles than most Agile approaches giving it a better fit with most corporate environments without compromising agility.
Philosophy and Fundamentals
The DSDM philosophy is that “best business value emerges when projects are aligned to clear business goals, deliver frequently and involve the collaboration of motivated and empowered people.”
The DSDM Philosophy is supported by a set of eight Principles that build the mindset and behaviours necessary to bring the philosophy alive. The principles are themselves supported by the People, an Agile Process, clearly defined Products and recommended Practices to help achieve the optimum results.
DSMS’s approach and style has always been founded on an underlying ethos of common sense and pragmatism.
Projects have to balance conflicting demands, and the four most common demands are: time, cost, features and quality.
Typically, in the traditional approach to managing a project, the feature content of the solution is fixed whilst time and cost are subject to variation. Quality also tends to become an unplanned variable primarily due to the fact that testing is typically left to the end of the project and, as a result of an attempt to make up for previous overruns, is either truncated in terms of testing effort or the time available to fix any defects identified.
By default, DSDM’s approach to managing the project fixes time, cost and quality at the end of the Foundations phase while contingency is managed by varying the features to be delivered. As and when contingency is required, the business roles identify the least valuable of the remaining requirements. These are then dropped or deferred in order to keep the project of track.
A DSDM project will always deliver a viable solution, on time and on cost, as long as the practices of MoSCoW and Timeboxing are followed.
The iterative and incremental approach to development ensures that the more important requirements are built to the agreed level of quality.
Principles
The eight principles of DSDM support DSDM’s philosophy.
Compromising any of the principles undermines the philosophy of DSDM and introduces risk to the successful outcome of the project. If a team doesn’t follow all of these principles then it won’t get the full benefit of the approach.
Preparing for Success
The following factors are seen as instrumental for positioning DSDM projects for a successful outcome. Where these factors cannot be met, they represent a significant risk to the DSDM approach.
It is important that all project stakeholders and participants understand and accept the DSDM project.
1. People are the heart of successful DSDM projects and the Solution Development Team is instrumental in ensuring the development of the right solution.
2. It is vital that the business is actively engaged and commits the necessary amount of time at all levels, and that this commitment is maintained throughout the project.
3. Each Timebox should ideally deliver a complete, potentially deployable increment of the solution.
4. Ensuring testing is fully integrated is key both to the reduction of project risk and to the success of the project.
5. Transparency is about making progress and ongoing work visible to all, providing clear and up-to-date information on the current state of work. Transparency underpins the demonstration of control.
The DSDM Process
Unlike most Agile approaches, DSDM integrates project management and product development into a single process.
The DSDM process model comprises a framework that shows the DSDM phase and how they relate to one another. This process model is then used by each project to derive their lifecycle.
DSDM provides an iterative and incremental process, with a total of six lifecycle phases. Each phase has a specific purpose, together with a number of defined projects intended to support the evolution of the solution and the smooth running of the project, through the tailoring of its various products.
The framework is designed to work effectively with projects of varying size and complexity.
The lifecycle phases are:
• Pre-Project Phase
• Feasibility Phase
• Foundations Phase
• Evolutionary Development Phase
• Deployment Phase
• Post-Project Phase
Roles and Responsibilities
People working together effectively are the foundation of any successful project. DSDM recognises this and assigns clear roles and responsibilities to each person in a project, representing the business interests, the solution/technical interests, the management interests and the process interests. Everyone involved in a DSDM project works very closely together in order to break down potential communication barriers.
Business Sponsor
This role is the most senior project-level business role. The Business Sponsor is the project champion who is committed to the project, to the proposed solution and the approach to delivering it. The Business Sponsor is specifically responsible for the Business Case and project budget throughout.
Business Visionary
This is a senior project-level business role that should be held by a single individual. More actively involved than the Business Sponsor, the Business Visionary is responsible for interpreting the needs of the Business Sponsor, communicating these to the team and, where appropriate, ensuring they are properly represented in the Business Case. The Business Visionary remains involved throughout the project, providing the team with strategic direction and ensuring that the solution delivered will enable the benefits described in the Business Case to be achieved.
Technical Coordinator
As the project’s technical authority, the Technical Coordinator ensures that the solution/technical roles work in a consistent way, that the project is technically coherent and meets the desired technical standards.
The Technical Coordinator performs the same function from a technical perspective as the Business Visionary does from a business perspective.
Project Manager
As well as providing high-level, Agile-style leadership to the Solution Development Team, the role is focussed on managing the working environment in which the solution is evolving. The Project Manager coordinates all aspects of management of the project at a high level and is expected to leave the detailed planning of the actual delivery of the product(s) to the members of the Solution Development Team.
It is usual that the Project Manager takes responsibility for the project throughout its duration.
Business Analyst
The Business Analyst is both active in supporting the project-level roles and fully integrated with the Solution Development Team.
Team Leader
The Team Leader ideally acts as the servant-leader for the Solution Development Team and ensures that it functions as a whole and meets its objectives.
Business Ambassador
The Business Ambassador is the key representative of the business within the Solution Development Team. During Foundations, the Business Ambassador has significant input into the creation and prioritisation of requirements, then provides the day-to-day detail of the requirements during timeboxed development.
During the Evolutionary Development phase of the project, the Business Ambassador is the main decision maker on behalf of the business.
Solution Developer
The Solution Developer collaborates with the other Solution Development Team roles to interpret business requirements and translate them into a Solution Increment that meets functional and non-functional needs of the business as a whole.
Solution Tester
The Solution Tester is an empowered Solution Development Team role, fully integrated with the team and performing testing throughout the project.
Business Advisor
Often a peer of the Business Ambassador; the Business Advisor is called upon to provide specific, and often specialist, input to solution development or solution testing – a business subject matter expert.
Technical Advisor
The Technical Advisor supports the team by providing the specific, and often specialist, technical input to the project, often from the perspective of those responsible for operational change management, operational support, ongoing maintenance of the solution, etc.
Workshop Facilitator
The Workshop Facilitator is responsible for planning, organising and facilitating workshops to ensure that a group of people collaborates to meet a predetermined objective in a compressed timeframe. The Workshop Facilitator should ideally be independent of the outcome to be achieved in the workshop.
DSDM Coach
Where a team has limited experience of using DSDM, the role of the DSDM Coach is key to helping team members to get the most out of the approach, within the context and constraints of the wider organisation in which they work.
DSDM Products
The DSDM Agile Project Framework describes a set of products to be considered as the project proceeds. These products describe the solution itself and anything created to help with the process of evolving it, and anything that is required to help with project governance and control.
Not all products are required for every project and the formality associated with each product will vary from project to project and from organisation to organisation.
Several of the products may also play a part in governance processes such as approval gateways.
The Terms of Reference is a high-level definition of the overarching business driver for, and top-level objectives of, the project.
The Business Case provides a vision and a justification for the project from a business perspective. The business vision describes a changed business as it is expected to be, incrementally and at the end of the project. The justification for the project is typically based on an investment appraisal.
The Prioritised Requirement List (PRL) describes, at a high level, the requirements that the project needs to address and indicates their priority with respect to meeting the objectives of the project and the needs of the business.
The Solution Architecture Definition (SAD) provides a high-level design framework for the solution. It is intended to cover both business and technical aspects of the solution.
The Development Approach Definition (DAD) 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 quality of the solution will be assured.
The Delivery Plan provides a high-level schedule of Project Increments and, at least for the first/imminent Increment, the Timeboxes that make up that Increment.
The Management Approach Definition (MAD) reflects the approach to the management of the project as a whole and considers, from a management perspective, 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.
The Feasibility Assessment provides a snapshot of the evolving business, solution and management products; as they exist at the end of the Feasibility phase.
The Foundations Summary provides a snapshot of the evolving business, solution and management products; as they exist at the end of the Foundations phase.
The Timebox Plan provides depth and detail for each Timebox identified in the Delivery Plan. It elaborates on the objectives provided for that Timebox and details the deliverables of that Timebox, along with the activities to produce those deliverables and the resources to do the work.
The Timebox Review Record captures the feedback from each review that takes place during a Timebox.
The Project Review Report 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.
The Benefits Assessment describes how the benefits have actually occurred, following a period of use in live operation.
It is critically important to remember that DSDM products are only created if and when they add value to the project and/or to the solution it creates.
If documents genuinely help achieve this then create them, if not, don’t waste valuable time and effort doing so.
DSDM Practice – MoSCoW Prioritisation
In a DSDM project where time has been fixed, it is vital to understand the relative importance of the work to be done in order to make progress and to keep to deadlines. Prioritisation can be applied to requirements/User Stories, tasks, products, acceptance criteria and tests, although it is most commonly applied to requirements/User Stories.
MoSCoW is a prioritisation technique for helping to understand and manage priorities. The letters stand for:
• Must Have
• Should Have
• Could Have
• Won’t have this time
Must Have: these provide the Minimum Usable SubseT (MUST) of requirements that the project guarantees to deliver.
Should Have requirements are defined as: “Important but not vital”
Could Have requirements are defined as: “Wanted or desirable but less important”
These are the requirements that provide the main pool of contingency. When a problem occurs and the deadline is at risk, one or more of the Could Haves provides the first choice of what is to be dropped from this timeframe.
Won’t Have this time: these are requirements that the project team has agreed will not be delivered (in this timeframe). They are recorded in the Prioritised Requirements List where they help clarify the scope of the project. This avoids them being informally reintroduced at a later date. This also helps to manage expectations that some requirements will simply not make it into the Deployed Solution, at least not this time around.
DSDM Practice – Timeboxing
DSDM defines a timebox as a fixed period of time, at the end of which an objective has been met. The Timebox objective is usually completion of one or more deliverables making up a Solution Increment. This ensures the focus for a Timebox is on achieving something complete and meaningful, rather than simply “being busy”. At the end of a Timebox, progress and success is measured by completion of products (requirements or other deliverables) rather than completing a series of tasks.
The optimum length for a Timebox is typically between two and four weeks – long enough to achieve something useful, short enough to keep the Solution Development Team focussed.
By managing on-time/on-target delivery at the lowest level, on-time and on-target delivery at the higher levels can be assured.
Every Timebox begins with a Kick-Off and ends with a Close-Out. Beyond this, DSDM recognises two styles of Timebox:
• A DSDM structured Timebox
• A free format Timebox (similar to those in other Agile approaches)