> For the complete documentation index, see [llms.txt](https://framework.aic.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://framework.aic.io/agile-delivery-playbook/foundations/agile-methods-we-use.md).

# Agile Methods We Use

### Overview

We use agile methods pragmatically. The chosen method must fit the work, team, customer environment and phase.

We commonly combine:

* Scrum-style sprint delivery
* Kanban-style flow management
* Lean thinking
* user-centred design
* service design
* technical spikes
* prototyping
* continuous delivery practices

### Scrum-Style Delivery

Scrum-style delivery works well when a team can plan work in short iterations.

Typical sprint length:

* 1 week for fast-moving discovery or alpha work
* 2 weeks for most product and software delivery
* 3 to 4 weeks only where customer governance or dependency cycles require it

Core sprint practices:

* sprint planning
* daily stand-up
* backlog refinement
* show and tell
* retrospective
* sprint review or governance review

### Kanban-Style Delivery

Kanban-style delivery works well where work arrives continuously or where support, live service improvement or operational tasks need steady flow.

Kanban practices include:

* visible board
* work in progress limits
* clear workflow states
* explicit policies
* cycle time measurement
* blocker management
* continuous prioritisation

### Lean Thinking

Lean thinking helps us remove waste and focus on value.

Examples of waste include:

* building features without validated need
* waiting for decisions
* duplicating evidence
* producing documentation nobody uses
* handoffs without ownership
* over-engineering too early
* fixing defects that could have been prevented

### User-Centred Design

User-centred design ensures services are shaped by evidence from users and their context.

This includes:

* user research
* journey mapping
* service blueprinting
* usability testing
* accessibility consideration
* content design
* assisted digital needs

### Technical Spikes

A technical spike is a time-boxed investigation used to reduce uncertainty.

Use a spike where the team needs to answer a question such as:

* Can this integration work?
* Is this technology suitable?
* What is the data quality like?
* What are the security constraints?
* Can the system meet performance requirements?
* What is the simplest viable architecture?

A spike must have:

* a clear question
* a timebox
* expected evidence
* decision criteria
* documented outcome

### Prototyping

Prototypes are used to learn. They are not automatically production assets.

Prototype types include:

* paper prototype
* clickable prototype
* content prototype
* data prototype
* technical proof of concept
* integration prototype
* service simulation

Prototype rules:

* make the learning goal explicit
* keep the prototype as simple as possible
* do not confuse prototype code with production code
* record what was learned
* decide whether to continue, change direction or stop

### Method Selection

Select the method based on:

* uncertainty level
* delivery phase
* team size
* customer governance needs
* supplier involvement
* technical complexity
* release frequency
* operational risk
* assurance requirements

### Default Method Pattern

Our default pattern is:

* Discovery: user-centred research, service design, technical discovery and short Kanban flow
* Alpha: prototypes, technical spikes, user testing and short sprint cycles
* Beta: Scrum-style product build with release planning and assurance gates
* Live: Kanban-style continuous improvement with roadmap-based planning
* Retirement: controlled transition plan with governance checkpoints