I've had practical experience with XP when managing a developer team in the states and I somehow always felt that it didn't provide a framework that was complete enough.
Looking at DSDM - which stands for Dynamic Systems Development Method - I am getting the feeling that it's exactly what I've been looking for since then. They are also one of the founding members of the Agile foundation.
I welcome everyone to discover this methodology for themselves. The way I see it, XP methodology borrows a lot from it. Maybe the two evolved independently of each other. They certainly have a lot in common with each other.
Go to their website
Or read the extended entry for a breakdown of what I see as some of the most fundamental objectives.
DSDM stands for (Dynamic Systems Development Method) but it is not a method in the accepted sense rather it is a framework focused on delivering a quality solution quickly.
The DSDM Framework is about ensuring projects are delivered ion time and on budget. It is not a Project Management method. Subsequently it is often the case that DSDM is used in conjunction with other approaches within projects to facilitate the delivery of the project and manage user involvement.
The DSDM philosophy is simple:
* Development is a team effort. It must combine the customers' knowledge of the business requirements with the technical skills of IT professionals * High quality demands fitness for purpose as well technical robustness * Development can be incremental - not everything has to be delivered at once, and delivering something earlier is often more valuable than delivering everything later * The law of diminishing returns applies - resources must be spent developing the features of most value to the business.
A fundamental assumption is that nothing is built perfectly first time, but that a usable and useful 80% of the proposed system can be produced in 20% of the time it would take to produce the total solution. One of the underlying principles of DSDM is that fitness for business purpose is the essential criterion for the acceptance of deliverables. This moves away from the approach of satisfying all the "bells and whistles" in a requirements specification as this approach often loses sight of the fact that the requirements may be inaccurate.
Project implementation cycle
The requirements of any DSDM project are prioritised using MoSCoW?. The o's are there for fun but they could stand for 'on time' and 'on budget'. The MoSCoW? rules provide the basis on which decisions are made over the entire project, and during any timebox.
Timeboxes are fixed; therefore, the deliverables from the timebox may vary according to the amount of time left. Essential work must be done - less critical work can be omitted. So the MoSCoW? rules are applied.
Must Haves fundamental to the projects success o Should Haves important but the projects success does not rely on these Could Haves can easily be left out without impacting on the project o Won't Have this time round can be left out this time and done at a later date
