Last year, I attended a training course for my company’s chosen brand of agile framework: DSDM. I had some misgivings, having seen some bad projects using this methodology, but I was prepared to give it the benefit of the doubt.
Long story short, I was persuaded of its usefulness*. To briefly summarise, if Scrum is about working through an ordered list of stories, reordering as priorities change, potentially forever, then DSDM is about how you manage the situation when it isn’t forever – when there are known start and end dates for the development.
*caveat: I prefer not to follow any one methodology, I’d rather try to understand their components and use them to solve project problems as they arise.
We don’t have an end date
Good for you. Here’s a scenario that has a definite end date, and I don’t think this is particularly rare:
Startup A has a vision. They need to find investors. As part of their business plan they need to state how much they will need in investment and make projections about revenue. This means that, realistically, they have finite money to make the vision reality, and to start making money from it. Their end date (as of the start of the project, at least) is the point at which the vision has become a saleable product.
Corporation B wants to test out an idea. They need a plan that tells them how much money it will cost to test out the idea, making sure that they don’t under-invest and leave questions unanswered while also making sure they don’t build stuff they don’t need yet and turn this into a full blown product before it has proved its value.
In fact, even when you don’t have a real end date for the development, I think it’s important to have a longer term strategy and to put dates on things. What are you looking to achieve in terms of your business? What needs to be in place and when? Is it achievable?
We have planning and strategy on our Scrum project
Of course you do. The advantage of DSDM, however, is that its main focus is at that project level rather than the day-to-day development process. This means that DSDM suggests specific artifacts and processes to handle things at that level. At a lower level, DSDM seems happy to incorporate Scrum practices into its iterations (sprints) because that is not its principal focus.
At first, the idea of surrounding iterative development with something that doesn’t iterate seemed to me like pretending your waterfall project was an agile one. However, having run several successful projects and attended the training, I am now convinced that there are useful things to be learned here.
DSDM divides projects into phases, starting with a Feasibility phase (that lasts about 2 weeks for projects up to a year long). The purpose of this phase is for the whole team to agree (and have signed off by those outside the project) what they’re going to try to do and how long they think it will take. We’re asking ourselves, “is this thing feasible in the time we have?” or rather, since it’s often an easier question, “is this thing definitely not feasible in the time we have?”
On a successful project I ran immediately after the training last year, the outputs from Feasibility were a “terms of reference” document outlining the scope and purpose of the project, and a set of questions we knew needed to be answered in the next phase, Foundations.
Foundations lasts around twice as long as feasibility and, for our project at least, its purpose was to answer those questions raised during feasibility and to get ourselves into a position where we could start our first iteration (sprint!). This phase contains any initial spikes you already know you want to do and have more detailed conversations about designs.
Haters here are going to argue that you’re maybe 6 weeks into your project and you haven’t written any code yet, in response to which, I would make the following points:
- Not all progress is code. We may value working software over comprehensive documentation, but we’ve used these phases to identify the direction and get buy in. On last year’s project, this was crucial as we identified a significantly different goal to the one we expected. Writing code in the first few weeks would have been setting off in the wrong direction
- Coders love to code. I’m a coder and I know. If you don’t have a separate bit where your coders aren’t writing code, that’s what they’ll be doing. It’s good to have a part of the project where lots of your day is spent in discussion around a whiteboard, discussing ideas instead of solutions
- The length of these phases should be based on the size and complexity of the project, so if you don’t need 6 weeks don’t take it. My old CTO claimed to have completed both phases for a project in a single, intensive week. The important thing is that, by the time we move on, the whole team is happy that we’re heading in the right direction towards a realistic goal
Foundations is also the phase where you come up with some sort of delivery plan. This is an area of Agile that creates a lot of anger. I don’t think DSDM advocates any particular method but I may be wrong. For my part, I think a small suite of different methods get us where we need to be, in particular a blink estimate for all for all of the Musts and Shoulds in the project and some high level intermediate delivery dates (or maybe a list of things and which months you’ll deliver them in). As usual, the closest deliverables should be the clearest, while the furthest ones away are only really worth a casual thought at this stage.
All being well the next phase, Engineering and Exploration, can be run a bit like Scrum development and will generate your product without interruption. However, if you run aground (realise something huge was missed, a high-level estimate was wildly inaccurate, your solution is impossible or the world has changed around you, for example) DSDM allows for returning to one of the earlier phases to take a second look before continuing.
So you love DSDM, why don’t you just marry it?
I have issues with some of the detail of DSDM. It is keen on MoSCoW as a method of prioritizing work. I have a number of issues with that:
- They’re kind of passive aggressive, i.e. shoulds are things that aren’t essential but we’ll be upset if you don’t deliver them
- There’s a lack of granularity. Relative importance between Shoulds, for example? Must-Musts and strong Shoulds often creep in…
- They are often difficult to sell to the business. Business folk hate the idea that you might have something in the project that they don’t care enough about to call it a Must.
Added to this is the advice that, in an iteration (sprint!), the work should be:
- 60% Musts (must be completed)
- 20% Shoulds (usually completed)
- 20% Coulds (not needed)
So, we’re planning to do work we don’t need in order that, when the work we do need takes longer expected, we won’t mind not doing it.
The consequence of this is that, if the Musts don’t take longer than expected, we will also do the Coulds, which we don’t need before we move on to more work we need.
Smaller and smaller projects
However, my main criticism of DSDM is the concept of large projects in the first place.
As I’ve said above, there are occasions when you need to know the size and shape of the timebox your entire project (or even business!) is working within, but in terms of delivering value I would recommend thinking of this as long term strategy and plotting a course of smaller projects which produce individually valuable, and saleable, components. These projects can act as stepping stones to get you to the strategic goal. In that respect, I think sometimes it’s even worth going out of your way to find valuable products on the way to your goal. It beats waiting a year before putting anything finished into the marketplace.
Of course, as these projects become smaller and smaller, the number of questions that need answering and the time you want to take answering them before you get going also become smaller and smaller. The risk of failure of any one project becomes smaller. The overall strategy potentially changes because of feedback from earlier products that are already out there. And so on.
Overall, the above criticism notwithstanding, I will definitely be using some of the features of DSDM in future projects, to try to make sure that the software we’re building is aligned to a feasible business case.