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 . 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 .
What is Scrum
Scrum is the most popular  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 . 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 : 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.