PRINCE2 and Agility: Gearing for Balance


Welcome to the second article in this two part series. Last month we looked at some of the problems that are commonly associated with Agile Methods when they are viewed in the context of process rigor. We saw that a reconciliation between emergent and prescriptive disciplines can be achieved via a model of orthogonal standards and frameworks. We contrasted that model with the more commonly assumed “continuum” hypothesis, which locates predictive and emergent processes at opposite ends of a methodological spectrum.

This month we will explore in more detail the remedial, standards-based approach adopted by Codeworks DEV. We’ll show how a specialised, tool-supported, configurable toolset can be used to leverage Agile Methods across multiple PRINCE2 projects at both delivery and programme levels.

Configuration of the Agile process

The Codeworks DEV Programme was conceived as a vehicle for getting innovative IT ideas to market. Funded from a mix of both public and private sources, the programme has gone on to encompass hundreds of projects, each of which can be at a different stage of development. Such projects tend to be characterised by an emergent scope – exactly the sort of thing that Agile Methods are known to handle well. Yet there was also a narrative (and somewhat linear) flavour to this work. Project stakeholders are guided from problem discovery to problem definition, and from there through solution development to solution delivery (the “4 D’s”).

Our hope was that the new version of PRINCE2 released in 2009 would be scalable enough to accommodate this simple narrative model. We also hoped that we could further the headway that others had made with DSDM previously [Richards, 2007], [Barron, 2003]. The scope of method configuration therefore included a number of considerations. We needed a programme-level approach to PRINCE2-Agile configuration, and not just as a project-specific one. Also we sought a more orthogonal and standards based solution than can be remedied by “mixing and matching” from parts of an assumed methodological continuum.

We decided to handle Agile-PRINCE2 process configuration in three stages:

1) Firstly, the “4 D’s” would have to be fleshed out with the details of the business process. For example, the “Discovery” stage includes discrete steps for identifying any new IP behind a candidate project, the likely economic benefits, the business case (with repeated checks for project viability), desk based market research, and other such details of project inception. We decided to use a simple flowchart grammar to model these flows.

Also, the business process model would need to be rationalised along broadly Agile lines. We decided to keep the Delivery Stage free of DEV specific business flows until we had enough information to make a firm decision on the operational characteristics of this phase. We therefore constrained its immediate scope to a dialogue between client, project manager, and supplier based on iterative-incremental delivery.

2) It was already established that PRINCE2 was going to be a key process component, representing as it does a defensible and widely accepted standard for project management. We therefore arranged PRINCE2 Practitioner training for all DEV team members. This gave us the vocabulary needed to define DEV’s roles and responsibilities in PRINCE2 terms, as well as management and work products (see Figure 1), and to map each of the “4 D’s” to the PRINCE2 process.


Figure 1

3) Thirdly, we needed a process management tool that would support DEV stakeholders – not just project managers, but also clients and suppliers – throughout the prototyping of each project. A variant of MoSCoW analysis [Clegg, 2004] would synchronise expectations across a common acknowledgement of scope. The initial requirements were:

a. This tool would have to support Agile Methods and be PRINCE2 compliant

b. It should be configurable in the sense that DEV’s own business process flows should not be hard coded.

c. It should be possible to customise process flows as necessary on a per-project basis

d. It should be possible to embed timeboxes and MoSCoWing activities at any point in a flow.

e. Requirements should be definable for each project

f. MoSCoWing of requirements and allocation to timeboxes would have to be fully supported. This would clearly be important during the Engineering Phase (DEV Delivery). There might also be opportunities for MoSCoW analysis when negotiating with market research companies in the Feasibility Phase (DEV Discovery).

No satisfactory tool was available as a


About the author

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!