The word “project” has a certain negative connotation in some agile environments. Years of failures in waterfall project are mostly to blame, and the meaning of “project” in IT environments has ended up being associated with something bothersome, strict and with inflexible dates. As a result, the figure of the Project Manager has been stigmatised as an authoritarian boss, who treats individuals as resources and leads with a command & control style. Even initiatives such as #NoProjects have made this focus their framework, despite the true meaning of #NoProject “focusing on the team”.

Scrum is great. It is a very powerful working framework, ideal for constructing complex products, and is certainly the most widespread in Agile. However, it is not easy to apply, and the Scrum guide itself tells us that it is “difficult to master”. Two of the difficulties reported to me by students from our Scrum courses and organisations that we have helped to implement it are the difficulty of applying it, and what to do between deciding to start the project and having the team formed to start development. Techniques such as Agile Inceptions help us to make this period of time as short as possible. Applying Scrum, we could include it as part of the first Sprint, and deliver software, finishing in 30 days or less. However, Scrum does not detail what other roles may participate in this process, or what activities to carry out (and also does not detail what activities to carry out for development or testing).

In this sense, DSDM is differentiated from Scrum (and other agile frameworks), requiring minimum steps to design, approve and initiate the development of the solution. One of the principles that we explained in the previous article is Build Incrementally from Firm Foundations. To have a good basis, DSDM proposes first analysing viability, and then agreeing expectations on the business, technical solution and management model.

The phases of the lifecycle of the DSDM Agile Project Framework process are as follows:

Pre-project. Ensuring that the organisation only begins suitable projects, with a clear objective. This is a vision of the Portfolio in which it must be decided what to invest in based on the strategy of the company.

Feasibility. Analysing the technical viability of the project along with a minimum cost-benefit analysis to stop at this point or continue. This is the initial form of the project.

Foundations. Establishing the bases of the project, without going into detail, to understand the potential solution to create, and how the development and management of the project will be carried out. This should take days or weeks at most, even for large and complex projects. The objective is to understand the scope of the work at a high level, and how we will execute it, who, when and where, and how much it will cost us. For small projects we can combine Feasibility and Foundations in a single phase of a few days.

Evolutionary Development. From the established foundations, the objective of this phase is to create and develop the solution. Short requirements oriented toward value, written, for example, in the form of User Stories, prioritisation with MoSCoW, using a 4 week timebox as a maximum (the shorter the better). The timebox format is similar to Scrum, establishing objectives and scope at the beginning, coordinating progress through daily stand up meetings, demonstrating the finished product at the end of the iteration, and reflecting with a retrospective. Testing is integrated in this phase, and we ensure that the developed increment satisfies the business needs and is correctly constructed.

Deployment. The objective of the deployment phase is to put the developed solution into an operating environment, available to users. It may be a partial solution or the final version. After the last production of the full solution, the project will be formally closed.

Post-Project. Once the deployment of a project is completed, the Post-Project phase reviews to what point we have achieved the expected business benefits. It may be carried out just afterwards, or several months later. It all depends on the plan for achieving benefits.

Warning. It may seem that it is a classic waterfall method of Analysis, Design, Development, etc., but there are several important differences that must be noted:

The duration of Feasibility and Foundations must be minimal, if possible in a timebox, reasonable for the size of the project. For example, if we have the Feasibility and Foundations phases and the first timebox in under 30 days, we are delivering finished software in periods established by Scrum. The Agile Manifesto suggests a few months at most. It all depends on the size. If we only make one delivery and complete the project, we will not be carrying out DSDM. This is waterfall and does not follow DSDM principles.

Testing is fully integrated in Evolutionary Development iterations. We do not leave testing until the end. DSDM is strict in designing a Testing strategy as part of the development process and categorises different types of test (collaborative, repeatable, prioritised, independent, TDD, etc.).

The Deployment is carried out frequently. Incremental deliveries, the sooner the better, and the more frequent the better. Being explicit in the Deployment phase does not mean that there is a single Deployment phase. It means that we must put the solution that we are developing into production, and must do so correctly, establishing a baseline for our solution, with the proper management of the configuration.

An example configuration of the lifecycle of a project with 5 iterations may be as follows:

Using DSDM, from the different phases we can design a roadmap of early and continuous deliveries for our project, implementing a solution incrementally, adapting from feedback obtained throughout the process, and reviewing that the expected benefits are being achieved.

An agile model may be of great help to organisations used to working on projects in changing their mentality and way of working to improve their capacity for delivering value and reducing the time to market.

Finally, don’t hesitate to learn more about our courses and certifications on AgilePM and AgileBA.