Skip to main content

AgilePM® aka DSDM®

18 Aug 2017

| Author: Nigel Mossman


AgilePM® aka DSDM®

The reaction to mentioning DSDM® to people I meet in the industry tends to take two forms:

  • DSDM® – what’s that?
  • DSDM® – tried that in early noughties and we stopped using it because…

If you’ve never heard of it then you really ought to take a look and if you did use it in the past, it’s worth revisiting as much has changed in the latest version (launched in 2014).

If an organisation has looked at Scrum and found it’s limited in terms of governance roles or scalability, or perhaps would like to start using Agile in a more formal manner, then SAFe might be a good choice. However, DSDM® is also well structured, established, scalable, home grown and for organisations in which governance is based around traditional approaches, a more comfortable migration path.

DSDM® – Some key points

  • Emphasis on delivering the solution that the business needs and on time
  • Works for projects/product development of all sizes
  • Recognises a range of roles in an organisation
  • Project Divided into Phases with gates to only allow viable projects to continue
  • Use of MoSCoW and Timeboxing to guarantee a solution is always delivered
  • Strong governance framework – wide range of documents with a tailorable level of formality (can support highly regulated environments as well as start-ups). Even more powerful when complemented by IndigoBlue’s Adapt 2.0 Governance framework.
  • Can be implemented “out of the box” or can be adapted to work with Scrum (the Agile Business Consortium has published a guide on doing this). Equally, can be adapted to work alongside other in-house methods.
  • Training courses available – exams backed by the APMG who many will know via PRINCE2 certifications.

DSDM® – Roles

One of strong aspects of the method is the Roles and their engagement within the project. The limited number of Roles in Scrum is one its weaknesses.

Project Level Roles to direct and guide the project:

  • Business Sponsor – Responsible for the overall business case and senior enough in the organisation to resolve major obstacles.
  • Business Visionary – has the “Vision” of how the business will look after the new solution is delivered; this is not just about the technology solution; it’s a broader business change view.
  • Project Manager – responsible for overall planning, reporting and delivery management. This can include the business change aspects.
  • Technical Co-ordinator – Provides the technical vision for the project and is the ultimate technologist on the project. This role is responsible for ensuring that the right technical architecture and tools are selected for the project and that it’s built and tested in the right way.
  • Business Analyst (sits at the Project and Team levels) – At the Project Level helps create high-level requirements and supports the development of the business case. At the Team Level, helps the Team decompose high level requirements into implementable features in the form of stories.

Team Level Roles (as with Scrum, a team is ideally 7 +/- 2; a project can have multiple teams)

  • Team Leader – Usually takes one of the other roles but ensures the team is working well and co-ordinates (not manages) team activity.
  • Business Ambassador – Works with the BA and team to decompose features into stories, provides answers to question and crucially is empowered to accept stories as Done once completed. The Ambassador is a business expert seconded to the team; the person may change from increment to increment depending on what is being built.
  • Solution Developers – Builds the features and runs the associated unit tests.
  • Solution Tester – Not the only person testing. The Ambassador, Advisors and possibly the Analyst will also be testing; the Tester could be acting as a consultant to support the business roles and/or providing automation expertise.

Supporting Roles

  • Business Advisor – There will normally be several people taking this role on a part-time basis. They provide specialist business knowledge, so could be engaged for specific timeboxes or over the whole life cycle.
  • Technical Advisor – There will normally be several people taking this role on a part-time basis. They could be drawn from Operations or represent specialist areas such as Security or User Experience.

It’s possible to combine the roles so that one person performs several functions. For example, in a smaller organisation the responsibilities of the Visionary and the Sponsor could be combined.

In one organisation, we developed a new website to replace a site that was built in the late 1990s. The Sponsor was the Sales Director and sat on the Board, he owned the budget and could remove interdepartmental blockers when necessary. The Visionary ran the business unit in question, knew what the business unit was trying to achieve at a strategic level (i.e. more revenue from existing customers and attract new customers from other market segments) and what trade-offs would be acceptable, and what features we could leave for later increments etc.; he was also responsible for planning the launch of new products and how the new site would support the unit’s business plan.

The Business Ambassador (from Marketing) understood the products and how they were delivered to customer and could answer questions raised by Developers and BA at a level of detail (he collaborated with out tester regarding automation and accepted stories as Done).

My role combined the Project Manager and Technical Co-ordinator which allowed the team to focus on building the software as any good Agile team should (the team comprised a QA Engineer and three software engineers, one of whom was a Senior Developer acting as Team Leader). Over the life of the project we had several advisors who either provided specialist business knowledge on the products or ran the production servers, so could help us ensure we met their operation needs and standards.

The Project Manager role has disappeared in many agile methods, and perhaps with good reason. An Agile PM is different to the traditional Project Manager. In most organisations, no matter how lean, an element of administration, liaison, overall planning and general reporting is necessary. A project manager ought to be doing this collaboratively in support of the team.

There are many good reasons to look at DSDM®, do get in touch with us if you want to know more about this proven Agile method, or take a look at the Agile Business Consortium site.

Subscribe to receive our email updates


Author profile image

Nigel Mossman

Nigel has a wealth of experience as an architect, developer, tester, business analyst, business strategist and project/programme manager. He is an AgilePM Practitioner, has SAFe SA (V3 exams V4) qualifications, is an Agile Business Consortium-certified Agile Project Leader Practitioner and a DSDM Advanced Practitioner.


How can we help your organisation?

+44 (0)20 7692 4832

How will we use the information about you?

When you complete this form and submit your details, you are trusting us with your personal data. Our Privacy Notice informs you of what personal data we collect, why we collect it, and of your rights in relation to your data. By pressing submit, you indicate that you have read and accepted the terms of our Privacy Notice and that you consent to our processing of your personal data as described in the Privacy Notice.