10.6 Managing Product Delivery and Its Agile Workshops

10.6 Managing Product Delivery and Its Agile Workshops

Quick summary: MP controls the link between the project manager and the delivery team through work packages. Its three activities are accept, execute and deliver a work package. Its agile workshops include the team planning workshop, where team OKRs are defined, and the team retrospective workshop, where the team shares the key accomplishments of its iteration.

Purpose

The purpose of managing product delivery is to control the link between the project manager and the delivery team, by placing formal requirements on accepting, executing and delivering project work.

MP runs in parallel with controlling a stage: CS at the managing level, MP at the delivering level. They are the two halves of the same conversation, and the work package is the interface between them.

The three activities

Accept a work package

The team and the project manager agree what will be produced. The team confirms it understands the products, the acceptance criteria, the Definition of Done, the tolerances and the reporting arrangements — and confirms it can deliver within them.

This is a genuine negotiation, not a hand-down. A team that accepts a work package it does not believe it can meet has already guaranteed an exception later.

Execute a work package

The team does the work — iteration by iteration:

• Pull ready items from the delivery backlog into the timebox
• Build and test within the iteration, not afterwards
• Hold planning, review and retrospective events
• Keep the team dashboard current so status is visible without being requested
• Raise impediments, risks and issues promptly
• Self-manage: decide how the work is done, sequence it, swarm on blockers

The project manager stays out of the how. Their involvement is limited to tolerances, impediments the team cannot remove, and interfaces with other teams.

Deliver a work package

The team confirms the products are complete — meeting their acceptance criteria and the Definition of Done — and hands them back for the project manager to receive in CS.

The work package as governance interface

A work package that specifies how the team should build something has crossed the line and removed the self-management the delivery approach depends on. Getting this boundary right is most of what makes a PRINCE2 Agile project work.

The team planning workshop

The team planning workshop plans the team's timebox. It:

• Reviews the prioritized items at the top of the delivery backlog
• Confirms items meet the Definition of Ready
• Sizes the work against the team's capacity, using velocity where history exists
• Agrees the goal for the timebox
• Defines the team's OKRs — the objectives and key results that express what the team is aiming to achieve and how it will know

The OKR point is directly examinable: team OKRs are defined in the team planning workshop, not in release planning, progress review or project closure.

The team retrospective workshop

The team retrospective workshop is where the team inspects how it worked and agrees improvements. It is also where the team shares the key accomplishments of its iteration — an explicitly named feature of this workshop.

Naming accomplishments is not decoration. A retrospective that only lists problems steadily erodes morale and psychological safety; one that starts from what went well establishes the safety needed for the harder conversation about what did not.

A typical structure: set the scene, review what happened, name the key accomplishments, identify what hindered the team, agree a small number of improvement actions the team itself owns, and check the previous iteration's actions were actually done.

Two conditions determine whether it is worth holding:

1. Psychological safety. Without it, nobody names the real problem.
2. Authority to act. Improvement actions the team cannot implement produce cynicism rather than improvement.

Distinguish the team retrospective workshop (team level, every iteration, this team's way of working) from the project retrospective (project level, at closure, lessons for the organization).

Agile tailoring of MP

• Checkpoint reports are often replaced entirely by a live team dashboard.
• The team decides its own iteration length, within the work package's constraints.
• Testing is inside the team, which is why tester is a named delivery role.
• The product owner accepts items continuously, rather than everything being accepted at work package hand-back.
• Tolerances are set on the work package, so the team knows exactly where its authority ends.