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. PRINCE2 is synonymous with Waterfall project execution and is, therefore, seen often believed to be incompatible with agile methods. Is this true?
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 framework of empiricism with a series of key opportunities to inspect plans, delivery practices, and deliver a potentially releasable product increment every 2-weeks. The result is reduction in risk through transparency of the relationship between activities, an output, and its outcome.
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, short, feedback loops, provides a significant risk-mitigation capability.
Where agile tends to fall down, though, is 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
One way to use PRINCE2 with Scrum, is to use Scrum in the delivery stage.
Here, Scrum helps the team to focus on delivery every Sprint in a way that aligns with PRINCE2’s management reporting needs and the projects’ board 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 (“Retrospective”) 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.
Scrum inside PRINCE2 has significant limitations
Where PRINCE2 seek to decrease risk through an initial set of definition and planning stage gates, instead Scrum decreases risk through short cycles of work (“Sprints”) that provide feedback on whether actual progress aligns to the need of stakeholders. What typically results in putting the two together is a Waterfall version of Scrum or “Water-Scrum-Fall”. This ends up delaying the delivery of an Increment to inspect and adapt to reduce risk in favour of developing a fully detailed plan (that will need to change and adapt anyway). These delays are a few months for small projects. For large programs of work, this approach can delay the commencement of producing an Increment by years.
Conclusions
PRINCE2’s focus is managing projects through stages of senior levels of governance. Once a project reaches the delivery stage, Scrum is then often employed. While perfectly compatible, using Scrum in this way doesn’t fully utilise its powerful empiricism practices – inspection and adaptation to mitigate risk and empower people to adapt and pivot rapidly to change.
A delay of months, in a world where markets can be disrupted in a matter of days, and stakeholder needs can change rapidly, is unacceptable in the 21st century.
This delay in starting to deliver value is the major reason why Gartner reports that C-level executives are now moving to product management frameworks.
If you are going to use project management with an agile framework like Scrum, be ready to pay for delays. Be prepared to wait for stakeholders to sign-off plans and solution requirements.
M
– – – –
1. Office for Government Commerce. Best Management Practice – PRINCE2.
2. Standish Group (2011) THe CHAOS Manifesto.
3. VersionOne (2020) State of Agile Development Survey.
4. Ken Schwaber and Jeff Sutherland (2017) The Scrum Guide™. The Definitive Guide to Scrum: The Rules of the Game.
