> 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/delivery-system/working-environment-and-cadence.md).

# Working Environment and Cadence

### Overview

The working environment should make collaboration, visibility and decision-making easy. Agile delivery works best when teams can communicate frequently, inspect progress and resolve blockers quickly.

### Delivery Workspace

Every engagement should have an agreed delivery workspace that includes:

* documentation location
* backlog tool
* roadmap location
* RAID log
* decision log
* change log
* reporting location
* communication channels
* repository links
* design or research workspace
* assurance evidence location

### Communication Channels

Teams should agree which channel is used for which purpose.

Example:

| Channel             | Purpose                               | Record Required    |
| ------------------- | ------------------------------------- | ------------------ |
| Email               | formal approvals and external records | yes                |
| Chat                | day-to-day coordination               | only if material   |
| Backlog tool        | work tracking                         | yes                |
| Document repository | controlled documents and evidence     | yes                |
| Video call          | ceremonies and workshops              | notes where needed |

### Delivery Cadence

A standard cadence may include:

* daily stand-up
* weekly customer checkpoint
* weekly internal delivery review
* weekly risk and issue review
* fortnightly show and tell
* fortnightly retrospective
* monthly steering review
* milestone acceptance review

### Daily Stand-Up

Purpose:

* align the team
* expose blockers
* coordinate work
* maintain momentum

Questions:

* What changed since the last stand-up?
* What is being worked on now?
* What is blocked?
* What decision or support is needed?

### Sprint Planning

Purpose:

* confirm sprint objective
* select work from backlog
* confirm capacity
* identify dependencies
* agree acceptance approach

Outputs:

* sprint goal
* sprint backlog
* owners
* dependencies
* risks
* planned review point

### Backlog Refinement

Purpose:

* improve future work items
* split large items
* clarify acceptance criteria
* identify dependencies
* prepare for future planning

Good refinement produces backlog items that are small, clear, valuable and testable.

### Show and Tell

Purpose:

* demonstrate progress
* gather feedback
* keep stakeholders engaged
* reduce surprise
* support evidence-based decisions

Show and tell should demonstrate real work, not only slides. It may include prototypes, research findings, service journeys, test results, technical evidence, data insights or working software.

### Retrospective

Purpose:

* improve how the team works
* identify friction
* agree practical improvements
* track whether previous improvements worked

Retrospective outputs should be specific actions with owners and dates.

### Governance Review

Purpose:

* review progress against plan
* review risks and issues
* review milestone status
* confirm decisions
* manage commercial or scope matters
* escalate blockers

### Meeting Rules

* Every recurring meeting must have a purpose.
* Every decision should be recorded.
* Every action should have an owner and date.
* Meetings that do not add value should be changed or removed.