Agile delivery, honestly

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.

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.