Ceremonies kunnen het probleem verbergen.

Ik ben geen grote voorstander van ceremonies omwille van de ceremonie. Sprint planning, stand-ups, reviews en retrospectives hebben alleen waarde wanneer ze iets zichtbaar maken en tot aanpassing leiden.

Dat is trouwens ook de bedoeling van Scrum zelf: transparency, inspection en adaptation. Zodra het ritueel belangrijker wordt dan wat je probeert te zien, kan het net problemen maskeren.

Ford maakte de bewegende assemblagelijn groot in de autoproductie. Daardoor kon een auto veel efficiënter geproduceerd worden. Maar een perfect georkestreerde productielijn helpt je weinig wanneer je de verkeerde auto bouwt, voor het verkeerde publiek, met een fout kostenmodel.

In software zie ik hetzelfde. Teams hebben sprints, reviews, dashboards en vaste cadans. Vandaag komen daar LLM-workflows en agentic development bij, opnieuw met frameworks en processen om sneller en herhaalbaarder te werken.

En toch lopen projecten uit. Het uiteindelijke product mist de werkelijke behoefte. De architectuur wordt zwaarder dan de organisatie kan dragen. Operationele kosten verschijnen pas laat.

Dan ligt het probleem vaak vóór de ceremonie: een onduidelijke visie, verkeerde probleemdefinitie, onvoldoende mandaat, onrealistisch budget of tijdsbestek, of keuzes die nooit echt gemaakt zijn.

Een ceremonie kan daarbij helpen, zodra ze dat zichtbaar maakt. Ze wordt gevaarlijk wanneer ze de indruk geeft dat het project onder controle is omdat het proces netjes gevolgd wordt.

Goede uitvoering begint met het juiste probleem zien.