Recently, I took a course in DSDM, an agile project delivery framework. Whether you’ve taken the course yourself, or if you’re thinking about booking it, here are some of my thoughts after having completed my training.
What is DSDM?
DSDM (or Dynamic Systems Development Method*) is a project delivery framework, most commonly used for software development projects. It embraces the core principles of Agile and encourages iterative and incremental development. What sets DSDM apart from other Agile approaches it’s strong focus on project governance and setting up a strong project foundation. DSDM is very verbose, and has very explicitly defined roles, principles, project phases etc.
*During the course we were informed the acronym had no meaning at time of creation, just a series of randomly chosen letters. Like there’s not enough acronyms in this line of work!
Why do the course?
Agile at project level
A lot of the time, it’s easy to only think of Agile applying only at the team level, the people who are at stand-up every day, the engineers, the QAs, the designers. I wanted to gain a better understanding of the key roles outside the team that have an impact on a successful project delivery,
Bridge the gap between Waterfall and Agile
Although Agile is becoming more and more popular, it’s still an emerging practice. There are plenty of companies that are in the very early stages of adapting to this new methodology after a lifetime of using waterfall. Hence why so many roles in agile delivery have a ‘coaching’ element to them. By taking this course, I wanted to learn the common pitfalls in being an Agile evangelist.
Diagnose common pain points in projects
If you get a group of delivery leads in a room, chances are they’ll have all experienced the same problems on a project at some point. Does DSDM have any silver bullets to tackle these problems?
What did I learn?
Specific roles and their purpose
There are many different roles in DSDM, 14 to be exact! They all have different responsibilities (and can be fulfilled by the same person if necessary). DSDM splits roles into business interests, technical interests, management interests & process interests. Each role has clearly defined responsibilities and lines of communication.
Business communication is essential for the project to work
This is one of the core principles of DSDM, and referenced by several of the key roles required within the project team. Collaboration and communication with the business is vital for the project to succeed, and often the reason why projects run into insurmountable issues.
The relationship between Time, Cost, Quality & Features
Almost at the very beginning of the course, we were introduced to one of the big selling points of a DSDM Agile project. There are four project variables: Time, Cost, Quality and Features. In a traditional project, your number of features are fixed. The project cannot be a success unless ALL the features are delivered. This typically means that your Time, Cost and Quality have to go up or down in order to accommodate for any risks.
In a DSDM project however, Time, Cost and Quality remain fixed. Features stay in a state of flux. This means if you’re working to a fixed deadline or budget, a DSDM project may well be the right approach. Even if all features can’t be delivered within the set timeframe, you at least get a useful subset of those features delivered by the end of the project. Feature are prioritised using MoSCoW, which then gives you your Minimum Usable SubSet (MUST)
It’s agile, there are a lot of acronyms!
What surprised me?
Not every project could/should be DSDM
Although we’re learning how to run a DSDM project, we’re told on Day 1 this approach will not work for everyone. Built into the DSDM Process are several check-points where you can assess whether the project should continue. In the ‘Feasibility’ phase of a project (and then later reviewed in the ‘Foundations’ phase), you fill out the Project Approach Questionnaire, a DSDM ‘Product’. This is essentially a rated checklist, that will bring up any signs the project is not ready to start. It could be for a number of reasons:
- There’s very little support available from the business side. This is rooted in two of the 8 principles of DSDM, “Collaborate” & “Communicate continuously and clearly”. If it doesn’t seem like there can be active and ongoing communication from key business roles, the project may not be viable
- The business needs aren’t clear or understood. If it’s not clear why the team is working on this project, is there actually any value in doing it?
Will I be using DSDM for an upcoming project?
Realistically, not anytime soon. That’s not to say the course wasn’t excellently led or I wasn’t convinced of it’s merits, but it’s hard to picture a DSDM project “in the wild”. Typically, when we’re brought into an organisation, even if we run an Agile project, the rest of the company will continue to operate in a waterfall way. So this makes the project governance that DSDM needs much harder to implement, as highlighted by its emphasis on having good communication with the business.
What you’ll most likely realise on the course is that there’s a number of DSDM features you’re already using, but perhaps you’re using a different name for it or you do a similar thing with a few tweaks. At Red Badger, we use Kanban as our choice of Agile delivery approach, with the focus on eliminating waste combined with visualising the flow of work better suited for us. It also allows us to adapt more to whatever framework a client may already be using around us.
Should I take this course?
What if I’m already in a project management role?
It’s always a good idea to continue learning, no matter what role you are in or level you are at.
What if I’ve never worked with Agile before?
The course assumes you have no prior knowledge of agile, and the fundamentals of agile and its guiding principles are covered in detail before moving onto DSDM.
What if I’m a non-techie?
DSDM was designed to be agnostic of any particular industry. Having said that, it was designed by people who come from technical, software development backgrounds. Naturally, this means some techy terms have snuck their way into the terminology. So anyone approaching agile from a non-software development background may face a steeper learning curve than others.
What do you think? I’m keen to hear your thoughts on DSDM. Feel free to get in touch.