Planning, daily stand-up, review, retrospective: running them is the easy part. The harder question is what they change. A ceremony that produces no change is a ritual, and on a fixed price a ritual is an hour of the whole team that nobody gets back.
The one forum that can question the plan
Planning, stand-ups and reviews keep the work moving inside the plan. The retrospective is different: it is the one place where the team is allowed to question how it works, and sometimes the plan itself. That is why I protect it, even when every hour is counted.
The team is also the best source of information about what slows it down. In a retrospective I keep the questions plain: what helped, what got in the way, what do we want to try. The last answer is where change comes from, and it is often not a tweak to the process but something about context, like the visit below.
An example: go and see the business
One retrospective surfaced a need that is easy to miss from behind a screen. Team members should visit the client, or go into a store, to understand the subtleties of the business context at grass-roots level. That understanding then helps them in development and testing.
A retrospective is worth the hour only if something is different on Monday.
What a document cannot carry
As I see it, a requirements document says what the system should do. It rarely carries the habits, the workarounds and the time pressure of the people who will use it. A developer who has watched real work understands why a screen needs three taps instead of six. A tester who has seen real conditions writes tests for real situations, not only for tidy ones.
A visit costs time away from the keyboard, and on a fixed price that time has to be planned and paid for from the budget. I still think it is the cheaper option. With 40% of the billing tied to UAT, a misunderstanding that only appears at UAT is the most expensive place to find it.
Different forums, different questions
Beyond the team's own ceremonies there are three forums I use with different audiences. The weekly PM sync is where the project managers look at the status report and the RAID log. The technical sync is where design and integration questions are answered by the people who know. The steerco is for decisions nobody else on the project can make.
Mixing them is a common mistake. A steerco that debates a technical detail wastes senior time, and a technical sync that waits for a budget decision leaves the team standing still.
How I try to make a retrospective change something
- Few actions. One to three, not a list of twenty that nobody reads again.
- An owner and a date for each one, agreed in the room.
- A review at the start of the next retrospective, before any new topic.
- Room for ideas that cost something. If an action needs budget or the client's time, it goes to the weekly PM sync for a decision.
A ceremony earns its place by what it changes. When a retrospective sends a developer into a store and brings back a better test case, it has stopped being a ritual and become part of delivery.