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:

• The DSDM Consortium
• The DSDM Consortium white paper DSDM and PRINCE2
• Information on DSDM on Wikipedia
• The DSDM group on LinkedIn
• The Agile Manifesto

Agile and PRINCE2

In January 2008, I posted an article on PRINCE2 and Agile which it seems has been #1 in Google for those search terms ever since and consequently has received a great deal of attention, comments and traffic.

More than 3 years later I have worked on 4 agile projects, become a PRINCE2 and MSP practitioner and qualified in DSDM (the Agile project management method mentioned in my earlier blog). I've also got a lot more experience - see my LinkedIn profile at http://www.CraigCockburn.com for further details - including 3 projects for Central Government (BERR, CIO Council and DirectGov).

Given the recent push to have Agile more accepted in government circles I thought it was time to update the blog.

A few things have been happening recently

1. The Agile Delivery Network are hosting a meeting later today. I am attending - the ADN appears to be a small developer led community promoting the use of Agile in government, especially from the software development perspective and working with the Institute for Government
2. This week we have seen reports in the IT media about the Government turning to small companies for help in introducing Agile and a number of important blogs such as Agile can fix government IT calling for agile to be taken seriously as a delivery method.
3. There has been a fair amount of debate about Agile in Government on the DSDM Group on LinkedIn and the DSDM group itself is also responding to the System Error report 
4. The government ICT strategy (March 2011) also states "Additionally, the application of agile ICT delivery methods, combined with the newly established Major Projects Authority, will improve government’s capability to deliver projects successfully and realise benefits faster. "
5. Increasingly organisations outside of government are deploying DSDM as a project management method rather than PRINCE2 as DSDM not only incorporates the benefits of Agile, but is also suitable for an environment that is regulated, compliance driven and is interested in meeting CMMI standards. Swiftcover (part of the AXA Group) won the award for "Most Agile aware organisation" at the inaugural UK agile awards in 2010.

So lots of change it seems. So where does that leave Agile, PRINCE2 and the appropriate choice of project management method in the new world of Agile government.

I am project management method neutral. I am not pro or against PRINCE2. What I am against is using PRINCE2 when it is either unsuitable for the project in question or that it is suitable, but there are more suitable methods. There is nothing in the PRINCE2 manual about producing reams of documentation although to be fair DSDM as an Agile project management method does go further and state that documentation should only be produced where it adds value. Neither am I going to recommend Agile when there are certain projects (especially those with risk to life) where you cannot adequately timebox testing and for which a pure Agile approach would be less than ideal.

PRINCE2 by itself assumes a waterfall like approach where the requirements are signed off at some level and then handed to development. There's no principle in the usual PID of fixing the time, cost and quality and flexing the scope. However, PRINCE2 does afford the project manager quite a lot of freedom and flexibility. The project manager works within the tolerances of time, cost, budget (and possibly scope) that are set by the project board and these can be as wide or as narrow as is appropriate for the project. In that regard, PRINCE2 gives the project manager the flexibility to get on with the job as best they see fit within those parameters. I was programme manager on the BCS "IT Project Team of the Year 2010" award winning programme. This was run along these lines of light touch management and working within agreed parameters - something common to both Agile and also a sensibly run PRINCE2 project. PRINCE2 really can have as much or as little ceremony as you like, it doesn't have to be a bureaucratic monster that some make it out to be, but in differentiating it from Agile, PRINCE2 does assume you know a lot more up front and are prepared to spend longer in analysis having detailed requirements to "sign off".

DSDM, like PRINCE2, had its origins as an IT Project management method but has now become a generic project management method capable for delivering both IT and non-IT projects. DSDM does have a lot more to say about day to day activities at the delivery team level (e.g. daily standups) and as such is more of a how-to manual rather than PRINCE2 which is more of a process guide for managers.

There are therefore a few potential options in choosing the appropriate method:

Choice of Development methods:

1. PRINCE2 with a waterfall development method (the traditional way)
2. PRINCE2 with an Agile development method (quick win for the PRINCE2 advocates)

Choice of Project Management methods:

3. An Agile Project Management method with PRINCE2 and one of the development methods above - -- Hybrid as put forward by Keith Richards  - author of Agile project management: running PRINCE2 projects with DSDM Atern published by The Office of Government Commerce and Agile Project and Service Management: delivering IT services using ITIL, PRINCE2 and DSDM Atern (by Dot Tudor and also published by the Office of Government Commerce. 
4. An Agile Project Management method without PRINCE2 and one of the development methods above. Agile project management with a waterfall development method makes no sense, so the alternative here is a full top to bottom Agile Project management and development method such as DSDM Atern. (published by the DSDM consortium, not the Office of Government commerce!)

I am dismissing 3 as not very useful. I've read the first book. It flips between one method and another not particularly blending them in any coherent way and comes up with a management structure that has BOTH the PRINCE2 board and the Agile project management team - 5 managers. This seems like a double headed monster. Besides not combining the "Senior User" and "Business Visionary" and also the "Senior Supplier" and "Technical Co-ordinator" there is still the conflicting philosophy of Waterfall and Agile to deal with. The only merit I can see in this split personality approach is for people interested in Agile management but who can't or won't take the leap and abandon PRINCE2 completely. DSDM by itself is enough. It doesn't need to be helped or hindered by PRINCE2 to be a success. The DSDM manual states although the method can be combined with the likes of PRINCE2, "For most organisations, Atern is all that is needed" (P29).

So the front runners for project management techniques emerge as :

1. The existing practices of PRINCE2 and a waterfall development method
2. PRINCE2 incorporating Agile techniques
3. DSDM Atern (or equivalent) Agile project management with Agile development techniques

There is no particular good or bad here; the skill is in choosing the technique most suitable for the project, people, skills, organisational culture, involvement of 3rd parties and so on. In the main however, I think in the new world of government project management we should be starting with 3 as the default position and then move to 2 if there are good reasons not to use Agile project management and to 1 if there are good reasons not to do Agile development. I really think there are few projects which are genuinely in the last category of requiring exclusively waterfall developmentl however. For further information, please see the Agile suitability filter paper [PDF] or the Project suitability filter. Note that both DSDM Atern and PRINCE2 can work alongside methods such as CMMI, see this paper on CMMI and Atern. 

Once we have got a culture that is comfortable choosing the most appropriate techniques for a project, we should revisit the procurement process. This still seems to favour a waterfall like approach of fixed scope rather than an agile like approach of fixed time, cost and quality and having scope as the variable. Once that is sorted I think public sector project management will be in a much better place.

Comments welcome. See also the follow up article.

Craig

PRINCE2 Practitioner

I am a certified PRINCE2 Practitioner if anyone knows of any current jobs (pref contracts) on the go just now in the UK.

Alternatively, if you want commission for referring me, you can do so via Zubka

See also the PRINCE2 group on LinkedIn.

Craig

PRINCE2 on LinkedIn

Please visit this link. I used to run a PRINCE2 group on LinkedIn, but have now closed it (no point in duplication)

Craig

PRINCE2 + AGILE = Common sense?

An article on how Agile can sit alongside PRINCE2 and where DSDM Atern fits in.

In 2007, I put "used an Agile/PRINCE2 development strategy" on my CV. It's been quite the conversation starter at interviews. So I thought it would be of interest to blog about it here and gauge the reaction/feedback.

First off PRINCE2 is an acronym for "PRojects IN Controlled Environments" (version 2). PRINCE2 is a generic project management method for exercising control over a project's startup through to closure (SU1 to DP5 for all you who enjoy punch card like references). It's a generic project management method that had its origins in IT but which now makes no reference to IT and could be used from anything from building a ship to planning your summer holiday. Whether you would want to use it on the latter is entirely up to you. The same flexibility of choice is not however accorded to the large number of public (and increasingly private) sector projects that use it since it is seen as the de-facto project management method and its use is frequently mandated, despite there being other methods that may be more relevant for the task in hand. There have also been a large number of complex and extensive government IT project failures recently many of which would have used PRINCE2 and which highlight that even a refined method such as PRINCE2 can run aground on large scale, long running projects that are subject to considerable change.

On paper, PRINCE2 is logical, reasonable and linear. However, as experience suggests - for example in the long series of failed UK Government IT projects where PRINCE2 is the mandated method - simply being logical, reasonable and linear, is not sufficient. It is not sufficient to make it the effective project management method business and public sector organisations really need."
From PRINCE2 problems by Business Transition Technologies

PRINCE2 is based around project control. Control is clearly a Good Thing, however being a generic method with no reference to IT, the closest IT development method would be the waterfall method, which is very well lampooned on the Waterfall2006 site. It is just these shortcomings of the waterfall method which seem to cause the biggest problems with PRINCE2 projects, especially those which due to their complexity and length of development are prone to large amounts of change. PRINCE2 also does not account for software projects comprising multiple versions and how these are handled, nor for website development and deployment which can be an almost continuous process.

Change is inevitable in projects. In response to this Agile development methods arose to deal with this change more effectively, particularly from a software engineering perspective and unlike PRINCE2, cover in detail the more day to day activities such as sprint planning, daily meeting structure etc. Agile does not have comprehensive cover for project management, however the Agile DSDM development method was developed with PRINCE in mind, as detailed in the paper using DSDM with PRINCE2 [PDF]. Thus the combination of Agile and PRINCE2 is not as contradictory as it might at first seem. One is a development method for managing change, the other is a project management method for exercising control, so the two compliment one another and should result in a management method for control in a changing environment. One can see from this white paper on integrating DSDM into a PRINCE2 environment [PDF] that at the actual delivery level the focus is much more on the agile processes rather than PRINCE2.

Alistair Cockburn (no relation) and others have produced a set of agile management methods however this has grown out of the agile community and consists of a set of principles rather than the sort of detailed how-to that would make it easy to sell to the PRINCE2 diehards.

The most complete agile project management method I have come across is DSDM Atern which is described as follows:

What is DSDM Atern?

Atern is an agile project delivery framework that delivers the right solution at the right time.

Importantly, Atern harnesses the knowledge, experience and creativity of end users. It uses an iterative lifecycle to evolve the most appropriate solution to satisfy project objectives.

Using planned, visible timeboxes with clearly-specified outcomes control is exercised throughout by the project manager and the team members themselves.

Roles are clearly defined and work is divided into timeboxes with immoveable deadlines and agreed outcomes.

Atern Agility
Atern’s agile approach avoids the cumbersome rigidity of ‘big design up-front’ without the inevitable risks of ‘no design up front’.

Since it is worth spending some early time examining the structure of the overall solution before building any components, Atern advocates that projects should do just ‘enough design up front’.

Atern flexibility
Atern can be used to complement other project management disciplines such as PRINCE2 ™ and PMI without duplication of effort.

The description of DSDM Atern on amazon.co.uk explains further:

Atern is the leading, proven, agile approach providing the governance and rigour along with the agility and flexibility organisations demand today. It is also ideal as a wrapper for more limited agile approaches to ensure that the whole project lifecycle is addressed. Atern is a proven 'battle hardened approach' and has been responsible for the successful delivery of innumerable projects around the world. Its provenance across both IT and non-IT contexts goes back to 1994 with substantial productivity gains independently verified by the UK Software Metrics Association.

Making PRINCE2 Agile

So it seems to me that you could use PRINCE2 for the high level governance of a project, Atern for the structure of how the project development is to be organised and prioritised and scrum techniques for the day to day elements of effectively organising the software engineer's time and daily priorities. Although for a true DSDM Atern approach, PRINCE2 isn't needed at all - whilst it is possible to combine DSDM and PRINCE2, DSDM Atern by itself is actually enough and also embodies from the outset the Agile principles which are completely absent from PRINCE2. The particular challenge for Atern lies in integrating Atern projects within a waterfall corporate culture and of DSDM takeup and experience generally, which is unfortunately quite low.

This is just intended as an overview to illustrate that PRINCE2 and Agile are not necessarily contradictory and that is possible to combine elements of both successfully, particularly when it comes to the managing a stage part of PRINCE2 - Agile turns this into many small stages comprising stable components of work suitable for release. However, what remains a mystery to me is why government departments have been so reluctant in the face of the number of IT failures I have blogged about to promote an agile implementation of PRINCE2 and how it can best be delivered for complex IT projects running into billions of pounds. DSDM Atern isn't necessarily suitable for all projects, but certainy for iteratively deployed projects which are happy to embrace change, it should be considered as a more suitable alternative to PRINCE2.

This whole sense approach to software development from project governance to day to day management would seem to be the holy grail for minimising such failures. Perhaps it is time to encourage those who mandate PRINCE2 to understand this in order to minimise further wastage.

Further reading on DSDM is available on the DSDM website and for discussions with the authors of DSDM, I would recommend the DSDM group on LinkedIn.

Craig

Update: in June 2011 I wrote an update covering Agile and PRINCE2.