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 then 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 who’s governance is based around traditional approaches, a more comfortable migration path.
DSDM® Some Key Points
- Emphasis on delivering the solution that the business needs & 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 PRINCE 2 certifications.
One of strong aspects of the method being the Roles and their engagement within the project. The limited number of Roles in SCRUM are one it’s 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.
- Business Advisor – There will normally be several people taking this role on a part time basis. They provides 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 Web Site to replace a site that was built in the late 1990’s. The Sponsor was the Sales Director and sat on the Board, he owned the budget and could remove inter-departmental 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 of a QA Engineer, 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 in collaboration with and support of the team.
There are many good reasons to look at DSDM®, do get in touch if you want to know more about this proven Agile method, or take a look at the Agile Business Consortium site (https://www.agilebusiness.org/).