Agile Delivery Playbook

Purpose

This GitBook explains how we deliver work using an agile approach. It is separate from the company operating manual. The operating manual explains how the company is structured, governed and commercially controlled. This playbook explains how delivery teams actually run work from early discovery through to live service operation and eventual retirement.

This playbook is designed for customers, internal teams, delivery partners and subcontractors. It gives people a detailed view of how we plan, research, build, test, assure, release and improve services.

Source Basis

This playbook is adapted from the GOV.UK Service Manual guidance on agile delivery, including the sections on agile principles, agile methods, planning, roadmaps, governance, measuring progress, discovery, alpha, beta, live and retiring services.

GOV.UK source: https://www.gov.uk/service-manual/agile-delivery

How This Playbook Is Tailored

The GOV.UK material explains good practice for agile public service delivery. This playbook translates those practices into our delivery model. Our model adds the controls needed for professional services, enterprise delivery, high-assurance environments and statement-of-work-led engagements.

Our agile delivery model is therefore:

• user-centred

• iterative

• evidence-led

• commercially controlled

• security-aware

• IP-conscious

• supplier-ready

• assurance-friendly

• suitable for complex customer environments

Our Delivery Lifecycle

We use five delivery phases:

1. Discovery

2. Alpha

3. Beta

4. Live

5. Retirement

Not every engagement uses every phase in full. The phase model is a decision framework. It helps us understand what evidence is needed, what work should happen next and what level of commitment is appropriate.

How Agile Fits With Commercial Control

Agile delivery does not remove commercial discipline.

The Statement of Work defines the authorised commercial boundary. The backlog defines the delivery detail inside that boundary. Governance reviews make progress visible. Change control manages material change. Acceptance criteria define completion. IP controls ensure reusable assets are protected and customer-specific outputs are handled correctly.

What Good Looks Like

A well-run agile engagement has:

• a clear problem statement

• visible user needs

• agreed outcomes

• a prioritised backlog

• a roadmap that evolves as we learn

• regular delivery rhythm

• clear governance cadence

• active risk and issue management

• evidence-based decisions

• strong technical and security assurance

• measurable progress

• clear acceptance criteria

• controlled use of reusable IP

• documented learning and improvement

How to Use This GitBook

Use this playbook when:

• explaining our agile approach to a customer

• preparing a proposal or Statement of Work

• planning a discovery, alpha, beta or live phase

• onboarding a delivery team

• onboarding a subcontractor

• setting up governance

• defining acceptance criteria

• deciding whether to proceed to the next phase

• reviewing delivery health

• preparing assurance evidence