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.

About the author

Related Posts:

Agile Principles and Practices to Mitigate Integration Issues

How to mitigate Intgertaion issues? – In the short term, transparency and communication is key. In the longer-term, we needed a more empowering state so we looked at how to to use agile practices to build capability and evolving environment practices to move to automation and continous integration.


Setting up a New Agile Team

When setting up new agile teams we have found that starting small with the basics and adding patterns as they start to develop capability has helped us get new teams up and running within 2-3 days and acheive a baseline of agile capability within 3 months


Measuring agility with Agile IQ

Agile delivers significant benefits over traditional ways of working, but how do you know when you’re agile? How do you use a metrics-driven approach to create repeatability, consistency, and scalability of agile capability across the enterprise? Agile IQ is the key.


Product Management versus Project Management

Gartner reports that 85% of executives are now turning to agile product management over projects. Why is this shift occurring and what do you need to know about product management to optimise your strategic investments for greater market share, better ability to pivot, or get your products to market faster?


Remote PI Planning – Insights into what worked and what didn’t

Running remote PI planning for the first time 100% virtual was a bit daunting a few weeks ago when the reality set in that with the current crisis, this was now our reality. We prepared, thought through worse case scenarios and had back up plans and felt eerily calm as the day began. It was a great success and here are our tips.


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

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