The Elevator Pitch

An agile method that offers a full life cycle, clearly defined roles for all those that need to be involved in a  project, in built process and product quality, governance support, can be configured to complement other methods in our organisation and with a clear focus on delivering software that meets the business need on time and at a known cost.

Background

When I mention DSDM I get the following reactions:

• DSD what?
• What’s that?
• I think the company I was working tried and it around 2001 and it petered out for some reason or the other

DSDM (which at one time stood for Dynamic System Development Method) started life back in the mid 1990’s and has had several revisions over the last 20 years.  It saw some early take up in government and large corporations but I suspect as the world was new to agile and DSDM used to be quite complex it petered out.  Revised as “DSDM Atern” in 2007 and again in 2014 where the silly “Atern” branding was removed  and replaced with AgilePM.  DSDM is now an Agile method that is flexible and offers a broader model than SCRUM.

These days APMG International (the organisation best known for offering exams in Prince 2) offers AgilePM as it’s defacto agile qualification, and this means that many corporate Agile project managers and team leaders have and will be learning the method.  I recently saw a reference to 53,000 people having taken DSDM AgilePM exams.

Other Methods

SCRUM is at the core of SAFe and LeSS – if an organisation has a number of SCRUM teams running then DSDM can be adapted to sit alongside.  The Agile Business Consortium (formerly the DSDM Consortium) have publications describing how this can be done.

Unlike SAFe which comes with a prescription implementation, DSDM can customised to use varying levels of formality and be customised to use the elements that make most sense.

More about DSDM

8 principals guide DSDM’s operation, however, the first two set the tone for the method.  Building the right product and delivering it on time.  Features the one thing that can be varied, DSDM allows for a core product (the Minimal Usable Subset).

• Focus on the business need
• Deliver on Time
• Collaborate
• Never compromise quality (DSDM builds in process and solution quality)
• Build Incrementally from Firm Foundations
• Develop Iteratively
• Communicate continuously and clearly
• Demonstrate Control.  This about transparency of the work to all interested parties and ensuring the team have a firm understanding of what they are trying to do and how the are doing it.

Phases

DSDM suggests that projects are broken up into phases:

• Pre-Project
• Feasibility
• Foundation
• Evolutionary Development
• Deployment
• Post Project

The aim here is put some structure around projects – pre-project is where the business formulates the idea for a project and puts a brief (Terms of Reference) together for a team to investigate the project.  Feasibility is a short (1-2 week phase even for a large project) to give an indication if the project could be delivered both technically and at a cost that makes financial sense.   This phase is about walking away from a project quickly and cheaply if doesn’t stack up, or at least moving ahead with  eyes open to the potential  risks – or even better an early strong indication that the project can be delivered with minimal risk/costs.

Assuming the project is signed off, the project can proceed to foundations where requirements are at least developed to an Epic level,  R&D can be undertaken to determine how the solution will be built (enough up front design not big up front design) and also to how the business will need to change as the solution is delivered (it’s not just about the software!).   At the end of Foundations, the team will have base-lined:

• a prioritised high level set of requirements
• governance documents (these are not expected to be large or onerous and cover management, delivery, architecture and testing approach)
• Indication on costs and timescales for the whole project.
• detailed plans for the first increment (which may have one or more real world deployments).
• a view on risks and uncertainties

At this point the business can either decide to proceed or stop the project.

Evolutionary Development is where development works takes place in timeboxes (Sprints in SCRUM).  DSDM offers two types of timebox – structured and free form.   The later allows teams to run a timebox using any standard SCRUM ceremonies.

Timeboxes

A structured timebox organises a two to four-week period into Kick Off (the team is introduced to the stories), Investigation (pre-planning in SCRUM – the team undertakes detailed investigation ino the stories selected for the timebox), Refinement (actually coding the work and asking for sign off on completed stories), Consolidation (fixing bugs, running tests, tidying up odd bits of work) and Closeout sections (Demo to stakeholder, Retrospective and completion of any Timebox Review Records).

The deployment phase is as it describes.  DSDM does suggest that software ought to be deployable at the end of a timebox and with many organisations looking at continue integration/deployment these days, I suspect this would only be relevant for the very largest projects.

The Post Project phase is not really a project phase as such.  The business is meant to be review the deployed software several times after deployment to see which benefits have been realised and how the software has fared in production.

Roles

One of the main problems with SCRUM is the very narrow definition of roles – it only mandates three roles and in most organisations this leaves a whole bunch of people (inside and outside the team) wondering how they and others interact with the project.

For me, the roles are the standout feature of DSDM, I have seen this work in operation and it delivers results as well as mirroring the reality in most corporations.

The roles:

Project Direction

• Business Sponsor – Owns the budget, the ultimate decision maker and commissioner of the project. Must be senior enough to make decisions and remove organisational blockers.  In many organisations this would be a director, VP or divisional head.  Not involved on a day to day basis, but certainly attends end of timebox demos.
• Business Visionary – Responsible for delivering a solution that meets the business need (this role approves all of the high level project requirements) and overseeing business change (i.e. the non-technical part of the project). The post holder has be senior enough to understand the business process and sufficiently empowered to make decisions.  Typically a senior manager.
• Project Manager – Responsible for ensuring that the project is working as it should (in effect keeping everybody else honest) and ensuring issues are escalated and resolved as quickly as possible.  Writes project reports and owns the content of the delivery plan.
• Technical Coordinator. The Senior Technologist in the project and responsible for technical design and architecture.  Not necessarily involved on a day to day basis, but close enough to the project to assists when needed.

• Business Analyst – Works with all the Business Roles (at project and  to ensure the Requirements List reflects the work that needs to be done and the stories; translates business requirements into detailed stories that the team build, research stories to gather artefacts to support code and test activity.

Project Delivery Team

• Team Leader – The Servant Leader for the Development Team. The Team is self-organising which means the project level roles introduce work but do not dictate to the team how and when it’s done.  The Team Leader is very much responsible for ensuring work progresses through the team (i.e. from the left to right hand side of the story board) and escalating issues to the Project Manager and other senior roles when necessary.
• Business Ambassador – Typically this is somebody drawn from the business who has a thorough understanding of how the business works. They represent to the “consuming users” of the evolving solution and are fully empowered by the Business Visionary to make day to day decisions on individual stories.    Like SCRUM’s Product Owner role.
• Solution Developer – Create the software and unit tests.
• Solution Tester – Tests the software – but more importantly works with the Business Ambassador and Advisors (who also undertake testing) to ensure they test in the right way.

Project Support

• Business Advisor – Typically a subject matter export (SME) or stakeholder who bring specialist advice and input to the project. In an e-commerce project, they could be a specialist in payment gateways; there involvement in the project may be for limited lengths of time.
• Technical Advisor – Brings specialist technical knowledge to the project. In some larger organisations, this could be form operations who might deploy or support the application in live use.  They may have specific non-functional requirements that need to be met – logging or monitoring for example.
• Workshop Facilitator & DSDM Coach. DSDM makes strong play to use workshops for rapid investigation and decision making.  The guidance is to use a trained neutral facilitator to run a workshop (not something many companies have access to).  Equally, a DSDM Coach is suggested to ensure the team runs DSDM in the right way.

DSDM recommends a solution team of 7 +/- 2 (as per SCRUM), there will be  multiple persons holding the Solution Developer and tester roles.    One person could fill several of the roles – in my experience the Visionary and Ambassador roles can be shared but it works better when held by two people.

MoSCoW and Timeboxing.

Virtually everybody has heard of MoSCoW Prioritisation (for those that haven’t – Must, Could, Should and Won’t have this time).   DSDM allocates all requirements to one of these, with the expectation that the Must features will be delivered.  (No more than 60% of the effort should be allocated to Must requirements) – Must requirements also form the basis of a useable system (Minimal Usable SubseT), should and could provide features provide contingency.

MoSCoW is applied at the project backlog, increment and sprint level.  At the sprint level, MoSCoW is applied by the team to ensure key stories are delivered, at the Increment (an Increment is a collection of timeboxes and every project will have at least one, features are prioritised – a could feature increment one might a should or must in increment 2.  Finally at the project level to determine the key deliverables for the project.

As changes arise (either because of new requirements or more information about existing requirements coming to light) work can be reprioritised.

By combining timeboxes (as with Scrum working software is expected to be available at the end of time boxing) with MoSCoW a project team will be able guarantee usable solution.

What’s not to like

• Structured timeboxes – I can’t see why anybody would want to use this style of timebox (Sprint). Against XP and SCRUM  structured timeboxes feel complicated and I suspect awkward in operation.
• Variable length timeboxes in an increment. Although DSDM says you can have timeboxes of any length, I personally never encourage teams to vary the length in the timebox.  To be fair the handbook makes the point that is does make ceremony cadence and velocity difficult.
• Quirky terminology, timeboxes, evolutionary development etc. So all agile methods have this but DSDM has a lot more – possibly more than SAFe.
• Complex RACI Model for products (and the term products is confusing). I haven’t listed all of the products (documents) suggested by DSDM, but they do suggest which role should write each document, which role approves and which roles should review.  It’s logical when you review it but it feels clunky.  What should matter is that the relevant documents are produced at the right level of detail.
• Needs some thought on how you implement this – it’s not a prescription more of a menu. Of course, you could can always call for an expert to support your rollout.
• It’s a bit vague in places; the core is well thought out but as you work through the handbook you find small inconsistencies and other areas where you feel the DSDM team ran out of steam or just ran out of time to think about.  This is not a major concern, but something to be aware of.

In summary

There is a lot in DSDM, I have only skimmed over the method in this article.  If SCRUM isn’t enough then don’t rush to SAFe, LeSS or DaD – take a look at DSDM you may well find a powerful method and naturally fits into your organisation.