In the governance lifecycles entry in the Praxis Encyclopaedia we show that all the mainstream conventional guides use the same fundamental lifecycle – which is of course, also used by Praxis.
In this article we look at the life cycle of DSDM Agile. This is a project delivery framework developed and owned by the Agile Business Consortium (previously known as the DSDM consortium.)
Many people will probably assume that because it is ‘Agile’ it is somehow fundamentally different from guides that they perceive as promoting the ‘Waterfall’ approach – and they would be wrong.
Understanding that the ‘Agile project lifecycle’ is the same as traditional project lifecycles should not be a surprise if you understand that Agile, as it is usually promoted, is a development approach not a project management approach. The DSDM lifecyle addresses the full project lifecycle not just the development part.
At first sight there is no doubt that the DSDM lifecycle shown above (DSDM actually calls it the DSDM process) looks very different from the parallel version of the Praxis lifecycle below, but let’s look at it in detail.
Before the project lifecycle gets underway there is a ‘Pre-project Phase’ that is intended to ensure that “only the right projects are started”. For a stand-alone project kicked-off by a simple mandate, this is likely to be part of the Feasibility phase. Where a project is part of a programme or a portfolio the pre-project work should be performed as part of the programme management or portfolio management processes.
The first phase of the DSDM project lifecycle is Feasibility and this is primarily intended to “establish whether the proposed project is likely to be feasible from a technical perspective and whether it appears to be cost-effective from a business perspective.” This definition is identical in principle to the identification process in Praxis. In fact DSDM goes on to say that “the effort associated with Feasibility should be just enough to decide whether further investigation is justified or whether the project should be stopped now.”
Praxis refers to the identification phase resulting in an outline business case that takes a view on whether the project is desirable (‘starting the right project’ in DSDM), achievable (‘technically feasible’ in DSDM) and viable (‘cost-effective’ in DSDM).
The DSDM Feasibility phase and the Praxis identification phase are essentially the same thing.
The next phase in DSDM is the Foundations Phase. This management of this phase aligns closely with the definition phase in Praxis. The key thing about applying the phase in agile projects is simply the level of detail in the planning.
The phase is named Foundations in DSDM to emphasise the need to provide a firm foundation for the project, even though much of the detailed understanding of the scope and how to achieve it will not be determined until the Evolutionary Development phase.
The fact that the Foundations phase only plans at a high level means that with more information gained in the Deployment phase it may be necessary to revisit the Foundations phase. This is the only fundamental adaptation of the standard lifecycle to suit the agile environment.
DSDM initially states that the Evolutionary Development phase “[builds] on the firm foundations that have been established for the project, the purpose of the Evolutionary Development phase is to evolve the solution.”
Solutions are developed incrementally and deployed in the Deployment phase. Deployment of release of a solution does not mean it is the final solution, it just means that it works. There is always the option to iterate further if it adds value to the overall solution.
The DSDM Deployment and Evolutionary Development phases equate to the application of the delivery process and development process in Praxis. Just because a project is agile doesn’t mean that there are not controls, progress reporting, exception plans and so on. It’s just that different tools are employed within the phases. Timeboxes, backlogs, scrum, retrospectives and velocity are all tools that will be used – but the underlying structure of the phases is the same.
The DSDM process does not explicitly show a closure phase but it does say in its description of the Deployment Phase that “After the last release, the project is formally closed”. There is an implicit use of the Praxis closure phase here.
DSDM then goes on to say that the Post-Project phase “checks how well the expected business benefits have been met.” This is a very significant statement.
Firstly, it implies that the Deployment phase incorporates the benefits realisation phase shown separately in Praxis. Secondly, it reinforces the fact that approaches labelled ‘Agile Project Management’ talk a lot about the value of benefits being central to the purpose of the iterative process. This contradicts the approach of some conventional guides that maintain projects only deliver outputs not benefits. It also supports the Praxis approach which says that benefits realisation is just as likely to be part of a project as it is a programme.
Hopefully, I have made the case for the DSDM Agile life cycle being fundamentally the same as the lifecycle used in all other guides. If you disagree, please let us know via the ‘comments’ button at the top of this page.
