Sign in

It’s all about delivery - PRINCE2 Agile®

White Paper

It’s all about delivery - PRINCE2 Agile®

White Paper

  • White Paper
  • Agile
  • Business solutions
  • Capabilities
  • Portfolio management
  • Project management
  • PRINCE2 Agile

Author  Duncan Wade, Director of Human Interface Consultancy Ltd

October 25, 2016 |

 17 min read

  • White Paper
  • Agile
  • Business solutions
  • Capabilities
  • Portfolio management
  • Project management
  • PRINCE2 Agile

The goal of this paper is to introduce PRINCE2® and PRINCE2 Agile® to people working in agile environments. It is about the tremendous potential that exists if agile delivery teams choose to make use of PRINCE2 to enhance their ability to succeed. It is about making a case that this can be done successfully without compromising either the spirit or the environment that good agile teams enjoy.

Therefore, I want to begin by presenting PRINCE2’s agile credentials. I know that will sound strange to many people but, perhaps unexpectedly, they are rather good. One of the challenges that we face when we discuss PRINCE2 in any context is the number of myths and misconceptions that abound about the model. Many think they know what it is and how it works. Yet the reality is often very different.

PRINCE2 myths:

  • Top-heavy
  • Waterfall-based
  • Focuses on command and control
  • A sledge hammer to crack a nut

Figure 1.1 shows diagram representing PRINCE2 misconceptions

PRINCE2 in fact:

  • is a tailored framework,
  • focuses on appropriate governance,
  • sets up a project environment that enables delivery,
  • is agnostic as to how you choose to deliver,
  • makes no mention of command and no mention of waterfall,
  • has many mentions of small and light management relative to the size of the job

Figure 1.2 shows diagram to represent PRINCE2 in reality

It cares a great deal about how you deliver the solution, not in the sense of ‘this is right’ and ‘that is wrong’, but by asking the question ‘what do you need to be successful?’

We have created some of the misconceptions about PRINCE2 ourselves. It is interesting to see the way PRINCE2 is drawn when compared to other familiar models.

Figure 1.3 showing hand drawn image of the contrast between Waterfall and agile phases

These diagrams come from the PRINCE2 Agile manual and they are included to help us to distinguish Waterfall thinking from agile thinking. In simple terms they illustrate the perception that Waterfall describes a linear approach whilst agile is iterative and incremental.

Figure 1.4 showing hand drawn image of basic backlog and sprint structure for delivering software

This is another classic piece of imagery for agile and in particular scrum. Please note the repeat is crucial to that iterative thinking.

Figure 1.5 is most often seen in the PRINCE2 and PRINCE2 Agile manual. It is used as a quick reference guide for PRINCE2.

Image of Figure 1.5 showing life of a PRINCE2 project diagram

So what does it look like and how would you categorize it? It is not surprising that many people believe that PRINCE2 is a Waterfall model! We create our models but they then influence our thinking. What began as a short-hand approximation becomes a defining guide, how could PRINCE2 be agile?

So, let’s return to the questions in hand.

  • First, ‘can PRINCE2 work with an agile delivery mechanism?’
  • Second, ‘even if it can why would you bother?’

Can PRINCE2 work with an Agile delivery mechanism?

Plenty of myths suggest it can’t and our own diagrams imply a mind-set that doesn’t feel very appropriate. We need to go back to basics to get a clear view of this puzzle.

It is important to remember that PRINCE2 was built to be tailored. Furthermore the 2009 edition ensures that PRINCE2 can be tailored for any type of project, including Waterfall and agile delivery. The processes, themes and products are all described in the PRINCE2 manual as a base from which to tune the needs of the project. They are a neutral starting point. The only part of PRINCE2 that should not be tailored is its principles. So if we want to demonstrate PRINCE2’s agile capabilities we will need to see them here. PRINCE2 has seven principles; let’s look at what they say:

PrinciplesPRINCE2Agile PerspectiveComment
Continued business justification 

A project needs a good business case to begin  and that business case needs to be checked regularly to ensure that it remains sound. Should it stop being sound, the project should be stoppedEach timebox of effort delivers a shippable product that has measurable business value. If the work selected next does not have sufficient value, we  stop.Match
Learn from experienceCapture learnings, share learnings, use learnings to make this project (and others) more effectiveRegular retrospectives that review our performance in this timebox generating improvements that are Match
Managing by exception Delegation from one level of management to the next below. An early warning system where we monitor key performance targets and escalate potential problemsTeams are empowered. Work pulled forward into based upon velocity or cycle time and priority. Problems are raised in daily stand-upsThe intentions are similar.
Both focus on practical real world self-empowerment.
Focus on products

A successful project is output-orientated.
Deliver products and don't get lost focusing on being busy. PRINCE2 also advocates product-based planning which enables us to clearly see the products being created in stages and work packages.

Deliver shippable product to an agreed definition of done. Using a pull system, the focus is on finishing things not on work in progress (WIP) itself Match
Defined roles and responsibilitiesDefine roles that engage the business, user and supplier stakeholder interests. Answers the question what is expected of me? PRINCE2 defines the governance roles and simply wants us to define any other roles clearly.Scrum defines three roles: scrum master, product owner, generalizing team member.  Kanban defines no roles though does suggest that we continue with existing roles at least at first. No conflict, focus is on different parts of the team. PRINCE2 defines project governance and management roles where Scrum's focus is more on the delivery roles. PRINCE2 Agile looks at the interface between them.
Manage by stagesProvide senior management with control points where decisions on the future of the project can be made.Sprint reviews provide the stakeholders with control points at the end of each timebox.Match
Both provide structure.
Both engage the stakeholders in understanding where we are now and providing information for their decision as to what we do next 
Tailor to suit the project environmentEnsure that the project management method relates to the project, project controls are based upon the project's scale, complexity and importance.
Review and update this at each stage boundary 
Inspect and adapt.
Review working practices and adjust them to be successful.

So we have made a good start ... the PRINCE2 principles are broadly aligned with current agile thinking. Indeed they describe a world that can easily be pictured as very agile. It is interesting to note that several members of the PRINCE2 author team worked in agile environments and wanted to make sure that PRINCE2 was compatible with their everyday working practices.

However, there are differences. The most obvious one is scale and perhaps that sets the scene for a fruitful partnership. PRINCE2 is talking about the project as a whole with a focus on governance and management. Most agile frameworks talk about delivery with a focus on products or product increments being completed, they offer consistent ongoing delivery of small yet valuable products.

However, before we move on, it might be interesting to do the reverse ... how comfortable is PRINCE2 with the agile manifesto and its supporting principles? I would also like to introduce PRINCE2 Agile here as well; this starts to give us guides and recommendations about how to tailor PRINCE2 for an agile delivery.

Agile ManifestoPRINCE2 perspectivePRINCE2 Agile tailoring recommendations 
Individuals and interactions over process and toolsPRINCE2 presents a large number of processes. However, it sees then as a way to support individual working and clarify interactions. The PRINCE2 principles 'manage by exception' mentioned in the table above also focuses on empowering the team and individual. PRINCE2 Agile recommends a light touch. It supports the statement explicitly by recommending the creation of a self-empowered team supported by the simplest practical processes. It adds more guidance about rich communications and their value in team-working. It emphasizes collaboration and transparency and several other important behaviours.
Working software over comprehensive documentationPRINCE2 also focuses on products (it includes software but its not restricted to it) As we have seen before it in an explicit principle. It also gives lots of guidance for the sort of management documentation that you might need if the project is large or complex enough. It has no guidance for what is right or correct for technical documentationPRINCE2 embraces the Agile delivery mechanism. The regular delivery of useful product is seen as one of the primary measures of project performance. In the spirit of Agile, detailed documentation is kept to the minimum necessary to ensure the correct level of quality is achieved.
Customer collaboration over contract negotiationPRINCE2 strongly emphasizes the creation of clear roles and responsibilities that represent three distinct viewpoints: the business, the user (customer) and the supplier. It believes that clarity of roles leads to clarity of interactions. It only uses the word contract to describe the promises made by the project team to its customer stakeholders with regards to project working practices. PRINCE2 Agile builds upon the basic PRINCE2 roles by adding other potential roles to support stakeholder representation and collaboration. It also adds significant new content about the key aspects of how an empowered team interacts and the value that this has to the project
Responding to change over following a planPRINCE2 explicitly manages change at project level. It provides guidelines for plans at all levels (project, stage and team) It strongly recommends tracking change and progress and provides guidance as to how this can be managed. Within the scope of their authority, every level of management cam amend plans as necessary to address change.PRINCE2 Agile expands change at the project level and explains change a the product level. I t provides guidance on how these two different visions can work together to create improved product delivery planned and intended scope, and objectives. Explicitly brings the Agile paradigm onto a controlled environment. New content relating to requirements and within change add clarity to the ideas.

Table 1.2 Mapping the Agile manifesto against PRINCE2 and PRINCE2 Agile

Although the agile manifesto was written from a software development focus there are many industries that use techniques such as iterations, rapid prototyping, and timeboxing to great effect. Therefore PRINCE2 Agile shows how these agile approaches can be used in any industry sector and not just IT or software development.

So perhaps the best characterization of PRINCE2 as regards the agile manifesto is that there is no conflict with the ideas, but not all of the ideas are explicitly addressed in the PRINCE2 manual. PRINCE2 Agile addresses the concepts directly and provides guidance on how PRINCE2 can be used to bridge any gaps and adds new material where appropriate to blend the visions.

So, in this first section I hope we have challenged a few myths, re-established some baselines and started to blend the best of both visions into a stronger whole.

In the context of agile working it might be said that PRINCE2 does well in spirit but it can be seen to be narrow in its focus. It has always looked at creating an environment where the project can win, not particularly at how that will be achieved in product delivery. For most of PRINCE2’s existence that has often meant creating an environment that supports waterfall delivery. It has done that very well. In an agile context we need to look at it again and tailor it appropriately. It has weaknesses in this context but they are by omission not error or conflict. PRINCE2 Agile has added ideas to the basic PRINCE2 model to address those weaknesses and fill the gaps.

If we look at just one of Agile’s principles we can see a bridge between the visions:

‘Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.’

Now that is a vision that PRINCE2 can deliver!