safeguards and management products. This chafes against the established cultural values of many code-oriented developers who profess to be working in an Agile manner.
Early attempts to integrate PRINCE2 with DSDM
One way of tackling this cultural problem is to appeal to standards. A standard can require that Agile development must occur under the mandate of a prescriptive background environment. Coding standards are an example of how an appeal to standards can work on Agile projects in practice. By extension of this model, team members can be required to subscribe to a standards-based process just as they are expected to adhere to certain coding conventions. Of course, in reality it isn’t as simple as that. There is an enormous difference in terms of the level of perceived intrusion and of sheer scale.
For example, the PRINCE2 framework is an official and de-facto standard in the UK and many other countries. It was initially developed by the Central Computer and Telecommunications Agency (CCTA) as a UK Government standard for IT project management. A rigorous and highly prescriptive method, it is typically associated with waterfall development techniques. For many years it has been seen as the antithesis of Agile Methods. Needless to say, getting Agile projects to work in conjunction with its strictures has been a significant technical and cultural challenge.
In 2006 a major overhaul of PRINCE2 was initiated to make it more flexible, and more capable of supporting recent developments in Agile practice. This was released in 2009 as the “PRINCE2:2009 Refresh”. Prior to this release, serious attempts had been made to reconcile DSDM Atern with the earlier PRINCE2 version [Richards, 2007], [Barron 2003]. Of all the Agile Methods in general use, DSDM Atern certainly stood the best chance of integration. It was product-focused, had broadly compatible artefacts and roles with PRINCE2, and featured a well-defined metamodel.
Unfortunately though, the “join” with the earlier PRINCE2 version was difficult to hide. It was generally recognised that it would be an oversimplification to assume an impedance mismatch, and to try to manage the join by associating PRINCE2 and DSDM with macro and micro level processes respectively (much as one might also try to encapsulate a Scrum sprint within a PRINCE2 work package). Instead DSDM was positioned as being cross-spectrum in scope, encompassing both project management and delivery disciplines. PRINCE2 meanwhile, was contextualised as a project management discipline focusing more on project direction and less on product delivery. Successful integration would involve the picking-and-choosing of which “bits” were thought to work best from each process, and the elision of those “bits” that didn’t. Although general recommendations can be distilled, hard experience - and an awareness of the optimum locus to occupy along the methodological continuum - are of fundamental importance in getting an approach like this to work.
Codeworks DEV: our approach to Agility and standards
The Codeworks DEV programme manages Agile projects in publically accountable environments. We have focused on Agile pilot schemes and prototyping projects. Agile Methods reconciliation and transfer has therefore been one of our responsibilities. Ironically perhaps, a linear model has proven to be a good starting point for the projects we have undertaken. We typically provide stakeholders with a narrative context which gives an indication of progress. This resolves into 4 phases of project “discovery”, project “definition”, solution “development”, and solution “delivery”. These phases, which we call the “4 D’s”, are meant to be conducted in series in order to provide narrative continuity. Although this suggests some sort of linear method, it goes no further than the provision of that high-level narrative. It can be noted from the