# 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: ### 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 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://framework.aic.io/agile-delivery-playbook.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.