Agile is a wide 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 principles and practices had already been used before. One of these approach to software development was RAD – Rapid Application Development. RAD did not gain much of a recognition in an agile community, so DSDM – Dynamic Software Development Method – was created.
To refresh our memory, here are the key principles of Agile Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
What is DSDM?
It is a method for developing products or services in the spirit of the Agile project management 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 (agile project 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 lifecycle.
The project life cycle in DSDM
The project lifecycle 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 business requirements and business objectives?
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 approach (repeating, looping, characterised by a greater number of shorter steps) and incremental approach (additional, adding) to software development. These practices are also used in DSDM principles.
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 agile development: even if the software 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 project team.
Creating documentation
There is a myth about Agile approach in 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 framework, 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 (iterative development), 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 larger 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 (project stakeholders): 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 complex projects with many variables and unknowns, and for innovative, large and long-term projects with continuous delivery pipelines. 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 firm 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 approach requires greater involvement and constant cooperation between the agency, product & service creators, and clients.
Participants in the development 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 agile 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 method, we mean SCRUM. However, SCRUM is just one of the methods, mainly used for completion of complex 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 Scrum Team, a self-organizing 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 developers team and the Project Manager, who is responsible for the schedule, budget and making sure that everyone does their job and ensures the customer satisfaction.
To wrap things up
DSDM is a great choice when you have a software development projects that requires a more structured approach (than eg. extreme programming) and involves multiple levels of responsibility. It is suitable for projects where the product vision needs to be clearly defined and aligned with strategic goals of business sponsor, and where there is a need for specific roles with defined responsibilities.
If you have a project that involves complex functionalities and requires a self-organising team, SCRUM might be more suitable. However, if your project requires a more structured approach with clearly defined roles and responsibilities, then DSDM would be the better choice. Ultimately, the decision of whether to use Agile – DSDM or SCRUM – depends on the specific needs and requirements of your successful project.