Dynamic System Development Model

The philosophy of DSDM is founded on 8 key principles, these drive the mindset to set the philosophy for the approach. This is embodied by everyone in the project and communicated clearly.

Principles form the foundation for the Philosophy (or the roof) these underpin the mindset for the approach. The principles are underpinned by 4 pillars.

This forms the Agile journey for the organisation in terms of the processes adopted. The incremental and iterative approach to the evolving solution.

The people are the most important component after all its the people that do the work. In DSDM roles and responsibilities are clearly defined and are part of the evolving solution.

DSDM has a defined set of products these range from a simple Business Case , Development Approach Definition to a Benefits assessment. The suite of products supports the full end to end of all phases.

DSDM contains a host of practices that are advocated to improve the quality for decision making for example,MoSCoW prioritisation or to promote transparency such as Daily Stand-Ups, or practices in the way work should be delivered by using Timeboxes.

The foundations for the house are common sense and pragmatism, this ethos elevates upwards and each pillar and philosphy throughout. Pragmatism revolves around an approach that evaluates theories or beliefs in terms of the success of their practical application.

The focus on the business need is imperative during the lifetime of the project. This ensures that was is delivered has business or economic value, it also aligns development teams to the needs of the business.

Delivering on an agreed time is vital in a DSDM project, delivery date cannot be compromised.

Collaboration accelerates clarity and understanding to resolve ambiguities.

Quality is fixed and non-negotiable and is not compromised during the lifecycle of the project. The minimal viable product once agreed would require full committment to achieve.

Before any development can start, the project will make sure that there is enough detail for the evolutionary phase to begin. There needs to be just enough information for the build to start.

This focuses on the iterative apporoach to development in form of timeboxes and review ceremonies identified during a project increment. Building iteratively results in a more focused delivery aligned to the needs of the business.

Communication is a key agile principle and is embedded during the DSDM framework.

Controls towards Inspection and transparency is a pre-requisite, and starts from the very offset for a project.

This is a very high level scope for the project similar to Term of reference, there is a clear high level objective for the project which gives details on what the project is about and what will be its main deliverables. The contents are very lean and concise.

The feasibility is used to determine the business and technical viability for the project. There is also a key check point to determine whether its viable to proceed at the initial stage for the project.

The high level rationale for the project is descried here, with details given on what shape the work would like, who are the participants and the committance to resources and the capacity for the planned increments.

This follows the foundation phase where three main activities take place Iterative development, Timebox and MoSCow prioritisation. The evolutionary development is split into 3 parts: the Assemble, Review and Deploy.

This stage involves the deployment for the baseline code created as part of the increment of Done.

This stage assesses the business benefits for the projects and any learnings given.

The Business Sponsor is the person that approves the business case for the project and has express ownership for the funding. All funding is approved and sponsored by them so holds a good level of accountability on whether project has met project objectives set from the offset.

The Business Visionary works alongside the sponsor to determine a clear vision for the project from business perspective that the DSDM team will align to. They promote the strategic direction for the project.

The Technical coordinator is responsible for the technical aspects for the project that the team will support and build from.

The Project manager coordinates all management aspects and activities for the duration of the project. They liaise closely to the Business Visionary and Technical coordinator as well as the Solution Delivery Team. They are also responsible for the delivery plan and plan for increments. They ensure the project is on track and will escalate any delays.

The Business Analyst is a very unique role in that they sit between the project level roles and the solution development team. They help the Visionary to formalise the requirements, or in the Sponsors case assist to write a Business case. For the Solution development team they will be involved in scoping the user-stories or supporting the development team during timeboxes.

The business ambassador is responsible for the creation and prioritisation of the requirements. They work very closely with the Business Visionary to ensure that the requirements are non ambiguous and fully understood. On the flip side the also work with the Team Leader to ensure the user stories are understood by the development team and can realistically deliver what is being asked of them.

The Team Leader is the servant Leader for the Solution development team. There objective is to make sure prioritised items are understood and committed by the development team. Their job is also to remove any impediments that may disrupt the developers from completing their tasks.

The developer is part of the Solution Development Team and will develop part of the solution increment and will provide the lowest level emerging details from the requirements provided.

The Tester is part of the Solution Development Team and creates test cases or scenario's and both functional and non-functional testing.

The Technical advisor is a 3rd party support that the development team may be dependent on to support activities or specialisms.

The Technical advisor is a 3rd party support that the development team may be dependent on to support activities or specialisms.

The workshop facilitator sets up workshops to support the facilitation for DSDM activities. Workshops can be in the range of trasferring process knowledge related to requirements, supporting issues that require a workshop for group analysis or prioritisation. Its important to emphasize that

An DSDM coach helps a team to mature during their Agile journey both inside and out of the Solution Development Team.

The business Case is a concise justification for the project in terms of the main objective and what it is setting out to achieve. The senior management will set out to approve this before the project can be started. Once the Business Case is formulised there is a decision of whether a feasibility is required or not. This is created by the Business Analyst on behalf of the Business Sponsor.

Prioritised List is a list of all requirements to be committed by the Solution Delivery Team as per priority. It is similar to a Product backlog which is an ordered list of requirements are created by the Business Ambassador on behalf of the business. The backlog will evolve as the detail becomes clear, so will require grooming to ensure user-stories are relevant and up to date. The owner of the backlog items is the Business Visionary. The Business Ambassador prioritises items of the backlog but its the Business Analyst who produces the requirements.

The feasibility assessment is a checkpoint to give the necessary approval of the feasibility stage and whether to progress to the foundations stage. This is often a no-go call or a brief document. This document is created by the Project Manager and the Business Sponsor is responsible for it.

The Foundation Summary is a checkpoint to give the necessary approval of the Foundation phase and whether to progress to the Evolutionary development and there is a return on investment. This document is created by the Project Manager and the Business Sponsor is responsible for it. At this stage all the products that have been created at this point must have the right level of detail to progress to the Evolutionary development stage.

The Management Approach document is a high level document that defines the business and protocols that the DSDM team wil adopt. This document provides guidance on various business aspects of the project, for example dealing with third party suppliers, contractural agreements, working hours and planning of activities. This document is produced by the Project Manager.

The delivery plan lists the high level details for each of the timeboxes in the increment. This gives the solution Development Team a plan for the activities that are required for the upcoming timebox. The actual details for the tasks are filled in during the the timeboxes. The project manager is responsible for this document.

The Timebox plan contains the highest level of detail for the development timeboxes that are outlined in the Delivery Plan. The planning of all development tasks during the timebox are detailed here, as well as the objectives or goal for the development. The Timebox plan is owned and created by the Solution Development Team.

A timebox review record is an retrospective on how activities went during the development timebox and what challenges or impediments had occured. These are discussed as part of the Solution Development Team and the objective is to provide feedback so that the issues may be resolved in future timeboxes. This review is produced by the Team Leader.

The Project Review Record is a business review for the project increment to detail what has been achieved and not achieved during the project increment. A retrospective occurs which highlights the learnings from the previous increment to determine what can be done better next time. The project review report is an important document to assist with the Benefits assessment. This document is created by the Project Manager.

The Solution Architecture Document provides the architectural blueprint for the product design. This is a high level document that addresses both business and technical components of the project, such as database platform, cloud technology or Distribution mechanism. This is created by the Technical Coordinator and the help of the Business Analyst.

The Development Architecture Document provides the tools, techniques and stndards by which the product implementation will be delivered. This is a high level document that focuses on the development and testing strategies that are to be applied by the Solution Development Team. This is created by the Technical Coordinator and approved by the Project Manager.

The Benefits assessment is a review to identify whether the project delivered the return on Investment for a given project increment. The assessment will also look at whether the increment objectives were met and what benefits were accrued as a result. The Benefits assessment is created by the Business Visionary.