CHAPTER 3: OVERVIEW OF PRINCE2 AGILE

PRINCE2 Agile is an adaptive governance method for project delivery which combines senior management’s ongoing need for business-value confirmation and due diligence with the empowerment and flexibility that the project team needs to deliver the required outcomes.²² It is the first extension module to the PRINCE2 method.²³

PRINCE2 Agile combines PRINCE2 and Agile methods in a way that both

• maintains the integrity of the PRINCE2 principles, themes, processes, roles, and project artifacts described in Chapter 1: Overview of PRINCE2 and
• delivers the efficiencies and core benefits of Agile methods described in Chapter 2: Overview of Agile.

Figure 4, from the AXELOS PRINCE2 Agile Official Guide, provides an overview of how these two approaches are combined into a cohesive framework.

Figure 4: Tailoring PRINCE2 by blending in the Agile ingredients

Copyright © AXELOS Limited 2015. All rights reserved. Material is reproduced under licence from AXELOS

This section details how these two approaches work together cohesively, and the corresponding benefits that they can provide for your organization.

Why PRINCE2 Agile?

There is a broad range of benefits that can be achieved by implementing the PRINCE2 Agile framework for your projects, including:

• Increased rates of on-time and on-budget project delivery with project outcomes continually confirmed to meet business requirements.
• More cohesion between senior management and project delivery teams.
• Greater transparency and communication on ongoing project status for all stakeholders.
• Flexibility for you to adapt project work to meet changing requirements.
• The reliability of using a best-practices framework with formal training and globally recognized certification.

The specific benefits that your organization can achieve with PRINCE2 Agile will depend upon the methods that you are currently using for governance and project delivery.

For existing PRINCE2 organizations, the implementation of PRINCE2 Agile takes the value of project governance to the next level:

• Information on project status is continuously available to the Project Board and project manager as needed, instead of waiting for highlight reports, checkpoint reports, end stage reports, or raised exceptions.
• Project delivery teams are continually focused on delivering the highest business-value capabilities throughout the project.
• Project delivery teams are empowered to do the work that is required without significant reporting overheads or delays awaiting approvals.

For organizations who are implementing PRINCE2 Agile without an existing governance framework, these benefits are substantially more prominent, as the organization will gain both the immediate and ongoing advantages of having well-managed business outcomes with the high-productivity, value-driven focus of Agile methods at the same time.

PRINCE2 Agile achieves this integrated approach by establishing baseline requirements for projects to adhere to and then allowing the organization and the project team the flexibility to determine what roles, processes, and artifacts are needed specifically for each project. For this reason, PRINCE2 Agile is “Agile agnostic,” supporting the Agile method(s) that are best suited to your organization and your projects.²⁴

The following section describes how PRINCE2 Agile is able to provide this flexibility and deliver these benefits to your organization.

How does it work?

Figure 5 shows a summary of PRINCE2 Agile and how these methods work together.

Figure 5: Overview of the PRINCE2 Agile integrated governance and project delivery framework

At the top of the diagram is the PRINCE2 project governance structure, with:

• Project work driven by a justified business case (the project brief) and a structured project delivery approach (the PID).
• Project oversight provided by the Project Board.
• Ongoing management and communication of project activities by the project manager using traditional PRINCE2 reporting tools.

At the bottom of the diagram is the selected Agile method for project delivery, with empowered teams undertaking priority-driven work using time-boxed iterations or capacity-based “pull” flows, along with high-value communication tools and frequent feedback channels.

In the middle of the diagram are the key touchpoints that allow PRINCE2 and Agile methods to work cohesively in the PRINCE2 Agile framework:

• Requirements as Outcomes and Acceptance Criteria: the capabilities that the solution is expected to deliver, described in a way that allows the product owner to make adjustments (i.e. “minor changes”) and assess acceptability during each stage without significantly altering the expectations of the Project Board.
• Controls and Tolerances: the project variables that need to be managed as the project progresses (Benefits, Scope, Time, Cost, Quality, and Risk) in accordance with the acceptable levels identified by the Project Board. In PRINCE2 Agile, it is expected that some of these variables will be fixed (Time and Cost), some will have expected levels of flexibility (Scope and Quality), and some will be either fixed or flexible, depending on the nature of the project (Benefits and Risk). This distinction is further explained in the section below.
• Outputs: in PRINCE2 Agile, the most important measures of project progress and ongoing business value are the potentially releasable capabilities that the project delivery team produces in each management stage – and their adherence to the agreed acceptance criteria (i.e. the quality criteria in PRINCE2). The business value that is produced in each stage is one of the most significant measures for the Project Board to determine the ongoing viability of the project and approve subsequent stages.
• Issues and Risks: as the project progresses, it is the responsibility of the entire project delivery team (not just the project manager) to identify potential issues and risks that could jeopardize the expected project outcomes.
• Communication: as high communication is a critical factor in the success of PRINCE2 Agile projects, this is an overarching, continuous, bidirectional connection between the Project Board and the project delivery team.

The outputs from the project delivery team are bundled for delivery in Iterations, Releases, and Stages, as required by each project.

The project manager and the team manager sit between Project Governance and Project Delivery, acting as a bridge between the Project Board and the project delivery team to identify required work, facilitate communication, escalate issues, and ensure compliance with the PRINCE2 Agile governance requirements. An important distinction in PRINCE2 Agile is that these are primarily servant leadership roles, where the project delivery team is responsible for managing their work, and the project manager and team manager are there to support the team’s work and remove any obstacles to project delivery.

At first glance, it may appear that PRINCE2 Agile is essentially PRINCE2 and Agile working concurrently. It is true that there are many aspects of PRINCE2 Agile that retain features similar to those of each respective approach, but there are also significant differences that make this combined approach particularly powerful, starting with the key principles that govern PRINCE2 Agile work.

Key principles

PRINCE2 Agile fosters – and relies upon – an environment of:

• Transparency: ensuring that current project information is readily available to anyone in the organization with an interest in the work, including (but not limited to) the project delivery team, the project manager, the Project Board, and the intended business users.
• Collaboration: encouraging teams to work closely together towards a shared vision, to play an active role in project decisions, and to take responsibility for their committed outcomes.
• Communication: using high-value communication tools to provide transparency of information and to support ongoing collaboration.
• Exploration: empowering teams to investigate and trial potential solution options to confirm capabilities and to mitigate risks as early as possible. Note that this exploration work needs to be done with the Project Board’s understanding that:
  • not all of the options explored will be viable.
  • parts of the investigation and trialing may require substantial rework, as well as the possibility of discarded work.
  • the results of the exploration work may require the original product requirements to be revisited and, in some cases, modified to establish a more achievable solution.
• Self-organization: empowering the project delivery team to allocate their work in a way that best utilizes the skills and strengths of the team members.
• Accountability: creating a shared ownership by all project team members for the successful delivery of the project outcomes.

For teams currently using Agile methods, these are core principles that already guide how the team interacts with each other and with the business representatives. In PRINCE2 Agile, these core principles are expanded upon to include everybody involved in the project, from development team members to senior executives.

In addition to these key principles, there are several areas where PRINCE2 Agile leverages the strengths of both approaches to provide a more effective environment than either approach can deliver independently, specifically in:

• Business value generation
• Management of project variables
• Communication and reporting.

Each of these is explained in more detail below.

Business value generation

The relentless pursuit of high business-value outcomes is one of the strongest parallels between PRINCE2 and Agile methods, whether these are quantitative benefits (e.g. increased profits, reduced overhead costs) or qualitative benefits (e.g. more satisfied customers, greater employee retention).²⁵

In PRINCE2, each project must provide sufficient business-value justification in the project brief for the initial project funding and resources to be approved. The PID then needs to expand upon this by providing an achievable approach for delivering this business value. Without these two documents (and other supporting PRINCE2 artifacts), the Project Board cannot – and will not – grant approval for the project to proceed.

As the project progresses, the Project Board requires confirmation of ongoing business-value delivery at each project stage (in accordance with the benefits review plan) before granting approval for the next project stage to progress.

At the closure of the project, the business value that the project generated is formally documented as one of the key metrics of project success.

In Agile methods, business-value generation is the primary driver in determining which capabilities are at the top of the product backlog for the project delivery team to work on as their next priority. The main difference is that, for Agile methods, the product owner is generally the role that is responsible for deciding what capabilities will deliver the greatest business value as part of the planning for each delivery cycle – and then confirming whether the expected business value was achieved at each review session. In Agile methods, the level of involvement of more senior management in the decision-making process is generally left to the discretion of the product owner.

In PRINCE2 Agile, both of these approaches are combined, as shown in the “Requirements as Outcomes,” “Acceptance criteria,” and “Outputs” touchpoints in Figure 5. The business value that was originally identified in the PRINCE2 Agile project brief (and elaborated upon in the PRINCE2 Agile PID) creates the foundation for the project product definition, which feeds directly into the priority-driven product backlog that the project delivery team uses in their Agile work.

The key difference is that, in PRINCE2 Agile, there are several people involved in defining and confirming the delivered outputs:

• The executive, who is responsible for confirming the business case and ensuring that the project delivers its intended business value.
• The senior user(s), who have the ultimate decision-making authority on the capabilities of the solution, including identifying the minimum viable product (MVP).
• The product owner(s) and customer subject matter experts (CSMEs),²⁶ who
  • identify the detailed requirements, the corresponding acceptance criteria and the priorities for the project delivery team.
  • work hands-on with the project delivery team to identify the highest-priority work for each iteration/release.
  • review the outputs from each iteration/release and confirm whether they meet the acceptance criteria.
• The business ambassador(s),²⁷ who are optional staff to further support the project delivery team by providing subject-matter expertise as input, but not by making the final decision on priorities (as this is done by the product owners).
• The business analysts and requirements engineers, who are optional staff able to provide additional support to the project delivery team in researching, eliciting and communicating requirements, as well as creating required documentation.

This is a significant shift from Agile methods, where the product owner is often the single source of business requirements identification, prioritization, and confirmation, even for complex solutions across multiple business areas. In PRINCE2 Agile, there is significantly more involvement across the organization, including confirmation and support from executive management.

Management of project variables

Traditional project management approaches tend to focus on the management of Cost, Time and Scope as the three most important variables to control on a project.²⁸ When there is a change in these variables (for example, the customer wants the product delivered three weeks ahead of schedule), these traditional approaches also guide project managers on how to adjust the other two variables to keep the project on track. In this example, where Time is reduced, the project manager can negotiate for a corresponding reduction in the Scope of the work delivered and/or an increase in the Cost of delivery to supplement the available resources.

The original Project Management Triangle has been expanded over time to include Quality as a fourth variable, where a reduction in Time or Cost – or an increase in Scope – can be compensated for by reducing the amount of effort expended by the project team on testing the output or confirming its usability. (There are multiple reasons why sacrificing Quality is never the correct option, but that alone would completely fill another book!)

In PRINCE2 Agile, the management of project tolerances is expanded upon even further to include the management of:

• Benefits
• Scope
• Time
• Cost
• Quality
• Risk.

For each of these management tolerances, the Project Board determines what are the baseline acceptable levels for project success, and to what extent the project is permitted to vary from these tolerances before an exception needs to be raised for Project Board review.

The interesting thing is that, unlike traditional projects that would monitor all of these tolerances with equal scrutiny, PRINCE2 Agile projects take a different perspective, seeing:

• Time and Cost as fixed values that are not expected to vary as the project progresses (i.e. “Don’t Flex”).
• Scope and Quality as flexible values that are likely to vary as the project progresses (i.e. “Flex”).
• Benefits and Risk as possibly flexible values that could, at the discretion of the Project Board and the project manager, be adjusted as the project progresses (i.e. “Might Flex”).

The reasoning behind each of these is explained in the following sections.

Time and budget management as fixed values

In PRINCE2, the management of project timelines and budgets is generally achieved by identifying fixed values up front and establishing tolerances for reporting exceptions if the project work is substantially over or under these allocations.

In PRINCE2 Agile, it is expected that work will be undertaken by a known team (with an established overhead cost) and will be delivered in agreed timeframes (generally time-boxed intervals). This is why, in PRINCE2 Agile, the originally established project timelines and budgets are not expected to vary throughout the project delivery.

PRINCE2 Agile focuses more on managing the value of the outputs that the project delivery team produces within these fixed times and costs. This includes getting updates on which high-value capabilities the team has delivered in each agreed timeframe, how much business value these capabilities are generating, and how well these capabilities meet business expectations.²⁹

Scope and Quality as flexible values

On the other end of the spectrum are the two management variables in a PRINCE2 Agile project which are, by their very nature, intended to be flexible: Scope and Quality.

The “Business-value generation” section above described how the business requirements that are identified in the PRINCE2 Agile project brief (and elaborated upon in the PRINCE2 Agile PID) create the foundation for the product definition which feeds directly into the priority-driven product backlog that the project delivery team uses in their Agile work. Key to this is the priority-driven product backlog.

Agile methods understand that not every capability requested by the business is of an equal priority – and that there is greater value in focusing the project delivery team on producing the highest-priority capabilities. Although the product owner is encouraged to document the full scope of requirements for the solution (including any known high-, medium-, and low-priority capabilities), they are also expected to put these requirements in order of top-down priority, to keep the most valuable capabilities as the primary focus of the project delivery team in the limited time they have for each upcoming iteration/release.

As PRINCE2 Agile projects have fixed budgets and fixed timeframes (and, therefore, a limited number of iterations/releases where the project delivery team can produce outputs), it is expected that not every capability that is listed on the product backlog will be delivered by the team. In fact, one of the primary purposes of PRINCE2 Agile is to ensure that projects are continued (or stopped) on the basis of how much ongoing business value they are able to deliver to the organization. When a project has reached a point where the only work remaining is the delivery of the low business-value capabilities that remain on the backlog, the Project Board can – and should – consider closing the project and investing the available resources in activities that will generate more business value across the organization.

It is also expected that the priorities that were originally established at the start of the project will need to be adjusted over time to reflect the information that is obtained from ongoing development work, as well as changes that may occur in the organization and the market.

For all of these reasons, it is important in PRINCE2 Agile that the Scope of the project work be flexible to support these expected variations. Where possible, the business case should be: “defined in a flexible way to allow for what is being delivered (and its value) to change to a degree during the project.”³⁰ This allows minor changes to be accommodated in the project delivery using the selected Agile method, and only involves raising an exception to the Project Board where there are major changes that could affect the core business outcomes, require changes to the project business case, or stop the project altogether.

Similarly, the acceptance criteria (i.e. the quality criteria) that are established for the expected capabilities of the solution are intended to be a combination of those that are essential (i.e. the product cannot be released unless it meets these minimum standards) and those that are desirable (i.e. there is a preference for the product to meet the qualification, but the approval for product release will not be withheld if it does not). Although the project delivery team will endeavor to meet as many of the acceptance criteria (i.e. quality criteria) as possible within the allocated timeframe, their primary focus will be on achieving the essential criteria to ensure that they are producing potentially releasable outputs. Therefore the Quality of the project work needs to be flexible to allow for the possibility of some (or all) of the desirable acceptance criteria not being achieved, especially where the cost of meeting desirable criteria does not justify the amount of value that the organization will receive from this additional work.

In PRINCE2 Agile, the senior user(s) and the product owner identify the quality metrics (and tolerances) for measuring the success and acceptance of the delivered outputs (i.e. the definition of “done”). These metrics are described at a high level in the project product description; defined at a more detailed level in each of the epics, user stories, and technical stories in the product backlog; and used as the basis for ongoing testing to determine when each of the required capabilities has achieved the intended outcome.

Benefits and Risk as possibly flexible values

In PRINCE2 Agile, the level of flexibility that is acceptable for the Benefits that a project will deliver – and the amount of Risk that the Project Board will tolerate – both need to be determined on a case-by-case basis for each project.

For some PRINCE2 Agile projects, there will be strict senior management expectations of the Benefits that the project will deliver for the organization (and, therefore, a minimum viable business case that must be achieved to justify the investment in the project team) – for example, a product that is intended to meet a legislative requirement by a specific date. In these situations, the Project Board may have no flexibility in varying the stated benefits in the PID.

For other projects, there could be a significant amount of flexibility, particularly where the Benefits identified in the project brief are described at a high level (or with a range of options) and it is left to the discretion of the Project Board to determine whether they have been achieved. For example, a new issue logging system that is intended to provide better customer service may have a stated benefit of reducing the volume and frequency of support calls, but, until the system is released and its impact measured, the ability for it to achieve the intended benefit may need to be a preemptive judgment call by the Project Board.

Similarly, the amount of Risk that the Project Board is willing to accept could vary based on the nature of the project or the organizational culture. For a particularly risk-averse Project Board – or a particularly high-profile project – there may be no flexibility in the acceptable level of Risk, i.e. zero tolerance. This means that every potential risk to the project needs to be reported as an exception and reviewed.

Equally, there are projects where a reasonable amount of Risk is considered tolerable by the Project Board as long as it does not represent a significant risk to the core business outcomes. In these situations, the Project Board may be comfortable establishing risk tolerances for the project manager to report on only when they have been exceeded.

As PRINCE2 Agile can be applied to a wide variety of projects, it is impractical for there to be a fixed definition of acceptable Benefits or acceptable Risk for any one project. The level of flexibility that is appropriate for each project needs to be left to the discretion of the Project Board.

Communication and reporting

In PRINCE2 Agile, there is an unprecedented level of ongoing communication between the Project Board and the project delivery team with communication tools that provide all stakeholders with regular updates on project status, issues, and risks. This communication is generally available through information radiators that are maintained by the project delivery team and are visible in their work area (where stakeholders are colocated) or through electronic delivery channels (where stakeholders are remote).

To ensure the effective governance and management of project objectives, PRINCE2 Agile provides the Project Board with the same level of information on project status, issues, risks, and adherence to defined tolerances as PRINCE2, including highlight reports, checkpoint reports, stage reports, issue registers, risk registers, configuration item records, and exception reports. With PRINCE2 Agile, however, the communication tools described can supplement the standard reporting tools in PRINCE2 with the most current project information available. In some situations, these communication tools can also serve as a replacement for PRINCE2 reports and registers that the project manager had previously needed to maintain manually.

Where project issues and risks have been identified (through either the Agile communication tools, the PRINCE2 reporting tools, or a combination), these are addressed with the same level of scrutiny and follow-through in PRINCE2 Agile, although the mechanisms for achieving this may be different depending on how the project is structured.

For teams using Scrum, one approach is to have the project delivery team raise issues in the daily stand-up session (for the team manager/Scrummaster to record), to empower the team to try to resolve the issues and risks within the iteration, and, if they cannot be resolved in that timeframe, to escalate them to the project manager. Another approach is to have the project delivery team record all issues and risks in a centralized location (manual or electronic) throughout the iteration, give the team manager/Scrummaster the responsibility of initially vetting these, and then escalating the most critical ones – or those that cannot be immediately resolved by the project delivery team – for resolution by the project manager.

Whatever approach is utilized by the project team, the most important requirement is that there are appropriate channels for anyone on the project team to raise issues and identify risks, that they are recorded in an accessible location, and that there is an agreed procedure for escalating issues and risks that require input from the Project Board.

Further detail on how to select the most appropriate communication and reporting tools for your project is provided in the implementation guidelines that begin in Chapter 5: Moving from PRINCE2 to PRINCE2 Agile.

More information on PRINCE2 Agile is provided in the Bibliography.

______________________________________

²² This section provides an overview of how the two approaches work together with a focus on the resulting benefits that organizations can achieve. Much more extensive detail on implementing PRINCE2 Agile is provided in the AXELOS official PRINCE2 Agile guide.

²³ Foreword, PRINCE2 Agile, Keith Richards, AXELOS (2015), www.axelos.com/store/book/prince2-agile.

²⁴ Where the AXELOS official guide incorporates a range of Agile methods, including Scrum, Kanban, and Lean.

²⁵ AXELOS provides Management of Value (MoV) guidelines to distinguish between the perceived and actual benefits a solution provides for the organization. Section 9.4, PRINCE2 Agile, Keith Richards, AXELOS (2015), www.axelos.com/store/book/prince2-agile.

²⁶ On larger projects – or ones that cover a broad spectrum of capabilities – there may be a need to have multiple people serve as product owners and CSMEs.

²⁷ In DSDM, the business ambassador is a representative from the business area who provides input (clarification) to the project delivery team on requirements from the business perspective.

²⁸ This is also known as the “Project Management Triangle”: https://programsuccess.wordpress.com/2011/05/02/scope-time-and-cost-managing-the-triple-constraint.

²⁹ There is one caveat to consider in fixing the Cost variable on a PRINCE2 Agile project. The focus of this section has been on the fixed cost of the project delivery team, i.e. the human-resources cost for the project. As each project progresses, there is the possibility of other unexpected costs arising, for example unexpected software license fees or additional hardware that needs to be purchased. In these situations, the Project Board may want the project manager to keep team costs as a fixed value, but may establish tolerances for other project expenses.

³⁰ Section 4.1.3.4, PRINCE2 Agile, Keith Richards, AXELOS (2015), www.axelos.com/store/book/prince2-agile.