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?
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:
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 .
Scrum is the most popular  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 . 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.
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:
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.
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.
How do you write great User Stories?
Facilitators can use many techniques, but this does guarantee that the outcome will be reached. Ultimately linking the facilitation pattern to the objective of the interaction, makes the event more effective and helps contribute to team success in achieving their goals.
An effective Product Owner is a strategic agile product manager that ties the Product Vision into the daily work by having a product management entrepreneurial mindset.
People complain that agile has too many meetings. To be effective, agile events need to be focused, productive, collaborative with a clear purpose
How do you create an Increment of work in Scrum? What has it got to do with the Product Goal and Definition of Done?
What metrics do you need to understand whether you’re going to achieve enterprise outcomes for agile transformations
Copyright © Zen Ex Machina® and ™ (2021). All rights reserved. ABN 93 153 194 220