top of page

When should you use Agile – DSDM?

Agile is a whole range of agile methodologies for releasing a working piece of software or simply a working product/service. Although Agile was officially “established” in 2001 in the form of a Manifesto written by 17 people from the world of IT, agile practices had already been used before. One of these practices was RAD – Rapid Application Development. RAD did not gain recognition, so DSDM – Dynamic Software Development Method – was created.

What is DSDM?

It is a method for developing products or services in the spirit of the Agile philosophy/mindset, which offers proven solutions if we are constrained by a firm deadline and a fixed budget, while maintaining the quality of software development. It precisely assigns roles and associated responsibilities: project-level roles, solution development roles or supporting roles (those who have a say on a given issue) for the elements (management products) created during the course of the project.

These elements are divided into evolutionary products, which – as the name suggests – evolve over time, and milestone products, which complete a particular phase and enable the next step in the project life cycle.

The project life cycle in DSDM

The project life cycle in DSDM is divided into 6 phases. We won’t go into all the details, but the important thing is that each phase ends with identifying specific objectives and conclusions which determine whether the project can move to the next phase, bearing in mind the question: will this project provide a return on investment?

A major advantage of DSDM is the constant review of business goals, which are overseen by the so-called Business Visionary. This helps to increase the competitiveness of the product or service. The continuously reviewed objectives are incorporated into 2-4 week-long time frames called Timeboxes. So, the objectives may change and this is completely normal – in fact, change is welcomed. This way, we can be sure not only that the product or service developed is competitive, but also that we have more control over the entire process.

Each Timebox ends with a retrospective (review) during which the work is inspected – this is an important point at which we receive feedback from the Business and ask the questions:

  • did the project meet our requirements?

  • what was/was not achieved in this iteration and why?

Product development is accompanied by a whole spectrum of Agile forms of testing, e.g. Continuous Integration tests which ensure compatibility with previously developed pieces of software.

What sets the DSDM approach apart?

What constitutes the core of the DSDM approach compared to waterfall is the so-called set of variables which are fixed. In the traditional approach, these are the features, while the time, budget, and thus also the costs in case of frequent changes are often stretched and require “gymnastics” on the part of the software house in order to keep the project under control.

Simply put – in such circumstances, producing a product or service that meets 100% of the client’s objectives is a daunting feat. When you consider long-term projects, it’s not unusual for the assumptions and objectives to change. There may be various reasons for this: the project goal has changed, analysis has revealed that we should focus on a different aspect of the software, or we’ve simply changed our minds about the product’s appearance.

In this case, the DSDM approach provides a focus on quality, time and budget – the product features can change just as clients’ priorities change – and that is totally fine!

When talking about Agile methodologies, we cannot fail to mention the biggest difference – the iterative (repeating, looping, characterised by a greater number of shorter steps) and incremental (additional, adding) approach to software development. These practices are also used in DSDM.

Quality is therefore ensured by prioritisation as well as short time frames (Timeboxes) for the development of a working piece of software. This means, as I mentioned earlier, that the Business can give us continuous feedback to put us on the right track when implementing projects. There are a lot of benefits to this way of doing software development: even if the solution development team did not manage to meet the goals of a given Timebox, the budget won’t suffer as much as it would in the case of a project where feedback from the client is gathered after a few months, when it’s already too late to make changes as they will be too expensive. Thus, timeboxes also make work easier for the team.

Creating documentation

There is a myth about Agile software development when it comes to the creation of documentation. Typically, in the traditional approach, documentation, technical specifications, information architecture and other documents are created before carrying out the project. The scope of work is discussed in detail and solutions are created. This is the right approach for projects that we have already implemented several times, when we want to organise our system of work or make a list of processes to facilitate and automate work, e.g. when designing a website for the same client that fulfils similar objectives, or designing simple landing pages or mailings. DSDM, as opposed to certain Agile methodologies, states that we should create just the level of documentation that is sufficient for us – which does not mean that we should abandon documentation completely.

Another myth is that in Agile, as in DSDM, there is no project planning, no schedule. In DSDM, the opposite is true – you are constantly planning on an ongoing basis due to the changing assumptions and objectives. Only the method changes: in the case of traditional projects, a detailed schedule is drawn up and delivered at the beginning of the project. DSDM provides the “Enough Design Up Front” [EDUP] method – the upcoming iterations are planned in detail, while only a sketch/plan is drafted for the subsequent ones.

The idea behind this is that there is no need to plan work in detail many months or years in advance – it may turn out that the previous tasks solve a problem, or generate new ones that need to be included in the schedule, or it may turn out that some functionalities are no longer needed because they are not as competitive any more.

When should you use DSDM?

Conducting a needs analysis and listing assumptions before designing solutions, in the case of projects that carry a lot of uncertainty and unknowns, is a risky approach. DSDM constantly analyses the needs of clients – this is ensured by assigning the relevant Business roles: Business Ambassador, Business Visionary, Business Analyst and Technical Coordinator, as well as gathering feedback after each completed Timebox.

The creators of Airbnb didn’t plan the deployment of the app and taking their business global from the very outset, without checking whether their idea would actually meet the needs of people. Their initiative was born from a need and a gap in the market – Brian and Joe, after moving to New York, couldn’t find an apartment, and noticed that all the hotels were booked at that time. When they finally found a place, they decided to offer other travellers a “piece” of their floor. The idea was tested and it worked, so they decided to start offering their services on a larger scale.

The greatest advantage of DSDM is its continuous focus on the competitiveness of the product – therefore, DSDM will work well for projects with many variables and unknowns, and for innovative, large and long-term projects. We often think that if we have a clearly defined vision of the project and we set ourselves a goal, the only thing we have to strive towards is finishing on time and on budget. For projects where there is a lot of competition or for large-scale services, it’s important to keep up with the needs of the market. A project which seemed innovative three years ago may now be heavily outdated. However, that does not have to mean demolishing the foundations of the project and rebuilding it from the ground up; it could be a case of, for example, a few additional functions in already existing software. When implementing large, long-term projects, we can put together a team of 9 to 15 people, although the Solution Development Team can have a maximum of 9 people. It’s important to fill the appropriate roles at the Business, Solution Development and Support/Advisory levels.

How should you prepare for DSDM?

Things are not always so rosy, however, and although Agile methodologies, including DSDM, may seem to be the perfect remedy for all the pain associated with project delivery and software development, this approach will not work every time and everywhere. One of the greatest risks when implementing projects using the DSDM approach is having a team and people on the Business side who are unprepared for agile thinking. Agile requires greater involvement and constant cooperation between the agency, product & service creators, and clients.

Participants in the process must know and fulfil their roles and must be empowered to make decisions about their actions. A self-managing and self-organising team is essential. This does not mean that there is no place for a Project Manager role in DSDM. It’s true that the team organises its own work and suggests solutions, but the role of a PM is to ensure that everyone fulfils their role on time and in line with the estimations that they have committed to.

The difference between SCRUM and DSDM

Finally, I’d like to mention a few differences between another of the Agile methodologies – SCRUM – and DSDM. Often, when we talk about Agile, we mean SCRUM. However, SCRUM is just one of the methods, mainly used for completion of products. Meanwhile, it says more about the product creation process itself than about the entire project implementation process. SCRUM works really well in projects where software, applications, and websites with complex functionalities are created. Only 3 roles are involved in the process:

  • The Product Owner is responsible for the product vision and direction, and for user stories, i.e. developing functionalities for the product, as well as prioritising.

  • The Scrum Master is the person responsible for guarding the process, therefore they are also the one responsible for removing obstacles in the way of the programmers as they complete their task.

  • And a self-organising team of “T-shaped” people.

DSDM roles are significantly broader, and each role has clearly defined responsibilities. Roles are divided into three levels:

  • business – that is, people responsible for the product vision, strategic direction, and ensuring that the product is viable

  • solutions – roles responsible for delivering a solution in line with the direction of development

  • advisors – people responsible for supporting the solution development roles in decision-making, as well as ch facilitators and DSDM coaches responsible for good team work and understanding of the process.

The presence of the Project Manager is also a major difference: in SCRUM, the PO is responsible for delivering the product, whereas in DSDM, it is the solution development team and the Project Manager, who is responsible for the schedule, budget and making sure that everyone does their job.

bottom of page