7.2 The Organization Practice in an Agile Context

7.2 The Organization Practice in an Agile Context

Quick summary: The organization practice defines the project's responsibilities. It establishes the three project interests, the four levels of management, and — in an agile context — how PRINCE2 roles and agile delivery roles fit together without duplicating authority.

Purpose

The organization practice defines and establishes the project's structure of accountability and responsibilities: who is accountable for what, who reports to whom, and how the roles relate to one another. It is the practice that gives the define roles, responsibilities and relationships principle its machinery.

The three project interests

Every project must represent three interests, and the project board exists to hold them:

Adding agile roles does not remove any of these. A team-level product owner is not a substitute for project-level user representation, and a delivery team is not a substitute for a senior supplier. If a project has a product owner and nobody holding the user interest at the directing level, that interest is being represented by someone whose accountability is backlog ordering — which is not the same thing as accountability for benefit realization.

Where the chief product owner fits. The eleven roles named in the Version 2 syllabus include the chief product owner rather than listing a senior user separately. On a PRINCE2 Agile project the chief product owner is the role that carries the user and product interest at the directing level, owning the project backlog and working to the benefit objectives the business case sets out. Where an organization also appoints a senior user in the PRINCE2 Project Management sense, the two work as a pair — the senior user accountable for specifying and realizing benefits, the chief product owner translating those objectives into project-level backlog priority. What must never happen is for neither to exist, leaving the user interest to a team-level product owner.

The four levels of management

The directing level delegates day-to-day management to the managing level — that delegation happens in the directing a project process, and it is what makes manage by exception operable.

Reporting relationships

Two relationships are examinable and frequently confused:

• Project support reports directly to the project manager. Project support is a project management function — administration, tooling, configuration and information management — and it sits under the project manager.
• Delivery team members do not report to the project manager. They work within a self-managing delivery team. The project manager agrees work packages with the team, sets tolerances, and then stays out of the how. The team coach serves the team rather than managing it, and the product owner owns priority rather than people.

That distinction is exactly what makes agile delivery work inside PRINCE2 governance: the project manager manages work packages and tolerances, not individuals' daily tasks.

Integrating agile and PRINCE2 roles

The practical work of this practice on a PRINCE2 Agile project is mapping. Common integrations:

The mapping must be agreed and recorded at initiation. The failure mode is ambiguity: a senior user and a product owner both believing they set priority, or a project manager and a team coach both believing they resolve impediments. Chapter 9 covers all eleven roles the syllabus names.

Artifacts and techniques

Artifacts in this practice include role descriptions, the project's organization structure, the communication management approach, and — in an agile context — the team dashboard and the working agreements a team produces in its kickoff workshop.

Techniques the syllabus associates with organizing an agile project:

• Personas — defining and prioritizing user groups, so that "the user" is a specific, understood set of people rather than an abstraction. The project canvas workshop is where this typically happens.
• Team skill matrix — a grid of people against skills that exposes single points of failure and drives cross-skilling.
• Delegation matrix — an explicit statement of which decisions the team takes alone, which after consultation, and which are escalated.
• Delegation poker — a collaborative technique for agreeing those delegation levels, which surfaces mismatches between the autonomy a manager thinks they granted and the autonomy the team believes it has.
• Servant leadership — putting team members' needs above your own; the leadership style appropriate to coaching roles and to the project manager's relationship with delivery teams.
• Working agreements and team norms — how the team agrees to operate, established in the kickoff workshop.

Tailoring the organization practice

• Small projects combine roles. The executive may also be the senior user; the project manager may also be the team manager. What cannot be combined is anything that removes a project interest or creates a conflict — the executive should not also be the senior supplier, because value for money and supplier margin pull in opposite directions.
• Multi-team projects add a chief product owner and require explicit cross-team decision rights.
• Commercial projects need the customer/supplier boundary made explicit in role descriptions, because accountability crosses an organizational boundary.