Sign in

It’s all about delivery - PRINCE2 Agile® White Paper

White Paper

It’s all about delivery - PRINCE2 Agile® White Paper

White Paper

  • White Paper
  • Agile
  • Business solutions
  • Capabilities
  • Portfolio management
  • Project management
  • PRINCE2
  • 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
  • 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!

The value add

The second question we wanted to answer was ... even if PRINCE2 can work with an agile delivery model, why would you bother?

I would like to make the assumption that as a reader you are already convinced of the effectiveness of agile working. There are many aspects of agile delivery that really are exceptional:

  • Product increments are delivered early and often in order of highest business value first.
  • The product increments that meet agreed definitions of ‘done’1 are the primary measure of progress.
  • Products that are fit for purpose are being used by customers to bring about desired outcomes.
  • Continuous learning, discovery and experimentation are harnessed for real improvement.
  • Self-managed and empowered teams that create space for people to thrive.
  • An environment where different and better solutions can be discovered.
  • An environment where we think differently and start to break old habits.

So the key question here is what does PRINCE2 bring to the party? Why should we consider adding PRINCE2 to an agile environment? Assuming that an agile delivery approach is appropriate to the project, let’s look at this from the perspective of the PRINCE2 processes and themes and some of the guidance and additions offered in PRINCE2 Agile.

Let’s start by re-envisioning the PRINCE2 model. The following diagram is perfectly faithful to PRINCE2 and perhaps makes its agile credentials more explicit. The irony here is that PRINCE2 has the capability to be agile, it simply has never been drawn that way.

Image of Figure 2.1 shows the PRINCE2 model


PRINCE2 Processes

Getting started

In PRINCE2 terms the main focus here are the processes Starting Up a Project, Initiating a Project and Managing a Stage Boundary. These three processes establish whether the project as a whole is worthwhile and viable, ensure that all key stakeholders are engaged, and ‘set up’ the delivery stages of the project. This is where we create an environment in which agile delivery can thrive. PRINCE2 adds value to the agile delivery by:

  • Checking that the project is worthwhile and viable from the organization’s perspective before work is carried out. This is done by:
    • Ensuring the project fits with the strategic vision
    • Securing the necessary funding to do the project
  • Ensuring that key stakeholders are identified, engaged and their representation organized. This is done by:
    • Gaining clear sponsorship and a mandate to proceed
    • Gaining buy-in to agile working practices and behaviours e.g. self-organizing teams
    • Identifying and acquiring the resources required for the project
      • Providing resources to create the early product backlog(s)
  • Setting up the delivery stages of the project
    • Evaluating the working environment for its suitability to support agile working
    • Actively supporting the adoption and use of agile by mitigating risks to its success
    • Assessing risks to the project and our preferred approach and instigating remedial actions
      • Tailoring project activities to support agile working within its teams e.g.
        • Management information
        • Created collaboratively in workshops
        • Being less formal, perhaps represented as information radiators
      • The final product(s) of the project being outcome-based (focusing on the delivery of value)
        • Mandatory requirements/stories distinguished from those that are not
      • The business case defined in a flexible way, to allow for the amount being delivered (and its value) to change during the project
        • Focused on how to deliver value regularly and as early as possible
      • Supporting the interfaces between teams who are using agile delivery methods and other teams using different approaches.
        • Sharing lessons, ideas and information
        • Escalating challenges, blockers and impediments
        • Coordinating delivery, timings, releases and approvals.

Delivery stages

In PRINCE2 terms the main focus here are the processes Managing Product Delivery, Controlling a Stage, Directing a Project and Managing a Stage Boundary. These processes guide, track ,report on the project and provide direction for the project. All of this in the context of supporting the product delivery by our chosen means, in this case agile. This is where we maintain an environment where agile delivery can succeed and support its needs. Here PRINCE2 adds value to the agile delivery by:

  • Guiding and directing the project
    • Gaining authorization to continue
    • Supporting key agile roles such as the scrum master(s) and the product owner(s)
    • Engaging with a potentially broad set of stakeholders and gaining ongoing resources e.g.
      • Product owner(s) and subject matter experts
      • Other customer and supply representatives that can support the product owner(s)
    • Providing ongoing funding
      • Maintaining project and stage plans necessary for continued funding and engagement
    • Empowering the team(s) to follow agile practices
      • We often talk of empowered teams but it is easy to forget that this occurs when someone with power delegates it to the team
    • Managing interfaces to and from the project
    • Collating and sharing lessons (retrospectives) within the project
    • Providing guidance when conflicts occur and priorities clash between teams within the project
    • Making decisions about project level change and changes that impact the final product and its quality criteria
      • Change control and decision-making sustained at the overall project level
      • Dynamic change and learning enabled and supported at the delivery level
  • Tracking and reporting on the project
    • Providing any additional reporting to stakeholders beyond that achieved by burn charts and other information radiators employed by the delivery team(s)
    • Providing the information necessary to assess the project in the context of the wider business and its continued viability
    • Supporting the interfaces between teams who are using agile delivery methods and other teams using different approaches
      • Sharing lessons, ideas and information
      • Escalating challenges, blockers and impediments
      • Coordinating delivery, timings, releases and approvals.

Final Delivery stage

In PRINCE2 terms the main focus here are the processes Managing Product Delivery, Controlling a Stage, Directing a Project and Closing a Project. These processes guide the completion of the work, close the project, and set up all ongoing activities post the project. This is where we satisfy the broader project and stakeholder needs after product delivery has done its job. Here PRINCE2 adds value to the agile delivery by:

  • Guiding the completion of the work and closing the project
    • Confirm that the delivered outputs and outcomes still satisfy the business justification for the project and all acceptance criteria have been met
    • Check what has been delivered (note: with an agile delivery approach this is very much easier than in other cases)
      • Identify extra requirements that has been delivered
      • Identify what elements have been removed
      • Build upon the incremental and iterative delivery achieved by agile working practices to gain clarity in the delivery of our project goals and objectives
    • Make final updates to project information and plans
    • Final retrospectives are held and project lessons identified and shared
  • Setting up all ongoing activities post the project
    • Ensuring that product recipients are in a position to own those products and use them on an ongoing basis
    • Finalise plans for measuring any future benefits and value that will be realized by use of the projects products after the project
    • Outstanding work on the projects product backlog(s) are moved to ongoing BAU backlog(s).

PRINCE2 Themes

A similar thoughtful attitude applied to the themes ensures an equally useful and appropriate tailoring process that adds value to core agile delivery and builds bridges between the larger organization and other differently organized delivery teams. The PRINCE2 themes describe aspects of project management that must be addressed continuously. The themes link together to support delivery. The PRINCE2 Agile manual offers a comprehensive explanation of this, however examples are as follows:

  • Business Case
    • Developed iteratively and reviewed to ensure there is an ongoing business justification
    • Key to engaging the wider business and securing resources and funding
  • Organization
    • Key to designing roles that represent a wider stakeholder group, multiple stakeholders, multiple and different delivery streams
  • Plans
    • Support to agile information radiators
    • Means to secure funding
  • Progress (and additional information regarding frequent delivery)
    • Stages, releases and sprints coordinated and integrated
    • Management by exception, the ability to escalate blockers
      • Move the emphasis away from time and cost and onto scope and quality
      • Consistent timeboxes and stable teams reduce the changes in time and cost
      • Negotiation and discovery of the best scope and quality make these the areas where the most change is seen
  • Quality
    • Fit for purpose established and guidance provided on identifying the elements that must be delivered and where ongoing variation is acceptable
  • Change (and additional information regarding requirements)
    • To support detailed change and control-project wide change
    • To enable the team to negotiate the details of scope and quality
    • To enable the organisation to manage the big picture
  • Risk (and the agilometer, see Figure 2.6)
    • Still important at the project level and to manage risks to our delivery mechanisms
    • An approach to address any weaknesses in our environment when creating an agile friendly space.

PRINCE2 Agile combines the PRINCE2 concept of setting tolerances (what to flex) for project variables with the agile timebox view of fixing time and cost and varying quality. This is illustrated in the PRINCE2 Agile guide and in Figure 2.2.

Image of Figure 2.2 showing diagram of applying tolerances to the six aspects of a project


PRINCE2 Agile goes even further by adding new sections where it provides guidance on elements outside of the usual PRINCE2 scope to further support agile delivery:

  • Behaviours
    • Specific behaviours that need to function smoothly for agile to operate in the most effective way
      • Transparency
      • Collaboration
      • Rich communication
      • Self-organization
      • Exploration.
  • Agilometer
    • How to assess the agile environment in order to tailor PRINCE2 in the most effective way, see Figure 2.3
  • Requirements
    • How to define and prioritize requirements (stories) so that they are in a form conducive to working in an agile way
  • Rich communication
    • How to create effective communication flows between stakeholders
  • Frequent releases
    • The importance of frequent releases when using agile
  • Contracts
    • New ways of thinking about traditional contracts to address agile working practices.

There is already a wide body of opinion that, in order to scale, agile frameworks need something more to help them manage their environment and context. The new idea here is that in the project context the most obvious tool to achieve this is PRINCE2. Far from it being the antithesis of agile that some suggest, PRINCE2 is actually perfectly placed to support and enhance agile delivery.

Image of Figure 2.3 showing the Agilometer


1 A set of criteria that is used to determine if a piece of work or a collection of work items is completed. Something is either ‘done’ or ‘not done’.

The packaged solution

So we have made a case for agile delivery and PRINCE2 projects being much better partners than myth and rumour suggest. We have identified the value that a well-tailored PRINCE2 project can bring to straightforward agile delivery and the way that, within the project space, it can:

  • help to integrate agile delivery teams into mixed delivery streams
  • interface with the broader project environment and stakeholders
  • protect and champion agile behaviours, frameworks and concepts
  • actively deliver the most agile friendly environment practical.

Well-tailored PRINCE2 has no negative impact on the internal working practices and behaviours of an experienced and effective agile team. It supports the efforts of:

  • product owners in coordinating and engaging with stakeholders
  • scrum masters in problem solving, blocker resolution and collaboration outside of the delivery team
  • the delivery team in educating stakeholders and actively managing and enhancing the project environment’s agile characteristics.

Even more than the points above, well-tailored PRINCE2 can expand the use of agile into greater and more complex projects and businesses. PRINCE2 can help agile grow... and PRINCE2 Agile is the roadmap.

The rate of change and the volatility of business has never been greater than today. To meet the challenges that businesses face they need agile delivery in the toolkit. It is not always the solution but it is a solution that is too important not to have available. However, not all businesses can change their working practices to encompass agile working without also suffering the challenges and consequences that mixed delivery brings.

We succeed in this challenging world not by building islands of success or by thinking in silos, but by utilising effective practices. We need to blend models and ideas to get the best from the tools and frameworks that we have. The goal is to constantly reinvent ourselves and our approaches to address the needs of the business.

In PRINCE2 we have one of the best project management frameworks ever created. In agile frameworks like Scrum and Kanban we have some of the best, and perhaps right now most appropriate, delivery frameworks conceived. By blending the two we have, in a project context, the best of both worlds.

PRINCE2 provides an interface and plays a coordination role that enables agile work streams to succeed in complex project environments.

Image of Figure 3.1 showing the business environment


Conclusion

If you are an agile practitioner and professional working in an organization that uses agile and other development approaches, then take a look at PRINCE2 Agile. You will find an interesting companion to your work containing few challenges to your vision and much that you will like and appreciate. More than that you will see a method that has been tailored by an agile team who have real empathy for how you work and what you believe in. PRINCE2 Agile can actively support agile delivery, and what it brings to the party is useful and perhaps necessary to grow the use of agile in a broader set of environments.

If your organization currently uses multiple delivery mechanisms to meet your varied needs and you are looking at agile adoption, let PRINCE2 help you integrate its use into your working practices. PRINCE2 offers a single guiding approach to integrate developments whatever the nature of the approaches in use.

Finally, I would like to put forward the idea that PRINCE2 Agile is not just for PRINCE2 environments that want to adopt agile practices for delivery. It is also for agile environments and teams that are passionate about the benefits of their working approaches and want those approaches to be used in a wider number of situations within their business. By using PRINCE2 Agile tailored PRINCE2 to manage the aspects of business practice that fall outside the remit of agile frameworks like Scrum and Kanban, first class agile delivery can grow and succeed in any project environment.

About the author

Duncan Wade (www.hic.co.uk) is a Director of Human Interface Consultancy Ltd. He is the Lead Trainer and Course Author of the Learning Tree International courses on PRINCE2 and PRINCE2 Agile, and a working professional in the field of project management and agile delivery.

Duncan-Wade.jpg

Reviewer

Larry Cooper, Agility Series Facilitator at BSSNexus Global Inc.

It’s all about delivery - PRINCE2 Agile