DSDM vs XP: complementary!
I've been following a thread of discussion on the DSDM opendiscussion mailing list. The subject was whether and how DSDM could suit the needs of a software product company .
Along the way someone recommanded XP instead which resulted in further animated talks.
I am highlighting here one reply that I believe gives an interesting and knowledgeable point of vue:
From : Dane R. Falkner:
I agree and disagree with your assumption that XP is more likely to give you a zero-bug scenario. I hope I am fare to both XP and DSDM. I have been using a hybrid for a few years now. But let me explain why I agree with you because I think I understand your perspective, yet from my perspective and the DSDM perspective I disagree.
DSDM is a non-prescriptive framework. It only "prescribes" that 20% of the minimum things needed to make most development efforts successful. What you do with the other 80% is a matter of customization and preference. An XP shop that adopts DSDM will continue to use XP. There will be several new elements added to the development method including some changes to project planning, scheduling, and length of iterations.
But most XP remain unchanged. I am a project manager who uses most of DSDM all the time and all of DSDM some of the time. On all of my DSDM projects I use a little or a lot of XP depending on the capabilities of the team and the technical/political environment of the company.
XP developers are always my best developers. If my clients could get past the "Extreme" in the name they would recognize the disciplined professionalism that XPers possess. That said, there is still a larger world view that escapes many Pers. The benefit of DSDM as a project management wrapper to XP, especially in software product development, is the quality of the final product.
Most XPers would define bugs as something not working as expected in the
application. DSDM describes a bug as it relates for suitability or fitness for business purpose. Perfectly working software that does not provide the business with what it needs is far lower value (quality) than software that atisfies the business need but has a few bugs.
Case in point, we have Symantec in our usability lab right now. They are running usability tests on the next version of one of their products. There product is relatively bug free for this stage of development. But the users that are testing the software are struggling to use and understand the software and it does not satisfy all of their most important needs. This product was developed using XP.
Unfortunately, had they used DSDM with XP to develop this product it is likely that it would have been far more useful and intuitive. It might have fewer features, but they would be the ones most important to the market and they would be easy to use because the marketplace users would have been driving features and quality.
I like XP and I like DSDM. When projects require only one small team then I prefer to use mostly XP with some DSDM. When a project is big, I use all of DSDM and as much of XP as my customer will accept. I have one customer right now that is using DSDM and won't use XP, so I have improvised. They are working towards a test driven development environment, they don't do pair programming, but two people are experts in each area and can take over for the other (joint code ownership), etc.
That looks like an healthy approach to me!
Posted by agnes at 11:47 AM