Module 1 of 2 · 40 minutes
What each ceremony is for, and how to spot theatre
By the end of this module you will be able to
- State the purpose of each ceremony and diagnose failure
- Choose between Scrum and Kanban
- Identify agile theatre
- Say when a predictive approach fits better
Work through it
1 interactive for this module, built on the WAJD Teach engine. Nothing moves until you ask it to, and every one has a written version if you would rather read it.
Amara We have stand ups, sprints and a board, and it feels like nothing has changed except we have more meetings.
Nadia Then you probably have agile theatre, and it is extremely common. The test I would apply is one question.
Amara Which is?
Nadia What have you decided not to build, as a result of something you learned?
Amara Nothing. We are building the list that was signed off last year.
Nadia 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 Let us take them one at a time. What is a stand up actually for?
Nadia One question. Has anything changed since yesterday that affects what we do today. It is a planning event for the team.
Amara Ours is a status report.
Nadia 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.
Amara Sprint planning?
Nadia 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 Not really.
Nadia Then it is not planning, it is allocation with a ceremony wrapped round it. A commitment somebody cannot decline is not a commitment.
Amara Review?
Nadia 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 Retrospective. Ours is quite miserable.
Nadia 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 How do I fix that?
Nadia 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.
Amara Scrum or Kanban? Nobody has ever explained the difference usefully.
Nadia Scrum is fixed length sprints with committed scope. It suits work you can plan in batches, and it protects a team from interruption.
Amara And Kanban?
Nadia Continuous flow with work in progress limits and no sprints. It suits work that arrives unpredictably. Support, operations, maintenance.
Amara We do support work in sprints.
Nadia 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 Last question, and it feels heretical. Is agile always right?
Nadia 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 And when is it not?
Nadia 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 So choose.
Nadia 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.
The written material
Every ceremony answers one question
Ceremonies become rituals when nobody remembers what question they answer. Each has exactly one.
Stand up: has anything changed since yesterday that affects what we do today? It is a planning event for the team, not a status report to a manager. The moment people are reporting upwards, it is dead, and you can tell because everyone speaks to the same person rather than to each other.
Sprint planning: what can we commit to, and do we understand it well enough to start? If the team cannot say no during planning, it is not planning, it is allocation.
Review: is this what was needed? Show working software to people who will use it and listen to what they say. A review with no users in it is a demo to your own department.
Retrospective: what will we change? A retrospective that produces no change is a support group, and after three of them people stop bringing anything real.
Scrum or Kanban
Scrum works in fixed length sprints with a committed scope, defined roles and a cadence of ceremonies. It suits work that can be planned in batches and a team that needs the structure to protect it from interruption.
Kanban is continuous flow with work in progress limits and no sprints. It suits work that arrives unpredictably and must be responded to: support, operations, maintenance, anything where an incident does not wait for the next sprint.
Forcing support work into sprints is one of the most common mistakes. The sprint commitment is broken every time an urgent issue arrives, the team learns that commitments are meaningless, and the ceremony becomes a fiction everybody maintains politely.
Agile theatre
The organisation has stand ups, sprints and a board. It also has requirements signed off nine months ago, a fixed date, fixed scope and a fixed budget. That is waterfall with ceremonies attached, and it gets the overhead of both approaches and the benefit of neither.
The signs: the backlog is a work breakdown structure with story points on it. Nothing has ever been removed from scope as a result of learning. Retrospectives produce actions nobody owns. The date was set before anybody estimated anything. And feedback from real users arrives after build rather than during it.
The test that cuts through all of it: what have we decided not to build as a result of something we learned? If the answer is nothing, the feedback loop is decorative, and no amount of ceremony will help.
When not to use it
Agile suits work where requirements are genuinely uncertain and where feedback changes what you build. That is not all work, and pretending otherwise is expensive.
A predictive approach is often better where the requirement is fixed and well understood, where regulation demands specification and approval before build, where integration must happen as a single event such as a physical migration or a hardware install, or where the cost of change late is genuinely enormous.
The mature position is to choose deliberately and say why, rather than adopting whichever the organisation currently believes in. Most real programmes are a mix: predictive at the boundaries, iterative in the middle.
Knowledge check
The knowledge check and your certificate need a free account, so that your progress and results can be saved as evidence.
The learning itself stays free and open. You are reading all of it right now without an account.