There seems to be very little hard evidence that DSDM is significantly more efficient than a waterfall approach at doing the work, which would seem to kill the business case stone dead. After all, why incur the costs of migration if the grass really isn’t any greener on the other side?
But as the discussion has evolved, it has become clear that this is to misread what Agile methods like DSDM (or Scrum) are offering. (And perhaps this should have been obvious from the start – I only really noticed this point once the discussion was well under way).
To boil down what is (for the time being) the final argument, there is indeed a narrowly economic argument for DSDM. Unlike a waterfall, DSDM is never going to waste stakeholder time and money by delivering (say) 100 function points that were agreed a year ago, when they were almost certainly based on premature and immature judgements. We probably don’t want exactly those things any more: our thinking has evolved, our goals have evolved, and the business situation has evolved. Instead it (DSDM or any other agile methodology) will deliver 100 function points and for much the same price per FP, but they will all be FPs we know we want.
Add to this DSDM’s far closer control over the delivery process, which makes it far less likely that the whole project will go over budget, schedule but under scope, and the business case for DSDM is clear: even if DSDM projects don’t cost less per FP, they represent better value for money, because they are all FPs you want.
Another interesting point was made by John Isgrove of Collaborative Consulting -
What we found was that DSDM completed the same development in 66% less time. It did not complete in less effort however as with agile projects they tend to be shorter but fatter resource profiles i.e. work for less time but more people involved at the same time across the time period. Overall effort was about the same with with higher proportions than the waterfall project being spent by the analysts and testers.
No comments:
Post a Comment