Total Pageviews

13 July 2011

DSDM, Agile and PRINCE2

Following my previous articles on Agile in a PRINCE2 environment and Agile project management, I wanted to go into some more detail here on DSDM and some issue on adding PRINCE2 to an Agile project management method such as DSDM.

A little background for those new to the subject. PRINCE2 had its origins in the 1980s as an IT Project management method and in 1996 became a generic project management method. DSDM had its origins in 1994 as an IT project management method (specifically towards Rapid Application Development) and was designed to be fully compatible with PRINCE2. In 2001 when the Agile manifesto was signed, one of the original authors (Arie van Bennekum) was, and is, heavily involved with DSDM. Since 2007, DSDM has joined PRINCE2 in being a generic project management method, although still makes many references to its IT origins.

In looking at these two methods, which have co-existed for the best part of 20 years, we see many similarities, however there are also many important differences.

In most projects there are typically four key management roles to fill:
  1. The project sponsor - the person who is paying for it and who is accountable for the delivery. 
  2. The project manager - the person responsible for managing the delivery of the project.
  3. Someone with overall responsibility for the project from an end-user perspective - including the business dependencies between the project and any other work in progress or implemented.
  4. Someone with overall technical responsibility for the project - including the technical dependencies between the project and any other work in progress or implemented.
In the world of the UK public sector, there is typically a department as the customer and a 3rd party company supplying the technical solution. As a result, roles 3 and 4 evolved into the "Senior user" and "Senior Supplier" roles respectively. This fits nicely with the typical government model. In DSDM, the equivalent roles are "Business Visionary" and "Technical coordinator" as DSDM is typically used with fully integrated teams and does not assume a customer-supplier type of contractual set up. The differentiation in roles is simply a reflection of the typical roles PRINCE2 has been used on and the typical roles which DSDM has been used on.

The UK public sector as the "home" of PRINCE2 has invested a great deal of expertise in developing PRINCE2, training people in it and having it adopted across the public sector. Commercially at least asking all of this investment to be dropped in favour of DSDM is a big ask. It is therefore pragmatic for not just the UK public sector and also the wider PRINCE2 community to look at how the flexibility of PRINCE2 can be used to take advantage of Agile thinking and what role alternative management methods may have, specifically Agile management methods such as DSDM.

Let me address this by looking at the book Agile project management: running PRINCE2 projects with DSDM Atern by Keith Richards which is the principle book explaining how to make this integration.

The first few chapters of the book explain the rationale and advantages of DSDM and PRINCE2 separately and it is when we get to chapter 6 that we first see what bringing together these two methods might look like.

The integrated method described in Chapter 6 misses off the DSDM project stages and doesn't relate the PRINCE2 stages to their DSDM equivalents, namely the SU stage of PRINCE2 being approximately equivalent to the Feasibility phase of DSDM, the IP stage of PRINCE2 being approximately equivalent to the Foundations phase of DSDM and the CS/MP being approximately equivalent to Exploration and Engineering. This comes later. The more I look at this it appears to be PRINCE2 with modifications to incorporate DSDM techniques and it's still being called PRINCE2. In chapter 6, Keith actually says in 6.1.2.1 that Atern goes further than PRINCE2 in terms of delivery techniques, yet despite Atern adding value it's PRINCE2 effectively getting the credit.

In my view, developing a hybrid method means there is potential for confusion regarding the documents that are produced, their names and contents and also the team roles and responsibilities. The simplest way that works should be to either say you are doing PRINCE2 but incorporating principles and techniques from DSDM (specifically to help with Agile delivery where DSDM is stronger) or that you are doing DSDM and being agile, but adding elements of PRINCE2 to clarify some of the governance features which people coming from a PRINCE2 environment would be more used to. PRINCE2 is very "contract" and "sign off" driven, whereas DSDM incorporates Agile techniques that are really coming from a different place in terms of collaboration, minimal sign off, flexibility and dynamism. Is the culture of the organisation one which is using the "sign off" mindset or has it embraced the flexible world of Agile?

The book does not really explain what documentation is necessary other than some of the DSDM documents being added to the PRINCE2 documentation set which seems almost a step backwards - if as is stated you add the BAD and SAD to the PID, then presumably there are also elements of the PID which are no longer needed otherwise there is a document overload.

What would I suggest? Well in organisations that have multiple methods, I would suggest some sort of decision tree to decide on the best approach and also to understand the risks associated with that approach, dependent on the organisation's culture, awareness of the methods, the size of the project and its criticality.

Based on that decision tree, we could have a number of outcomes such as
- PRINCE2 as is or with some modifications
- PRINCE2 but incorporating DSDM techniques as advocated in the book
- DSDM with some PRINCE2 techniques (e.g. for 3rd parties using PRINCE2)
- DSDM, which by itself can deliver a project without PRINCE2
- Some other combination such as PRINCE2 with SCRUM or other agile principles.

In this I think there are a few different ways of blending PRINCE2 and DSDM besides those shown in the book.

I would suggest that unless the business and management are ready to do DSDM in the organisation that having a development team doing DSDM but a management board doing PRINCE2 is probably going to result in a conflict of culture and misunderstanding. It would be better if the board were fully engaged with DSDM at the outset. In that regard, I would suggest subsuming the senior supplier role into the technical co-ordinator role and also the senior user role into the business visionary role. If it is necessary to manage PRINCE2 workstreams within this (e.g. for an external supplier) then the DSDM/PRINCE2 boundary should be at the Project Manager level - this should be someone experienced in both DSDM and PRINCE2 and who on a day to day basis is closest to all the projects.


Further Reading:
Post a Comment

Popular Posts