DSDM Atern can be thought of as a Framework (the handbook calls it that), or a Method. It comprises a Philosophy, underpinned by eight Principles and supported by defined Processes, People (Roles and Responsibilities), Products and Practices.
Like any other method/framework, it is intended to be tailored to suit specific projects. But, like any other method, the processes work best as a whole. Adhering to the Principles is easier if certain Practices are followed; following certain practices is only possible when the right People are in the right roles and fulfilling their responsibilities.
Here are some examples:
It is unlikely that teams will adhere to Principle 1 – Focus on the Business Need – if they are not adequately and accurately prioritising their requirements. Prioritising requirements properly requires at least that an empowered Business Ambassador is a full-time part of the solution development team, and that the priorities are agreed and understood through a facilitated workshop. See how they go together?
Delivering on Time becomes much more likely if the team understand what work they need to do, which requires that an adequate amount of high-level analysis, design and planning is done during Foundations, and that the output of these Workshops is documented in relevant Products. Delivering on Time also requires that the plan has some contingency, which requires that the MoSCoW rules have been followed.
Being more agile means Iteratively exploring the customers’ need in detail rather than specifying the detailed solution in advance. This also requires that business Ambassadors & Advisors are empowered and involved enough to allow teams to leave the details until they get to the timebox and the solution development team work together to arrive at the best solution.
For an Atern project to be successful, the team, and the project manager in particular, need to Demonstrate Control. For this, they need a feasible, clear and visible plan, formulated Collaboratively, with everyone fulfilling their Responsibilities throughout the lifecycle, and Communicating clearly and continuously.
It is dangerous to ignore parts of the method, unless you understand how they interact with other parts. Not assigning someone to a specific role, for example, means some Responsibilities are not carried out, which can impact on Processes and even mean the Principles are not met, which can reduce the chances of success.
Every Principle that is not adequately met constitutes a risk to the project success. Think carefully during the early stages of the project about how it will be run. Take each of the Principles in turn, read them carefully (see the handbook or my earlier blog posts on each) and construct your development approach in such a way that all of the principles are met. Do that and you won’t go far wrong.