DSDM: Agile for ‘projects’

DSDM is our framework of choice at Deeson and this blog post explains why.

Firstly, what is it?

DSDM is “an Agile method that focuses on the full project lifecycle, DSDM was created in 1994 after project managers using RAD (Rapid Application Development) sought more governance and discipline to this new iterative way of working.”

There are pros and cons associated with any delivery approach or methodology and, in my opinion, there isn’t a ‘one size fits all’. However, it’s important for people to make an informed choice and when they say ‘agile’ they know what that actually entails.

So, why DSDM?

When we first embarked on the journey to deliver projects using agile methods, we started with ‘Scrum’. Scrum is a collaborative Agile development framework that breaks large processes down into small pieces in order to streamline efficiency.

Scrum is great, but it was and is intended for in-house development teams building software in-house and it doesn’t always lend itself well to ‘projects’ as it “focuses on product development via the product backlog. Ignoring that there are many other things that have to be managed outside of the product development to deliver a successful project.”

It provides no framework for the definition stage of projects and has no steer on documentation, governance, or stakeholder management. These are all very important things to our clients, and rightly so.

What makes DSDM unique?

Clear project phases

The DSDM process consists of four main phases: Feasibility, Foundations, Evolutionary Development and Deployment.

These phases constitute the lifecycle of our projects and ensure we don’t move to the next project phase until we have met the intended outcomes required to move to the next phase successfully.

Often, teams will move into development too quickly without fully understanding the scope and size of projects, fully examining the risks and, where possible, undertaking the necessary feasibility steps to ensure the unknowns are properly understood.

Documentation

As part of our Foundations phase, we produce two key documents which our clients input on, review, and effectively sign off on in terms of the direction of travel. A key principle we hold is that our clients shouldn’t get any surprises — good or bad. Because they’re embedded as part of our multi-disciplinary teams, they should discover things at the same time as our teams.

Solutions architecture definition (SAD)

The Solution Architecture Definition provides a high-level design framework covering both the business and technical aspects of the solution to a level of detail that makes the scope clear without constraining development.

Development approach definition (DAD)

The Development Approach Definition provides a high-level definition of the tools, techniques, customs, practices, and standards that will be applied to the development of the solution. Importantly, it describes how the quality of the solution will be assured.

These documents ensure the right amount of upfront thinking is done to de-risk development, that there is overall alignment on the scope of work at a high-level and all teams are aligned on the approach, project objectives, and ways of working before proceeding.

A clear definition of ready

Many agile teams use digital boards and backlog tools: these can be really useful, but they can also make teams lazy. The speed and ease in which you can add new tickets can often result in an unmanageable backlog of tickets that haven’t been properly ‘validated’.

The backlog, in some cases, reflects the noise and distractions of your organisation and the opinions of the highest-paid people. We wanted to put some thoughtfulness and consideration back into how we use our tools and ensures what gets added is evidence-based, user-led and, if worked on, provides value to the organisations we’re working with.

We have configured JIRA to separate the ‘refinement’ of work from the backlog, which only shows tickets that have been fully defined and meet our definition of ready e.g. they have acceptance criteria, designs and UX if necessary, they have been given an estimate, and have been approved by the Product Owner to work on.

The definition of ready and definition of done originates from Scrum and is a good practice for any agile team, as it determines what needs to be done and the amount of work required to deliver the unit of work.

Read more about our workflow here.

Prioritisation method

Have you ever worked on an ‘Agile’ project where you got to the end of the project and the budget had been exhausted but there was still a sprint worth of stories the client was expecting to get delivered? Yes, me too!

The combination of the ‘MoSCoW’ prioritisation technique and strict Timebox goals ensures this isn’t the case.

When refining user stories in parallel to development, rather than defining all the technical requirements upfront, it can be easy to lose sight of the big picture, focusing too much on the current increment and the next Timebox. The danger of this is that you go too deep on a feature set too early, which allows for less flexibility and agility later on in the project.

By our clients adopting this method of prioritisation, it forces us to work in ‘layers’ i.e. we build all the ‘must’ features which are critical for the project to launch and then circle back to develop the ‘shoulds’ and ‘coulds’ as budget allows. This ensures that clients get a complete website at the end of the project.

Budget control

With budget and quality being fixed, the scope becomes the variable. The combination of strict Timebox goals and prioritisation ensures we’re always focusing the budget on the next most important thing.

During the new business phase of a project, we estimate how many Timeboxes we would need to deliver the broad epics/themes in the request for proposal.

When we win the project, the first thing the delivery manager does is split the total budget across the number of Timeboxes. It’s common for teams to realise too late that a project is over-running.

Our setup and tooling provide very early visibility of progress, budget forecasting and velocity, which we can extrapolate across the project to provide meaningful context to prioritisation conversations with the product owner throughout the project.

Why our clients like it

Many of our clients are still relatively new to Agile; as DSDM can be blended with more traditional project management methodologies or approaches, it often provides an easier transition for companies who have had less experience of delivering iterative software.

Understandably, ‘on time and budget’ is often the single most important success factor. I’m proud to say that through the DSDM practices of timeboxing, MoSCoW prioritisation and the flexing of features, here at Deeson, we have built a strong reputation for timely and on-budget projects.

Our process allows Product Owners to feel in control of where the project is going and how it will look, with no ‘big bang’ surprises at the end.

Interested in learning more about how this process could work for you? Get in touch.