PRINCE2 processes vs Agile development frameworks

UPDATED: 27/05/2017
PRINCE2 has been the gold standard for project management certification for over a decade. It’s commonly a prerequisite for project managers and is recognised as being essential for keeping projects “in control” particularly in the public sector in Australia where Zen Ex Machina does a lot of its work. I think it is with great sadness, however, that PRINCE2 is synonymous with Waterfall project execution and is, therefore, seen often believed to be incompatible with agile methods. Nothing could be further from the truth.

What is PRINCE2?

PRINCE2 is all about process. It’s best described in a linear fashion from starting up a project, initiating it, managing product delivery within stage boundaries, and then closing the project down so it can be handed off to business-as-usual.

The assumptions made by many is that this process prescribes a Waterfall approach to the project’s execution. That is:

  • A Stage is equivalent to a stage in the Waterfall methodology.
  • There should be a Stage for each of Analysis, Design, Development and Testing.
  • Before moving from Design to Development, the project requires a “locked-down”, complete and comprehensively detailed set of requirements.

It’s important to note that PRINCE2 is sometimes considered inappropriate for small projects or where requirements are expected to change throughout the project. In particular, this is because there is a significant workload in creating and maintaining PRINCE2 documents, logs, registers and lists. However, the Office for Government Commerce (OGC) in the UK suggest that PRINCE2’s processes are  intended to be scalable and should be tailored to suit the specific requirements and constraints of the project and its environment [1]. Without tailoring these processes, when a project needs to quickly adapt to a change in environment, business needs, user needs, or even system needs, the project becomes bogged down in red tape, reporting, committee meetings and lengthy approval processes, that instead paralyse rather than quickly enable the project to act to change direction. This difficulty in being able to adapt to change is ultimately the primary reason why Waterfall projects continue to fail [2].


What is Scrum

Scrum is the most popular [3] of the agile frameworks. It’s not a methodology or process, but rather a series of key opportunities to inspect plans, delivery practices, and an potentially releasable product increment every 2-weeks. The result is reduction in risk through transparency of the relationship between activities and an outcome following shortly thereafter (over waiting what in Waterfall is often months if not years).
Scrum is designed, unlike PRINCE2, as a framework for product or project execution over its explicit management. The Agile Manifesto reinforces that Scrum’s success revolves around acceptance that requirements are likely to change and that the most effective way of understanding change and accommodating it is through close collaboration with clients, stakeholders and users.
Importantly, Scrum is design for use in complex environments. The transparency created through multiple feedback loops provides a significant risk-mitigation capability.
Where Scrum tends to fall down, therefore, is through inexperience [3]. It’s not black and white. It’s not a process of sequenced events. While its rules are simple, it’s the interpretation and application that is shades of gray, and require experience to do that interpretation well.
I’ve heard many Project Managers recently claim to be “doing agile” and “doing Scrum”, but what they are referring to is the use of a Daily Scrum (or Stand-ups) and yet continue to employ command-and-control, Waterfall task-driven project methods, rather than Scrum’s continuous planning, commitment, execution and review events that surround delivery of Products at the end of each Sprint.
Success with Scrum requires more than just doing “stand-up” meetings. Scrum employs robust, disciplined mechanisms of empirical process control, where feedback loops that constitute the core management technique, are used as opposed to traditional command-and-control management. Unlike PRINCE2, and other Project Management processes, it’s not designed to be a “pick and choose” affair [4]: you don’t pick the pieces out of Scrum you think will work with the environment or the ones you might like the most. Its authors, Schwaber and Sutherland, designed Scrum as a complete set of events for project planning, requirements, governance and development and implementation. It brings participative management and decision-making to an operational level to engender transparency, and creates repetitive cycles of work that promote sustainability and predictability. This enables decision-making at an executive level to occur based on operational certainties at a project level rather than using predictions based on schedules and Gantt charts.

Putting PRINCE2 and Scrum together

The key to unlocking PRINCE2 with Scrum is to use Scrum in the Managing Product Delivery stage.
Here, Scrum helps the team to focus on delivery every Sprint that coincides with PRINCE2’s management reporting requirements and projects’ committee meeting cycles. These critical integration points are:

  • Project plan — Contains a preliminary Release Plan outlining Scrum’s Sprint cycles.
  • Stage plans — Contains description of the scope to be developed as defined by Scrum’s Product Backlog, typically at a medium level of detail.
  • Work packages — Contains the details of the scope (“Product Backlog”) that is committed to delivery for a Sprint, the acceptance and quality criteria (“Definition of Done”). At the end of each Sprint, completed Products are delivered with associated artefacts and deliverables defined by that Work Package.
  • Lessons learned — Each Sprint concludes with a lessons learned (“Sprint Review”) to improve quality and efficiency of the project’s delivery for subsequent Sprints.
  • Reporting — At the end of the Stage, the Project Manager incorporates Sprint Review Reports into the End Stage Reports.

Conclusions and adoption

PRINCE2’s focus on managing projects through stages with appropriate levels of governance, and its mandated approach to adapting its methods to suit the project and its environment, enable Scrum and its Sprints to easily operate within Stage Boundaries and within the Managing Product Delivery phase. Scrum and PRINCE2 are perfectly compatible in this way, but ultimately require knowledge of and experience in both to produce an efficient framework that can easily adapt to change.
– – – –
1.  Office for Government Commerce. Best Management Practice – PRINCE2.
2. Standish Group (2011) THe CHAOS Manifesto.
3. VersionOne (2013) State of Agile Development Survey.
4. Ken Schwaber and Jeff Sutherland (2016) The Scrum Guide™. The Definitive Guide to Scrum: The Rules of the Game.

1 thought on “PRINCE2 processes vs Agile development frameworks

  1. Great Article! I do think though no matter how qualified you are with all these training courses you do need to have a bit of common sense and you need the ability to assess each situation differently. Looking at the difference between the waterfall approach and agile methodology from you pie chart will not give a clear indication of which is better then one because there are various other reasons of why a particular project could have failed and therefore the diagram may be biased to a certain extent.

Leave a Reply

Related Posts:

“Netiquette” for online meetings for remote and distributed teams

As with face-2-face meetings, online meetings also have an etiquette (“Netiquette”) to make them effective. One of the 12 principles of the agile manifesto suggests face-to-face is the best option but in today’s world of social distancing and WFH, it is no longer an option.

Here are the guidelines we have found useful for having for online meetings with distributed


22 Stances of a Scrum Master

The Scrum Master doesn’t remove impediments from the team. Their job encompasses 22 wider stances for supporting the team to self-organise to remove impediments themselves, coaching the Product Owner and coaching the wider organisation.


Does agility go out the window when we work remotely?

Many organisations are making guidance on what tools to use for remote teams in response to COVID-19. The situation isn’t a tools problem. This is a people problem – how can people, who are social creatures, successfully work remotely without physical interaction?


Copyright © Zen Ex Machina® and ™ (2019) All rights reserved. ABN 93 153 194 220

search previous next tag category expand menu location phone mail time cart zoom edit close