# Core Agile Principles ### Overview Our agile principles are aligned to the GOV.UK Service Manual. They are expressed here as practical behaviours for our teams. ### 1. Focus on User Needs We start by understanding who the users are, what they need to achieve and what prevents them from succeeding today. User needs may include: * end-user needs * customer operational needs * administrator needs * support team needs * security and compliance needs * reporting and audit needs * accessibility needs * integration and data needs A user need is not the same as a feature request. A feature is one possible response to a need. Agile delivery keeps the team focused on the underlying need so that the right solution can emerge. ### 2. Deliver Iteratively We break work into manageable increments. Each increment should produce learning, value, evidence or risk reduction. Iteration allows the team to: * validate direction early * expose problems before they become expensive * adjust priorities * reduce delivery risk * show progress * improve quality continuously ### 3. Keep Improving the Service The service is never considered complete simply because a phase ends. Every phase creates evidence that should improve the next phase. Improvement may include: * simplifying user journeys * reducing support burden * improving performance * improving accessibility * reducing technical debt * improving security posture * improving monitoring * improving documentation * improving operational readiness ### 4. Keep Improving the Team Agile teams improve how they work, not just what they deliver. Teams should regularly inspect: * communication quality * decision speed * meeting effectiveness * backlog quality * handoffs * blockers * technical practices * quality practices * customer engagement * supplier coordination ### 5. Fail Fast and Learn Quickly We deliberately test risky assumptions early. The aim is not to fail carelessly. The aim is to avoid large, late and expensive failure. A fast failure is useful where it: * invalidates a weak assumption * prevents wasted build effort * clarifies a better path * produces evidence * reduces uncertainty ### 6. Keep Planning Agile planning is continuous. Plans are not abandoned; they are updated as the team learns. We maintain planning at multiple levels: * outcome plan * phase plan * roadmap * release plan * sprint or iteration plan * daily coordination ### 7. Make Work Visible Visibility is a control. The team should be able to show: * what is planned * what is in progress * what is complete * what is blocked * what is at risk * what decisions are needed * what has changed * what evidence exists ### 8. Build Quality In Quality is part of the delivery process. It is not a final inspection activity. Quality is built through: * clear acceptance criteria * good user stories * code review * testing * security review * architecture decisions * accessibility checks * performance checks * documentation * governance reviews ### 9. Protect Reusable IP We use reusable IP to accelerate delivery, but we do not lose control of it. Reusable templates, components, playbooks, code, patterns, checklists and methods must be used in line with the contract and IP rules. ### 10. Produce Evidence as We Deliver Evidence should be created naturally as work progresses. We avoid trying to reconstruct evidence at the end. Evidence may include: * research notes * decisions * prototype findings * test results * accessibility checks * security reviews * acceptance records * deployment records * metrics * retrospective actions --- # 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/foundations/core-agile-principles.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.