CHAPTER 5: MOVING FROM PRINCE2 TO PRINCE2 AGILE

Expanding an existing PRINCE2 framework to the PRINCE2 Agile framework is likely to be the most common project scenario that readers will be facing. This chapter provides you with step-by-step advice on setting up and executing your PRINCE2 Agile project when your organization is in a position to leverage your existing PRINCE2 framework.

Which came first?

There is always a “chicken-and-egg” trade-off in project planning. Although the steps in this chapter are listed in sequential order, Steps 1 to 7 can (and should) be implemented in parallel based on emerging project information. For example, identifying the project team in Step 1 may need to be revisited after the release plan is defined in Step 4 to align proposed timelines with staff availability. In this case, part of the project team can be identified up front and other team members will need to be added as the project planning progresses (and, ideally, given the opportunity to provide ongoing input into the project planning).

Similarly, the project team’s ability to define the project controls and tolerances in Step 6 may depend upon the tools that are selected in Step 5, e.g. where the Project Board is comfortable increasing some of the tolerances because the communication tools selected in Step 5 give them greater ongoing access to current information on project status.

The objective is to use the information gathered in Steps 1 to 6 to build the PID in Step 7, either as

• a progressive activity (where project information is added to the PID as each key decision is made in Steps 1 to 6), or as
• a cumulative activity (where all of the project information is added to the PID once Steps 1 to 6 are completed to minimize the potential for rework if key decisions need to be adjusted in the ongoing project planning).

As you complete each step, it may be valuable to stop and revisit the decisions that were made in the previous steps to confirm whether they are still valid or need to be adjusted based on the subsequent decisions made by the team.

Step 1: Identify the right project team

Implementing a successful PRINCE2 Agile project requires a collaborative effort between the Project Board members, the project manager, and the project delivery team members. This includes key decisions that need to be made at the start of the project to establish the most effective team structure, delivery approach, communication tools, quality management strategy, risk management strategy, configuration management strategy, and methods for implementing project controls. It also includes the ongoing review and adjustment of the selected approaches to ensure their continued effectiveness.

Involving all members of the project team in these initial decisions creates an environment of high communication, transparency, empowerment, and ownership that carries forward throughout the project delivery, leveraging one of the most powerful advantages of the PRINCE2 Agile framework.

It is, therefore, important to identify the core Project Board, the project manager, and the project delivery team members as early as possible in the process to confirm their availability and to enlist their participation in these initial planning decisions.

For some projects, the Project Board members and project manager may have already been identified (or their roles in the organization may make them the definitive choices). Where these team members have already been decided, it is important to ensure that they are familiar with the structure and principles of the PRINCE2 Agile framework – and the distinction from their previous PRINCE2 work – before the project begins, and to assess their comfort level with this approach. For example, Project Board members who are looking for a “command-and-control” project governance structure may not be well suited to a PRINCE2 Agile delivery model (or may require the establishment of additional project controls to address their concerns).

Where there is discretion in choosing the Project Board members and the project manager, the preference would be to choose people who have the characteristics that make an effective PRINCE2 Agile project team member. (See “The fourth key to PRINCE2 Agile success: the right people” in Chapter 4: Five Keys to PRINCE2 Agile Success for further detail.)

Similarly, for the project delivery team, there may already be an established delivery team (or the skills that are required for project delivery may determine which people are selected). If there is discretion in choosing the project delivery team members, use the same approach described for selecting the Project Board members and project manager, with a preference for people who are familiar and comfortable with the PRINCE2 Agile framework – and, ideally, experienced in the Agile method that will be used for project delivery.³³

Once you have identified the core project team members, the next step is to identify the most effective team structure and roles – and to decide if there are additional people that need to be added to the project team. This includes:

• Determining if there are people needed on the Project Board in addition to the executive, senior user(s) and senior supplier(s) – and what their respective responsibilities will be.
• Determining who is needed to accurately represent the full requirements for the project deliverables in addition to the senior user, including customer subject matter expert(s), product owner(s), business ambassador(s), business analyst(s), and requirements engineers(s) – identifying their respective responsibilities and how they will interact with each other to confirm accuracy and consistency.
• Determining whether the project requires a separately assigned team manager or whether the project manager (or, for Scrum projects, the Scrummaster) will effectively function in this role.
• Determining the respective roles on the project delivery team, based on the Agile method selected (if it is known at this point in the process).

The outcome from these decisions may require the team to review and adjust the staff that were originally identified for the core project team, and to include these additional people in the ongoing planning discussions, where possible.

Step 2: Establish a shared vision

Once the project team is identified, it is important to ensure that everyone on the team has a shared vision of what the project is intended to deliver and how the PRINCE2 Agile principles and practices will be implemented to achieve these objectives.

If this is the first project that this team is delivering with PRINCE2 Agile (even if they have worked on PRINCE2 projects before), it is strongly recommended that all project participants – including the members of the Project Board, the project manager, and the project delivery team – get together for an interactive workshop to establish a shared understanding of PRINCE2 Agile and to set the focus for ongoing work. This can be done either as a separate session or as the first part of the project planning session(s).

Once the team has a common understanding of PRINCE2 Agile, the workshop session(s) should focus on establishing a shared vision of the key project information, including:

• The product vision and product roadmap.
• The expected benefits that the product will deliver.
• The overall project timeline, including the intended stages and releases, and any fixed dates that the project must adhere to, e.g. launch dates for marketing campaigns (with emphasis on the Agile method for delivering the highest-priority business capabilities within these timeframes).
• Any known issues and risks.
• The identified project roles.
• The preferred Agile method for product delivery, e.g. Scrum, Lean, Kanban, Scrumban (with a revisit of the project roles and team members as needed based on this decision).
• The team’s preferred methods for communication, status reporting, issue management, risk management, and configuration management.
• Other team and organizational culture dynamics, such as the extent to which the project delivery team will be empowered to make decisions and self-organize.

In this session, the project team will also need to determine how the work packages being delivered by the team will be managed and communicated with the project manager. There are several potential options, including:

• Assigning a dedicated team manager to manage the work packages and update the project manager on the progress of the team’s work.
• Having the project manager serve as the team manager to manage the work packages.
• If the team is using Scrum or Scrumban as their Agile method, having the Scrummaster serve as the team manager.

The session may also include the team establishing a shared understanding of the terminology that will be used and, if needed, creating a glossary of these terms.

The outcomes from the workshop session(s) will set the stage for the decisions that need to be made in the following steps and documented in the PID. Equally important, it will engage the entire project team and create a shared ownership of the project and the outcomes.

Step 3: Define the outcomes and outputs

The PRINCE2 Agile framework makes a distinction between the outcomes of a project, i.e. the measurable business value that the project generates,³⁴ and the outputs of a project, i.e. the specific project deliverables that are produced by the team to achieve these outcomes.

The intended project outcomes and benefits will have been described as a high-level business case in the project brief that was used for the initial project approval. As part of the project planning, these high-level requirements will need to be defined as more detailed business outcomes with the associated benefits and acceptance criteria identified.

The senior user generally provides this additional information, including identifying what is considered an MVP for release, distinguishing between the mandatory and the “nice-to-have” features and, where appropriate, identifying the range of tolerances in the acceptance criteria.³⁵ These product capabilities are documented in the product description (which may already exist at a program level) and in the project product description (which are the subset of product capabilities that this specific project is intended to deliver), with corresponding benefits identified in the benefits review plan.³⁶

Once the detailed business outcomes are identified, the next step is for the product owner(s) to transform these requirements into outputs (i.e. discrete bodies of work) that can be estimated and produced by the project delivery team. Additional support for this may be provided by the CSMEs, business ambassadors and other product specialists where needed (with the potential for further help from business analysts and requirements engineers).

In Agile methods, these outputs would generally be

• Defined as epics, user stories, and technical stories (for nonfunctional requirements) with acceptance criteria identified for each.
• Put into top-down priority order in a product backlog (and, if required, a release backlog).
• Reviewed in interactive sessions with the project delivery team in accordance with the selected Agile method (e.g. sprint planning sessions).
• Populated into the appropriate Agile tools for product delivery, e.g. sprint backlog, Kanban board.

Where possible, the PID should maintain high-level descriptions of product capabilities, referring out to the detail provided in these Agile tools for more specific information. Similarly, the benefits review plan should ideally focus on the outcomes, not the outputs. This allows for the outputs to be adjusted as the project progresses without compromising the agreed outcomes.

Step 4: Define the release plan

In Step 2: Establish a shared vision, it was identified that one of the key project areas for the team to discuss is the overall project timeline, including the intended stages and releases, and any fixed dates that the project must adhere to. In waterfall methods, the stages, releases and fixed dates that are identified at the beginning of a project are generally tied to specific capabilities (i.e. outputs) that are expected to be delivered within each timeframe. Establishing these upfront expectations for specific capabilities at specific times creates one of the biggest challenges (and, one could argue, weaknesses) of waterfall methods, as it minimizes the flexibility that the project team needs to adapt the outputs to support emergent information as the project progresses. It can also create significant overheads (and potential delays) for the project team where changes to outputs need to be treated as exceptions and formally approved before the project delivery team can progress.

PRINCE2 Agile provides a balanced view between giving executive management the timeframes that are needed for forward planning, and giving project teams the flexibility that is needed to continue progressing their work. This is primarily achieved by establishing stages and release dates that are tied to high level business outcomes – not specific functionality – and by allowing the PRINCE2 Agile process to guide the project work to achieve these outcomes.

PRINCE2 Agile also addresses the need for project adaptability by allowing the work that is undertaken to proceed using an Agile model, where time is generally managed as a fixed value with the variability being what is delivered in that timeframe.

For example, a project that is allocated for a duration of six months may be broken down into six time-boxed iterations of one month each. Within each iteration, the project delivery team strives to deliver as many of the highest-priority capabilities that the team can produce. At the end of the six months, the project delivery team will have delivered a cumulative set of highest-priority capabilities which, ideally, corresponds to the stages and the release plan that were identified at the start of the project (and updated as the project progressed).

This is an important distinction when it comes to distinguishing PRINCE2 Agile from other governance methods. Establishing stages, release plans, and other fixed dates at the start of a project should be viewed as an initial starting point (a baseline) that is likely to be adjusted as the project progresses.

The more the capabilities that will be delivered in these timelines can be defined at a high level, i.e. specific to outcomes, not outputs, the greater flexibility the project delivery team has to deliver the highest-priority business capabilities that will achieve these business outcomes within these timeframes (including allowing these capabilities to be released into live environments for ongoing measurement).

To achieve the PRINCE2 Agile planning model, the project team should group the intended capabilities of the solution into an initial time-boxed plan for intended stages and releases with the understanding that this is a baseline for moving the project forward and that the outcomes of ongoing project work will be used to confirm or adjust the release plan.

It is left to the discretion of each project team to determine the relationship between stages, releases, and iterations, e.g. to determine whether:

• there can be multiple releases within a stage
• releases should only occur once at the end of each stage
• capabilities can be released into the live environment as soon as they have successfully passed acceptance testing, without waiting for a defined project timeframe.³⁷

Once the high-level project plan is identified, the planning of the work for each iteration/release is undertaken by the project delivery team using the selected Agile method and guided by the top-down priorities identified by the product owner. At the end of the agreed time, the project delivery team will review the work that was produced with the product owner and work jointly to determine what should be included in the next iteration/release.

Depending on the level of uncertainty of the intended capabilities, the project team may also want to include a dedicated time-boxed interval for upfront investigation, experimentation, and prototyping to address potential risks. This allocated upfront time is commonly referred to as the Discovery Phase (e.g. Sprint Zero in the Scrum method). This phase can also be used for other work required to initiate the project, including purchasing equipment and configuring technology platforms.

As the project progresses, if there are substantial changes to the originally agreed release plan, the project manager is responsible for informing the Project Board of the exception for their guidance and approval to proceed.

Step 5: Choose your tools

As identified in Chapter 4: Five Keys to PRINCE2 Agile Success, one of the most critical factors in implementing PRINCE2 Agile successfully is establishing an environment of transparency, collaboration, and communication. This is particularly important for:

• communication within the project delivery team (including remote team members)
• communication between the project delivery team and the project manager and
• communication between the project delivery team and the Project Board (where the project manager may or may not need to be an intermediary, as described in the following section).

The Project Board needs to trust and empower the project delivery team to produce the required outputs, but they also need the opportunity to see the team’s progress and to receive advanced knowledge of potential issues and risks throughout the project timeline, if they choose. Equally, the project delivery team wants the ability to keep the project manager and Project Board informed without required substantial additional overheads or needing to shift focus from their primary work. There are several tools available in the PRINCE2 Agile framework that can address both of these requirements without requiring significant additional work from the project delivery team, including:

• Information radiators that are prominently displayed in work areas (or online) to show vision statements, daily progress, burndowns, planned work, and potential issues.
• Executive dashboards that provide a summary of key project information as “at-a-glance” management reports (and, with the right Agile tools, can be automatically updated when the team updates the backlogs).
• Iteration review sessions that provide the product owner and the project manager (and optionally the Project Board) with demonstrations of the capabilities produced in each iteration.
• Daily stand-up meetings which include a review of potential hurdles (i.e. issues) that can be recorded by team managers (or project managers if they are attending).

It is also possible for the team to create online tools for logging issues, risks, and configuration items in shared locations which are easily accessible by all project team members.

PRINCE2 Agile allows each project team to select the tools and communication processes that are best suited to the needs of the team members – and to adjust the tools as the project progresses to meet their ongoing needs. The following questions will help you to determine the right tools for your project:

• What tools are the project delivery team members planning to use in support of their own work (e.g. backlogs, Kanban boards)?
• Are these tools accessible to the project manager and the Project Board? If not, could they be made accessible with minimal additional effort by the project delivery team?
• Do these tools provide the project manager and Project Board with the ongoing status, quality, issue, risk, and configuration management information that they need? If not, what could be added to provide the additional detail without requiring a substantial amount of extra work for the project delivery team?
• How does the Project Board want to be notified of status information, issues, and risks? Are they happy to have this information available for their access (i.e. “pulling” the information) or would they prefer the information to be prepared and presented to them (i.e. “pushing” the information)? Note that, if the Project Board wants the information pushed to them, this would generally be the responsibility of the project manager, with support from the team manager as required.

The answers to these questions will also help the project manager determine what additional tools are needed to support PRINCE2 Agile reporting requirements.

It is worth noting that Project Board members are likely to request access to more information at the start of the project than they will continue to need as the project progresses (particularly if they are new to PRINCE2 Agile and hesitant about fully empowering the project delivery team). It is recommended that the project team members do not spend substantial time at the start of the project creating additional tools that may have limited value over the project timeline. It may be more beneficial for the project manager to temporarily provide the additional communication that the Project Board is requesting as a manual exercise (i.e. asking team members for updates) than to create an extensive range of registers, spreadsheets, etc. that may not be needed after the first few iterations/releases.

Step 6: Identify management strategies and project controls

The communication and reporting tools identified in the previous step provide the foundation for the project team to manage status, quality, configuration items, issues, and risks as part of ongoing project work. To ensure the effective governance of the project work in accordance with PRINCE2 requirements, the project also needs to establish formal strategies that identify how these tools (and other processes) will be used to manage these critical project areas, specifically:

• a communication management strategy
• a configuration management strategy
• a quality management strategy and
• a risk management strategy.

The team should try, wherever possible, to leverage the tools identified in Step 5 in these strategies to minimize the need for additional work, e.g. using information radiators as the primary issue communication tool within the project delivery team and escalating significant issues in a separate issues register.

The Project Board and project manager will also need to identify whether additional tools will be required to provide highlight reporting, checkpoint reporting, exception reporting, and end stage reporting – and to what extent the existing tools can satisfy these requirements.

In addition to establishing formal strategies to manage key project areas, the Project Board will also need to identify the acceptable tolerances for reporting on variations in Benefits, Scope, Time, Cost, Quality, and Risk as the project progresses. As described in Chapter 3: Overview of PRINCE2 Agile, PRINCE2 Agile focuses on having flexible Scope and Quality variables, possibly flexible Benefits and Risk variables, and fixed Time and Cost variables. Therefore it is reasonable to assume that Scope and Quality would have higher tolerances (i.e. allowing for more variation before reporting is required) and that Time and Cost would have much lower or zero tolerances (i.e. any variation on these would need to be reported to the Project Board). The Project Board’s familiarity in using PRINCE2 Agile can also influence their decision on how much variation they can allow for, with the potential for originally set tolerances to be increased as the project matures and the Project Board becomes more comfortable with this approach.

Step 7: Get approval for the baseline PID

At this point in the planning process, the project will have:

• an identified project team
• a shared vision of the outcomes and outputs that the project is expected to deliver
• the intended timelines for delivery
• an understanding of the tools that are available (or need to be developed) to monitor and manage ongoing project work and
• agreed project controls.

You are now in a position to create the baseline PID for Project Board review and approval for the project work to begin (or to refine the PID that you have been working on at each step).

In PRINCE2 Agile, the PID can be as formal or informal as the Project Board and project manager require. Where possible, the tools and processes identified in the previous steps should be used in lieu of including (and maintaining) substantial project management information within the PID itself. This will minimize the need for significant and frequent updates to the PID as the project progresses.

It is important to remember that the PID is being developed as a baseline document that is intended to be used as a starting point and adapted as the project progresses to reflect emergent information.

During this time, the project manager may also need to update the other supporting documentation for project approval, including the business case (as needed), the benefits review plan, and the project product description.

Step 8: Start the project work

When the Project Board has approved the PID, the project manager can develop the stage plan and work package(s) for the first stage of the project. This is where the project focus shifts from planning to execution, with the selected Agile method driving the production of outputs in accordance with the agreed plan.

For the project delivery team, this is the first iteration of Agile work based on the top-down priorities identified in the product backlog (and may include the Discovery Phase for initial investigation work, as determined in the release planning in Step 4 above). This would be the first of several iterations leading to one or more releases which fulfill the requirements of the first stage. (Further detail on how to use the selected Agile method for effective project delivery is provided in the Bibliography.)

It is important for the project manager to ensure that the stage plan for this work is written in a way that supports the use of Agile tools and agreed processes wherever possible, e.g. by having the project product description detail refer out to the product backlog instead of replicating its contents within the document (and needing to update it throughout the stage).

Similarly, the work packages for this stage need to be written in a way that allows the Agile method to manage ongoing work without creating a significant documentation overhead for the team.

The intent is to ensure that the primary focus of the project delivery team is on producing the required outputs, with governance and oversight occurring as a natural extension of the tools that the team is already using.

Step 9: Monitor the project work

As the project work progresses in each stage, the project delivery team uses the agreed Agile method to build the highest-priority capabilities within the allocated timeframes for the work packages identified in the release plan.³⁸

Within each stage, the project manager has ongoing responsibility for overseeing project progress, facilitating project work, getting required approvals, managing project tolerances, addressing exceptions, maintaining project records, and communicating with the Project Board through highlight reports and at other times as needed.

The team manager supports the project manager by managing the work packages being delivered by the team and updating the project manager on the progress of their work (where the team manager is a separate role).

Ongoing project status, issue, and risk information throughout the stage is made available to the project manager and Project Board using the communication tools agreed in Step 5.

At each review, the product owner(s), and other CSMEs, product specialists, etc., have the opportunity to confirm whether the outputs that the project delivery team has produced in that timeframe meet their expectations, and adjust ongoing work accordingly.

At each stage review, the senior user(s) have the opportunity to assess whether the capabilities that the project delivery team has produced across all of the iterations/releases in that stage are generating the anticipated level of business value and meeting their quality expectations in order to approve progressing to the next stage. Note that the involvement of the senior user can occur more frequently, e.g. at iteration reviews, as determined by the communication channels established for the project.

At each review point, it is important that the project team include retrospectives, reviewing both the effectiveness of the Agile method used and the PRINCE2 Agile governance structure. (These may be conducted as sprint reviews in Scrum or as service delivery/operations reviews in Kanban.) These review sessions should include comparisons of baseline versus actual measurements, and reviews of benefits achieved, issues encountered, and lessons learned. Where needed, the project team should endeavor to refine these approaches as the project progresses, instead of waiting for the stage end or project closure.

These review sessions can also include:

• Conducting a PRINCE2 Agile Health Check using the checklists that are provided in Appendix C of the AXELOS official guide.
• Using the Stoplight Reporting tool in Section 7.5 of the AXELOS official guide to determine whether the key PRINCE2 Agile principles are being adhered to – and to raise an exception if they are not.

Both of these tools are specifically designed for the monitoring and refinement of PRINCE2 Agile work.

Project work continues within the iterations/releases agreed for each approved stage until the project is closed, as described in the following step.

Step 10: Close the project

There will be a point where the project work will naturally (or unexpectedly) come to an end, because of one of the following:

• All of the intended outcomes have been achieved (including capabilities that have been released into a live environment where they can be measured).
• The project is not delivering the level of business value that was expected.
• The remaining work for the project does not deliver sufficient business value to justify the project continuing (particularly likely where Agile methods have focused on delivering the highest business-value outputs first).
• The project needs to be ended unexpectedly due to changes in the organization, budget availability, market conditions, etc. (even if the project work was delivering its intended outcomes).

For all of these scenarios, PRINCE2 Agile has a structured approach to project closure that should be followed, as detailed in Section 4.3 of the AXELOS official guide.

Importantly, the use of Agile methods, high communication, and transparency throughout project delivery means that project closure is generally more of a clean-up activity where the Project Board is already aware of:

• what outputs have (and have not) been produced
• whether the outputs produced meet the acceptance criteria (or allowed tolerances within these criteria)
• how well the outputs produced align with the expected benefits
• what issues and risks the project team encountered (and which of these have not yet been resolved)
• whether there were any unexpected project costs.

Ideally, this means that there should be no surprises at this point in the process. The primary focus for the project team will be to:

• Hold a project retrospective that focuses on reviewing the effectiveness of the PRINCE2 Agile framework, comparing baseline versus actual measurements, and documenting lessons learned for future project work (including decisions on the ongoing use of Agile methods).
• Finalize any remaining PRINCE2 Agile documentation (generally done by the project manager with support from the team manager and other team members as required).
• Implement any methods or tools that will be needed to measure the value of released capabilities (as described in the benefits review plan) after the project is closed.

This step should also include formal confirmation from the senior user(s) on the extent to which the requirements of the original business case have been met.

The documentation produced for project closure will serve as a formal record of what the project did (and did not) achieve and, equally important, as a learning tool for future PRINCE2 Agile teams.

______________________________________

³³ This may not be possible until the appropriate Agile method for that project is selected, in which case the selection of resources may need to be revisited.

³⁴ For further information, see Gabrielle Benefield’s guide to creating measurable outcomes at www.gabriellebenefield.com/mobius/how-to-measure-value.

³⁵ With the executive having the ultimate responsibility for ensuring that the intended benefits are being achieved.

³⁶ To support the adaptability and responsiveness of Agile methods, it is preferred that any capabilities identified by the senior user are described with flexibility to allow for the outputs to be adjusted as the project progresses without compromising the agreed outcomes.

³⁷ Figures 16.2, 16.3, and 16.4 in the AXELOS official PRINCE2 Agile guide provide further detail on the options and alternatives available for planning iterations, releases, and stages.

³⁸ The resources on the project delivery team should remain consistent throughout the project (i.e. across all stages) wherever possible to maximize the value of their Agile work and the accuracy of Agile metrics, e.g. velocity.