Chapter 6: Process
Previous chapter: 5 Preparing for success
6 Process
6.1 Overview
In line with the DSDM philosophy that
“the 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 approach to development and delivery is both iterative and incremental, with the most important business needs typically being addressed early while less important features are delivered later. The iterative nature of DSDM enables business representatives to see the solution as it evolves, to provide feedback on it and to request changes throughout the development of the solution.
Unlike most Agile approaches, DSDM integrates project management and product development into a single process. For many organisations, DSDM is all that is needed, although some gain value from integrating DSDM with other methods e.g. project management methods, such as PRINCE2™ and PMI, or software engineering practices, from eXtremeProgramming (XP).
Figure 6a: The DSDM process
The DSDM process model comprises a framework which shows the DSDM phases and how they relate to one another. This process model is then used by each project to derive their lifecycle.
The project process, as shown in the figure above, has four main phases: Feasibility, Foundations, Evolutionary Development and Deployment.These are preceded by the Pre-Projectphase and followed by the Post-Project phase, giving six phases in total. All phases are formally defined later in this chapter in terms of their purpose and what needs to be in placebefore they can be successful.
6.2 Pre-Project Phase
In line with the DSDM Philosophy
“that best business value emerges when projects are aligned to clear business goals”
the Pre-Project phase ensures that only the right projects are started, and that they are set up correctly, based on a clearly defined objective.
6.3 Feasibility Phase
The Feasibility phase is intended primarily to establish whether the proposed project is likely to be feasible from a technical perspective and whether it appears cost-effective from abusiness perspective. 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 itis unlikely to be viable.
6.4 Foundations Phase
The Foundations phase takes the preliminary investigation from Feasibility to the next level. It is intended to establish a fundamental (but not detailed) understanding of the business rationale for the project, the potential solution that will be created by the project, and how development and delivery of the solution will be managed. By intentionally avoiding low levels of detail, the Foundations phase should last no longer than a few weeks - even for large and complex projects. The detail associated with requirements, and how they should be met as part of the solution, is intentionally left until the Evolutionary Development phase of the project.
It may sometimes be necessary to revisit Foundations after a Deployment phase. The decision to revisit Foundations may be planned in from the start of the project; for example, on aproject where the business environment is sufficiently dynamic that the Foundations are expected to encounter significant change during the life of the project. Alternatively, the decision to revisit Foundations may be taken after a Deployment has produced an unexpected outcome.
Returning to the Foundations phase to re-affirm and, where necessary, refine the foundations of the project normally takes significantly less time than establishing them in the first placeand may be as short as a single Workshop.
For smaller, simpler projects, the Feasibility and Foundations phases can often be merged into a single phase.
The aim of Foundations is to understand the scope of work, how it will be carried out, by whom, when and where. The Foundations phase also determines the project lifecycle by agreeing how the DSDM process will be applied to the specific needs of this project.
6.5 Evolutionary Development Phase
Building on the firm foundations that have been established for the project, the purpose of the Evolutionary Development phase is to evolve the solution.
The Evolutionary Development phase requires the Solution Development Team(s) to apply practices such as Iterative Development, timeboxing, and MoSCoW prioritisation, togetherwith Modelling and Facilitated Workshops, to converge over time on an accurate solution that meets the business need and is also built in the right way from a technical viewpoint.
Working within Timeboxes, the Solution Development Team create Solution Increments, iteratively exploring the low-level detail of the requirements and testing continuously as they move forward.
6.6 Deployment Phase
The objective of the Deployment phase is to bring a baseline of the Evolving Solution into operational use.
The release that is deployed may be the final solution, or a subset of the final solution.
Some examples of what can be deployed are:
- Business change - introducing a new way of working into a factory (deploying a business change as a single release)
- The early deployment of a corporate intranet, providing a limited number of features, with more features to be provided later (deploying the first release of many)
- A complex product - e.g. the launch of a new mobile phone, bringing together par ts of the solution from multiple projects run in different locations (deploying a new product as a single release)
The Deployment phase comprises three main activities: Assemble, Review and Deploy. In addition, after the last release, the project is formally closed.
6.6.1 Assemble
Before a physical deployment, there are usually activities that take place to ensure that what is being delivered is coherent.This may also include bringing together any relevant supporting information. Assemble encompasses the work to “bring together” what is to be released.
On a small simple project, the work involved during Assemble may be minimal. On larger more complex projects or programmes where multiple projects are feeding into a single release, the amount of work to assemble a number of Solution Increments into a single release could be significant e.g. combining a new business process, a schedule of training, user guides and a new IT solution.
6.6.2 Review
Once all the elements of a release have been assembled, in most circumstances there will be some form of “approval to deploy”.This will be based on a final review of the solution before it goes into operational use - to ensure the proposed release meets the appropriate standards and is complete enough to be viable. In a simple environment, this can be very informal – a basic checklist - but in a more complex environment, it may be as formal as a go/no-go checkpoint workshop.
At this point, the team also carries out a retrospective for the Project Increment, focusing on ways of working and potential areas for improvement.
Information from both the retrospective and the formal review of the product help shape plans for future increments and can be used to facilitate learning across projects within a portfolio.
6.6.3 Deploy
Once approval has been given, Deploy is the physical act of putting what has been assembled (the release) into operational use. It includes any technical work, such as transfer of the solution into the live (production) environment, but also the enactment of any plans for business change.
6.6.4 Closing the project
After the final Deployment, the project is formally closed. At this point, the whole team hold a retrospective to review the overall project performance, both from the technical and/or process perspective and from the business perspective.
6.6.5 Deployment and complexity
A release may encompass one or more Solution Increments and can also span one or more projects.This means that the Deployment phase may be a simple or a complex activity. How deployment is done varies from organisation to organisation, and from project to project. For many organisations, decisions about how deployment is handled are imposed by the organisation itself, and are not negotiable by an individual project.
There are two common scenarios for deployment:
- Deployment phase is under the control of the project; or
- The project has control of Assemble and Review but not the final Deploy activity
6.7 Post-Project Phase
After the final Deployment for a project, the Post-Project phase checks how well the expected business benefits have been met. Although it may be possible to highlight immediate benefits, most benefits will accrue over a pre-defined period of live use of the solution.
The Post-Project phase produces one or more Benefits Assessments for these realised benefits in relation to the business case. Benefits may be assessed for individual releases (in which case the assessment of benefit should start before the Post-Project phase is reached), for the whole project or may be omitted completely, depending on the needs of the organisation.
6.8 The Lifecycle in Practice
Whilst there is a clear progression of phases from Pre-Project to Post-Project in the process diagram above, there are also arrows indicating a return path within the process, specifically the arrows from Deployment to Foundations and from Deployment to Evolutionary Development. The process shows the framework and the options available, and then each project derives their lifecycle from this process.The lifecycle for a project is determined by factors such as the number of intended Project Increments and other external influences, such as the stability of the business environment and endurance of Foundations decisions. The lifecycle for the project is defined and agreed as part of the Foundations phase.
6.9 Configuring DSDM for Scalability and Formality
DSDM recognises the real value of Agility in terms of project productivity and solution quality while acknowledging and accepting the necessary constraints that often exist when working in a corporate environment. Such constraints may include financial governance, architecture and/or infrastructure strategies, regulatory governance, vendor agreements and third party support considerations.
The DSDM process can be configured and calibrated to cater for a range of projects: small projects with light governance, larger projects which need stronger governance.Typically this is achieved by configuring a lifecycle appropriate for a specific project and determining an appropriate level of formality with which the DSDM products are defined, created and approved.
With regards to scaling, the project organisation can easily be refined to support multiple teams, with key roles acting as directors and coordinators across the teams. To support a more complex project structure, products such as the Solution Architecture Definition, Development Approach Definition, Management Approach Definition and the Delivery Plan and Timebox Review Records can be made more elaborate and more formal than would be appropriate for smaller projects
6.10 Summary
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 products intended to support the evolution of the solution and the smooth running of the project.The DSDM Agile Project Framework is designed to work effectively with projects of varying size and complexity.Through the tailoring of its various products, DSDM ensures control is demonstrated to a level of formality appropriate to the organisation, thereby running a project so that all the benefits of Agile are achieved without compromising effective project governance.