PRINCE2 Agile

History & Constraint


The first edition of PRINCE2 Agile was published by AXELOS on Jun 2015.

No plans are announced about a second edition, and because of the heavy investment in certification and training programs, it’s likely not to have a new edition for years.

PRINCE2 Agile is a new concept form AXELOS (the owner of PRINCE2), which is a tailored from of PRINCE2, suitable for Agile environments such as Scrum.

PRINCE2 Agile does not contain an Agile delivery method, and supports the existing ones instead.

Process Model



Legend:

Abbreviation PRINCE2 process Key Agile artefacts and events
DP Directing a Project Process
SU Starting up a Project Process Vision, Product Roadmap
IP Initiating a Project Process Product Backlog
CS Controlling a Stage Release(s), release backlog, release retrospective
MP Managing Product Delivery Sprint(s), Sprint Backlog, Sprint Review and Retrospective
SB Managing a Stage Boundary Process As for CS
XSB Managing a Stage Boundary Process (when an exception has occurred) As for CS
CP Closing a Project Process Project retrospective

Stages are still set based on the management needs of the project, rather than turning into iterations. Each Stage contains one or more “release”, and each “release” contains one or more “iterations”. Iterations are usually called “timeboxes” in PRINCE2 Agile.

Plans are created as usual, with the default responsibilities. Then Work Packages would be the basis for creating the release plans and iteration plans (Team Plans), while their high-level aspects have been defined in the Project Plan and Stage Plans from the beginning.

Delivery team members are empowered to decide on minor changes, as long as they do not affect the Category:Management Products directly. Otherwise, the usual change control process would be run, with escalations based on tolerances. Therefore, a limited level of adaptation exists in the delivery layer, and higher-level adaptation would happen in the higher layers, and specially in the Managing a Stage Boundary Process.

The suggested approach in PRINCE2 Agile is to have fixed time and cost for the project, similar to DSDM Atern. Consequently, the contract would be fixed-price. When the customer asks for a new feature, they have to swap it for one (or more) of the initial features mentioned in the contract, with the same size.

PRINCE2 Agile defines Agile as a set of behaviors and practices rather than the use of an adaptive lifecycle, and consequently, the manual is focused on providing generic guidelines on common behaviors in Agile environments rather than providing a complete integration between the PRINCE2 process model and Agile lifecycle.

Tailoring done on PRINCE2


Principles

Themes

Processes

  • Continued Business Justification Principle
  • Learn from Experience Principle
  • Defined Roles and Responsibilities Principle
  • Manage by Stages Principle
  • Manage by Exception Principle
  • Focus on Products Principle
  • Tailor to Suit the Project Environment Principle
  • Business Case Theme
  • Organization Theme
  • Quality Theme
  • Plans Theme
  • Risk Theme
  • Change Theme
  • Progress Theme
  • Starting up a Project
  • Initiating a Project
  • Directing a Project
  • Controlling a Stage
  • Managing Product Delivery
  • Managing a Stage Boundary
  • Closing a Project

Note: Principles are not supposed to be tailored in PRINCE2. The above pages only explain how each principle will be interpreted in Agile environments.

PRINCE2 Agile doesn’t add, remove, merge, or split any of the original processes.

Management Products

PRINCE2 Agile mentions some additional Management Products such as User Stories, but does not make it official, and for example, does not provide Product Descriptions for them. So, in this part, only the original Management Products and the way they are tailored are discussed.

Baselines
Records
Reports
1 Benefits Review Plan

2 Business Case

4 Communication Management Strategy

6 Configuration Management Strategy

16 Plan (including Project Plan, Stage Plan, and Team Plan)

17 Product Description

19 Project Brief

20 Project Initiation Documentation, aka PID

21 Project Product Description

22 Quality Management Strategy

24 Risk Management Strategy

26 Work Package

5 Configuration Item Record

7 Daily Log

12 Issue Register

14 Lessons Log

23 Quality Register

25 Risk Register

3 Checkpoint Report

8 End Project Report

9 End Stage Report

10 Exception Report

11 Highlight Report

13 Issue Report

15 Lessons Report

18 Product Status Account

Changes in the baselines products are managed formally, while other changes (e.g. on user stories) are managed informally by the delivery level. More on this on the Change Theme.

Roles and Responsibilities

All default PRINCE2 roles still exist in PRINCE2 Agile, and their responsibilities have not changed much, except for the recommendation to empower the delivery team.

While PRINCE2 Agile frequently mentions the Scrum roles such as Product Owner and Scrum Master, as if they are a fixed part of the team, still does not considers them as default roles, and uses the more generic roles mentioned below. More on this in the Organization Theme’s page.

Original Roles Project Board The Project Board should understand Agile, and especially the concept of having a dynamic scope and the way Requirements are managed.

They should be willing to delegate enough power to the lower levels of project organization through the Manage by Exception Principle.

Executive They should understand Overview, and especially the concept of having a dynamic scope and the way Requirements are managed.

They should be willing to delegate enough power to the lower levels of project organization through the Manage by Exception Principle.

Senior Supplier There’s no specific considerations for this role.
Senior User In case of Scrum, the best choice for Senior User is one, or a few of the Product Owners working in the delivery level, or a representative of them.

Note: based on the Scrum Guide, each project can have only one Product Owner. However, there can be a group of people responsible for product ownership and one of them will be called the Product Owner. In this case, the same person, or other representatives from the committee can be Senior Users.

Project Manager They should fully understand “Agile”.

They should ensure that Agile is incorporated properly. In case of Scrum, the Project Manager should get help from the Scrum Masters to manage the process.

They should ensure that team members are involved in project planning.

They should help create a no-blame environment.

They should understand that more authority should be delegated to the delivery level, compared to predictive projects.

Team Manager The Team Managers should ensure that they are not blocking the self-organization of the delivery teams.
Project Assurance Besides its usual role, the Project Assurance would be responsible for assuring the Agility of the project, especially based on the adopted PRINCE2 Agile version in the organization, and other related guidelines.
Change Authority This role would be focused on changes to the baseline, withing its tolerance. The minor changes that do not directly affect the baselines would be managed by the team members.
Project Support Project Support can be responsible for coaching the management team on understanding Overview, and the right way of interacting with the team.
Additional Roles Customer Subject Matter Expert The Customer Subject Matter Expert is assigned to the delivery team to define detailed requirements, answer questions about them, and prioritize them.

The responsibilities are similar to that of a product owner in Scrum.

Customer Representative Customer Representatives are those from the customer side assigned to provide information and direction to the Senior User(s) or the delivery teams.
Supplier Subject Matter Expert A Supplier Subject Matter Expert is a technical person from the supplier side, helping the delivery team (supplier)!
Supplier Representative Supplier Representatives consult the delivery team or the Senior User(s) on the technical aspects.

providing technical guidance

communicating technical standards

highlighting any areas that the project may impact from a technical perspective

Delivery Team Quality Assurance Quality Assurance is recommended to be external to the project in PRINCE2. PRINCE2 Agile adds a new QA role besides the original one, which sits inside the project organization, in the delivery layer.

There can be one QA role in the delivery level for both the customer and supplier interests, or have two separate persons/groups for the two sides.

They have the usual QA responsibilities, but in a more detailed level; e.g. focused on the adherence of completed items to the Definition of Done.

The original PRINCE2 responsibilities tables have not adjusted to include the new roles, or reflect any tailoring. The new roles are not even mentioned much through the manual and it’s not clear how they are supposed to be used, and how they are connected to the rest of the methodology.

Extra Concepts


  • The Focus Areas
    • The Agilometer
    • Requirements
      • User Stories
    • Rich Communication
      • Information Radiators
      • Daily Standups
      • Review Meetings
      • Retrospective Meetings
    • Frequent Releases
    • Contracts
  • Behaviors
  • Health Check
  • Cynefin
  • Targets
  • Guidance Points
  • Definition of Done
%d 블로거가 이것을 좋아합니다: