# Agile delivery, honestly

*What the ceremonies are for, why most agile is waterfall in two week chunks, and when not to use it.*

## Production summary

- Modules to record: 2
- Total script: 1054 words, about 7 minutes of finished audio
- Voices: Amara (host) and Nadia (practice educator)
- Level: Team members, leads and managers new to agile

## Accreditation wording that must appear in the description

- **The CPD Certification Service** (planned): Application scheduled.

> Do not upgrade any of these words in a description or a thumbnail. Aligned is not accredited, and planned is not approved.


---

## What each ceremony is for, and how to spot theatre

**Runtime** about 4 minutes. **Words** 557. **Starts at** 00:00 in the full course recording.

### Learning outcomes to state on camera

- State the purpose of each ceremony and diagnose failure
- Choose between Scrum and Kanban
- Identify agile theatre
- Say when a predictive approach fits better

### Script


`[CUE 1]` *Each ceremony with the single question it answers written beneath it.*

**AMARA**  [00:00]
We have stand ups, sprints and a board, and it feels like nothing has changed except we have more meetings.

**NADIA**  [00:08]
Then you probably have agile theatre, and it is extremely common. The test I would apply is one question.

**AMARA**  [00:15]
Which is?

**NADIA**  [00:16]
What have you decided not to build, as a result of something you learned?

**AMARA**  [00:22]
Nothing. We are building the list that was signed off last year.


`[CUE 2]` *A stand up where everyone faces one person, marked as a status report.*

**NADIA**  [00:26]
Then the feedback loop is decorative. You have the overhead of agile and the constraints of waterfall, which is the worst available combination, and no amount of extra ceremony will fix it.

**AMARA**  [00:39]
Let us take them one at a time. What is a stand up actually for?

**NADIA**  [00:45]
One question. Has anything changed since yesterday that affects what we do today. It is a planning event for the team.

**AMARA**  [00:54]
Ours is a status report.

**NADIA**  [00:56]
Then it is dead, and there is a tell. Watch where people look. If everyone speaks to the same person rather than to each other, they are reporting upwards and the event has stopped doing its job.


`[CUE 3]` *Scrum sprint batches beside Kanban continuous flow with WIP limits.*

**AMARA**  [01:10]
Sprint planning?

**NADIA**  [01:11]
What can we commit to, and do we understand it well enough to start. And here is the test: can the team say no?

**AMARA**  [01:21]
Not really.

**NADIA**  [01:22]
Then it is not planning, it is allocation with a ceremony wrapped round it. A commitment somebody cannot decline is not a commitment.

**AMARA**  [01:31]
Review?


`[CUE 4]` *Support work breaking a sprint commitment repeatedly.*

**NADIA**  [01:31]
Is this what was needed. Which means real users in the room. A review with no users is a demo to your own department, and it will always go well, which is why it is useless.

**AMARA**  [01:46]
Retrospective. Ours is quite miserable.

**NADIA**  [01:48]
A retrospective that produces no change is a support group. And after three of those, people stop bringing anything real, because they have learned that raising something costs them and changes nothing.

**AMARA**  [02:00]
How do I fix that?

**NADIA**  [02:02]
One change, owned by a named person, revisited at the next retrospective. One. Teams try to fix five things, achieve none, and conclude retrospectives do not work.


`[CUE 5]` *Agile theatre checklist: signed off scope, fixed date, no removals, unowned actions.*

**AMARA**  [02:13]
Scrum or Kanban? Nobody has ever explained the difference usefully.

**NADIA**  [02:17]
Scrum is fixed length sprints with committed scope. It suits work you can plan in batches, and it protects a team from interruption.

**AMARA**  [02:26]
And Kanban?

**NADIA**  [02:27]
Continuous flow with work in progress limits and no sprints. It suits work that arrives unpredictably. Support, operations, maintenance.

**AMARA**  [02:35]
We do support work in sprints.


`[CUE 6]` *A decision matrix for predictive versus iterative by uncertainty and cost of change.*

**NADIA**  [02:37]
Then your sprint commitment breaks every time an incident arrives, the team learns that commitments are meaningless, and everybody maintains the fiction politely. That is one of the commonest mistakes there is, and Kanban would fix it in a fortnight.

**AMARA**  [02:53]
Last question, and it feels heretical. Is agile always right?

**NADIA**  [02:57]
No, and being able to say that is a sign of maturity rather than disloyalty. Agile suits work where the requirements are genuinely uncertain and feedback changes what you build.

**AMARA**  [03:09]
And when is it not?

**NADIA**  [03:11]
Where the requirement is fixed and well understood. Where regulation demands specification and approval before build. Where integration has to happen as a single event, like a physical migration. Or where the cost of late change is genuinely enormous.

**AMARA**  [03:27]
So choose.

**NADIA**  [03:28]
Choose deliberately and say why. Most real programmes are a mix anyway: predictive at the boundaries, iterative in the middle. The problem is never the method, it is adopting one because the organisation currently believes in it.

### Sources for the on screen credit

- The Scrum Guide, Scrum.org
- Kanban and flow principles, Lean Kanban literature
- Agile delivery guidance, Government Digital Service

---

## Stories, estimation and making work visible

**Runtime** about 3 minutes. **Words** 497. **Starts at** 03:42 in the full course recording.

### Learning outcomes to state on camera

- Write a user story that is about a user rather than a task in costume
- Split work small enough to flow without losing its meaning
- Use estimation for conversation and forecasting, not for pressure
- Read a board and see where work is actually stuck

### Script


`[CUE 1]` *A task in story costume, unmasked to a plain task.*

**AMARA**  [03:42]
Our stories all read: as a developer I want to refactor the module so that the module is refactored.

**NADIA**  [03:50]
Which is a task in a costume, and everybody can see the costume. The story format exists for one purpose: keeping the user in the sentence.

**AMARA**  [04:00]
So what do I do with technical work?

**NADIA**  [04:04]
Call it a task and let it be one. Forcing it into the format teaches the whole team that the format is a joke, and then the real stories get written as jokes too.


`[CUE 2]` *The two story tests: a nameable person, a recognisable so that.*

**AMARA**  [04:17]
What makes a story real?

**NADIA**  [04:19]
Two tests. Can you name the person, specifically, not users in general. And would that person recognise the so that clause as something they actually want?

**AMARA**  [04:30]
Why does the so that clause matter so much?

**NADIA**  [04:33]
Because it is the outcome the work will be judged against. Lose it and you are back to shipping output and hoping.


`[CUE 3]` *Ninety per cent done sitting for weeks, beside small items finishing.*

**AMARA**  [04:42]
Acceptance criteria?

**NADIA**  [04:43]
The story's contract. Testable statements that would convince a sceptic it is done. A user can complete the referral in under two minutes without training is a criterion. It should work properly is a wish.

**AMARA**  [04:57]
Our items sit at ninety per cent done for weeks.

**NADIA**  [05:01]
Ninety per cent done is not a measurement, it is a mood. The only states that mean anything are done and not done, which is the entire argument for small items.


`[CUE 4]` *Outcome slice through all layers, against a completed layer nobody can use.*

**AMARA**  [05:13]
How do I split big things without losing the point of them?

**NADIA**  [05:18]
By outcome slice, never by architectural layer. A thin slice that lets one real user complete one real journey beats a finished database layer nobody can touch, because the slice ships and teaches you something.

**AMARA**  [05:32]
And if something will not split below two weeks?

**NADIA**  [05:36]
That is almost always a sign it is not understood yet. The split to make is a discovery task: spend two days finding out what it actually is.


`[CUE 5]` *An estimate gap of two versus thirteen surfacing a misunderstanding.*

**AMARA**  [05:47]
Estimation. Our velocity is now a KPI.

**NADIA**  [05:50]
Then your velocity is now fiction. The moment the number becomes a target, it inflates, and once it inflates it forecasts nothing. That is not a moral failing, it is what happens to every measure that becomes a target.

**AMARA**  [06:05]
So what are estimates for?

**NADIA**  [06:07]
Two things. Forecasting roughly when things land. And forcing the conversation, which is worth more than the number.


`[CUE 6]` *Ten items in progress across four people, then WIP limited and flowing.*

**AMARA**  [06:14]
The conversation?

**NADIA**  [06:15]
One person says two, another says thirteen. The gap is the finding. They are imagining different work, and discovering that in planning costs an hour. Discovering it in production costs a month.

**AMARA**  [06:28]
Last one. Our board has ten things in progress for four people.

**NADIA**  [06:33]
Then everything is being juggled and nothing is finishing. Limit work in progress. And when something is blocked, swarm it, do not start something new, because starting new work is how blocked work becomes furniture.

**AMARA**  [06:47]
Is there one question that cuts through?

**NADIA**  [06:50]
In every stand up: what is the oldest item on this board, and what would finish it today? Ask that daily and the board fixes itself within a month.

### Sources for the on screen credit

- User stories and splitting patterns, Agile practice literature
- The Scrum Guide, Scrum.org
- Flow and work in progress limits, Lean Kanban literature

---

*Copyright WAJD Group. Built by WAJD AI.*