Compare Dsdm And Xp

[Some very stale thread mode pruned 2006-Feb]

Well one big difference between XP and DSDM is right up front of dsdm.org you seem to need a licence to "practice" DSDM. It is proprietary.

Regional Interest Groups: http://www.dsdm.org/en/communities/rigs.asp

Why compare them? Do both! some of the XP practices have been added to version 4.2 of DSDM and spawned a new methodology: EnterpriseXP http://www.enterprisexp.org and http://www.dsdm.org/timebox/issue11/version4_2.asp -- Sarah Clooney

In comparing these two method(ologie)s we may come across some special cases of XpConceptsInAcceptedMethodologies.

Based on an informal chat with a colleague who has much DSDM experience, it would seem that DSDM and XP differ in at least these ways (this is hearsay, please, of course, correct if you have better information):

Based on an informal chat with a colleague who has much DSDM experience, it would seem that DSDM and XP are similar in at least these ways (this is hearsay, please, of course, correct if you have better information):

DSDM currently has much more official corporate support, at least in the UK. From experience chatting to people into DSDM, they tend to be pretty open to XP... but some members of the DSDM community will see XP as "more of the same" and be resistant to it on that basis.

The reason I was after a comparison was for the potential of selling XP into an environment as an evolution of DSDM. It's that corporate support that could be a great leverage for that introduction. -- StuartBarker

I remember talking about the relevance of this to the UK DERA (DefenceEvaluationAndResearchAgency?). -- RichardDrake

the idea of using small iterations to address the requirements issue to be where XP and DSDM are similar.

The fundamental difference for me is the considerable focus XP places on the quality of the code developed during each iteration. It's use of techniques such as Pair Programming, Test-Code-Refactor, regular integration etc. etc. This is how XP addresses the time to market issue, as opposed to DSDMs use of prototyping. -- AnthonyDickinson

The quality of the code is considered a non-functional requirement in DSDM with 'fit for purpose' being paramount; if you combine DSDM and XP, then you would take the XP approach to code quality. -- Steve Ash

DSDM does not use prototyping to address the time to market issue, it uses it to gather requirements both functional and usability. The time to market issue is addressed, as in XP, by prioritized requirements in short increments. -- Steve Ash

Whilst here, may I mention that DSDM recognizes a distinction between 2 aspects which are used almost interchangeably elsewhere, these are Increment and Iteration. An Increment is deployed, being used functionality; an Iterations are how that Increment is produced. You are advised to have a maximum of 3 iterations when producing ANY deliverable (document, user story, test scripts, code); the first to Investigate, the second to Refine and the last to Consolidate; it is found that 2 iterations usually suffice. Each iteration is planned to be as long as needed could be half a day, could be a week but not longer (if longer is expected to be need then the deliverable is probably too big). -- Steve Ash

Reading through "The Underlying Principles" (http://www.dsdm.org/tour/principles.asp) in the online DSDM Manual, I believe the two overlap in a number of places. I've come up with the following comparison.

This is just a quick outline, after reading through the DSDM Consortium web page. Please feel free to add, edit and comment. Particularly those out there with DSDM experience. -SB

See JenniferStapleton's book, DSDM: The Method In Practice ISBN 0201178893 .

DSDM & XP have a lot in common. Add the Rational Unified Process to this list and you will see a lot of resemblance. RUP has inherited a lot from the DSDM Process, and Rational is working on joining XP and RUP to a light RUP-version called XUP. I'm working on an article comparing DSDM and XP (hope it is ready mid January 2001), because XP can be very helpful for DSDM adopting organization, DSDM can be helpful on the project management side for XP adopting teams (> 2 people). I've experience in implementing DSDM in organizations, and encountered the problem for fast moving e-business teams,and their XP has a lot of practical add-ons. You can contact me mailto:b.weegenaar@devote.nl. -- Bertrand Weegenaar

Which aspects of DSDM project management have you found useful? Was it a case of using DSDM to ease the management into accepting the XP practices? -- SB

One thing first: DSDM is further in its evolution as a method then the Extreme Programming community. It's also more advanced in creating user groups (both consultants, customers and developers) then XP. XP is targeted primary at the engineering/developers community. DSDM has evolved to a worldwide consortium with a DSDM Manual version 3 and dozens of White Papers to support its users. If you look at the projectmanagement part you'll see a situation the XP-architects would be proud to evolve to; a stabile, described process supported by guidelines and practices for example project & team structures, project planning and control, measurement, testing, configuration management and quality (DSDM is very quality oriented!). XP is were DSDM was in 1996, focusing on small rapid developing projects in a waterfall (SSADM) environment giving more project guidance then James Martin's RAD practices. Now it will be the XP community's task to guide the more general oriented practices of DSDM (And others like RUP) to e-business development speed were very short timeframes, high demanded quality, small flexible teams and ever changing customers are demanded. I have seen initiatives in the DSDM world called e-DSDM who focus on this aspect.

One marketing aspect XP needs to solve is its name (has a negative attitude to management who associate it with hacking!) and the pair programming practice. It's essential that XP-cases are published proving the advantages above traditional practices. - Bertrand Weegenaar

Another ExtremeUnifiedProcess? So far there's the original by PeterMerel and another from Sun. Now Rational wants to get in the fray too...

Recently, we, (http://www.exoftware.com), visited a client that was interested in XP but had already made an investment in DSDM. Prior to the meeting we did some research, (basically spent a day on the web), on DSDM and where it fits vis-à-vis XP. We basically came to the conclusion that.

1. DSDM and XP are very closely aligned. There is an almost perfect match between the principles behind both XP and DSDM. (see http://www.dsdm.org/tour/principles.asp). DSDM's principles are more general than XP's.

2. XP could be looked at as a concrete instance of a DSDM implementation.

3. XP has outlined more specific practices, especially in the coding arena.

4. DSDM seems to reach: 

   further up the process
      feasibility, business impact analysis
   and farther down the process
      explicit implementation reviews and addresses support
   and around the process
      change management is big
Basically, it seemed to us that XP could easily fit within a DSDM environment. In fact XP could be seen as a concrete instantiation of a DSDM process. DSDM itself is as far as we can tell much more tolerant in the actual practices used, in fact recommends using what already exists if possible, as long as the principles are adhered to.

Within the DSDM process XP seems to fit within both the "Functional Model Iteration" and the "Design and Build Iteration" or more cleanly just in the "Design and Build Iteration". If the output of the "Functional Model Iteration" could be User Stories then we have a perfect fit within the "Design and Build Iteration". However, there does seem to be some level of code level prototyping advocated in the Functional Model Iteration, which by definition falls within the XP's realm. DSDM states itself that the line between these two phases can be blurred and I believe that a fully compliant XP project, i.e. all 12 practices, could exist within these 2 phases while maintaining DSDM compliance.

In fact our client's comments were that XP gave them some of the concrete steps they were looking for within the "Design and Build Iteration". They had implemented DSDM up as far as this box. However, they were struggling with what to do within the box to improve on their ability to deliver quality software. There initial reaction was that XP could fit perfectly within this box and fill a lot of the gaps they had identified.

There does seem to be one or two possible conflict points that I have captured in the Notes section below.

Notes: What follows are just some random notes and observations I made while researching XP and DSDM.

-- SeanHanly

I would like to comment on some of Sean's Notes:

SA - Agreed; how the Principles are being followed is the the first check I make when doing a 'health check' and the first reference when something unexpected happens.

SA - The target Network etc architecture is needed reasonably up-front for any software development; no point writing a whole load of stuff using EJB/COM/.NET if it will be running on a 20 year old mainframe!. There may be a corporate standard software architecture that has to be complied with/configured again same for any software development. There may a 'green field' software architecture environment, in which case DSDM recommends high-level investigation during Feasibility and more detailed technical investigation during the Business Study and Functional Model Iteration (hopefully the development language has been chosen before prototyping so that the prototypes can be evolved rather than rewritten during design and build).

SA - DSDM recommends modelling as a quick and unambiguous way of documenting requirements and design decisions. As with all documentation, the matter of quality is a non-functional requirement and fitness-for-purpose is the key. If you want to keep them for posterity then the completeness and correctness will have to be reviewed; if you don't want to keep them, then throw them away. I think this is what practically happens with XP; if the customer wants it, XPers will advise against it but do it if required and charge more.

SA - Agreed, a prototype in DSDM is no more than a sophisticated XP user story and I would not expect TestFirstDesign to be used when building it but would when evolving it in the Design & Build phase.

SA - Multiple Ambassadors are NOT recommended. There is experience where this has been tried and to my knowledge has always caused conflict. You need to find an Ambassador who can be seen by all business Advisor Users to be impartial.

SA - Not sure why you get this impression. DSDM treats initial development as a project and any maintenance requirements that come along as other projects. What do you see as the XP gearing towards maintenance?

SA - The 3 knobs that DSDM recognize are Functionality, Time and Resources; Functionality is the only variable knob. Quality is addressed by advising that any proposed product has its quality requirements set before it is produced. So you have overall, 'high-level' quality requirements and specific deliverable (document, user story, test plan, code) quality requirements; the specific obviously have to fit in with the overall or the overall may have to be revised (with agreement of everybody of course).

SA - The first 3 are really no different to any other prioritizing system (High/Med/Low, Essential/Highly Desirable/Desirable, A/B/C, 1/2/3 etc) but adding the W is a useful weeding out mechanism. Getting the business to think about what they don't want now helps focus their minds better and helps avoid the 'When I said I wanted this, it should have been obvious that I wanted that as well' situations. It is just a technique, not dogma (sometimes you don't get any Won't Haves).

SA - Firstly, Timebox and Iteration are not the same in DSDM; you use Timebox techniques within iterations to produce products. Secondly, there are definite deliverables to all iterations; all deliverables will involve the Ambassador and/or Visionary either in producing the deliverable or reviewing/accepting it. BTW deliverable does not just mean code in DSDM; it means all documentation/models/user stories leading to code (DSDM is also used for non-software development projects as well)

SA - DSDM is about project development frameworks and tools/techniques to help manage iterative and incremental lifecycle - as such it lends itself to be used for process improvement. XP is more specific project focused and has nothing to say about reviewing the way it was done specifically and how it could be improved. DSDM needs to be tailored for specific projects, that is the whole point of a framework.

SA - Thanks for that last comment; I have been involved in writing a couple of those papers.

I might have sounded as though I was critical of your notes but I would like to add my thanks for you raising these perceptions and giving the opportunity to clear up any misunderstandings.

Please email me at steve@ootac.com if anybody wants any other clarifications. -- Steve Ash

CategoryMethodology

EditText of this page (last edited November 18, 2011) or FindPage with title or text search