Sjabloon voor een dagelijkse standup-agenda (die engineers echt gebruiken)

Het probleem met de meeste standup-sjablonen

De meeste standup-sjablonen zijn gemaakt voor teams die niet echt een standup houden. Drie vragen per persoon, vijf mensen, 15 minuten wordt een planningsvergadering als het team het laat uitdijen. Het onderstaande sjabloon is geoptimaliseerd voor één ding: de standup onder de 10 minuten houden en er tegelijk voor zorgen dat de juiste informatie naar boven komt en wordt vastgelegd. De vragen zijn bewust smal gehouden. De onderdelen na de ronde regelen al het andere.

De agenda (kopieer en plak dit)

Duur: maximaal 10 minuten
Vorm: synchroon, elke persoon spreekt één keer

Voor elk teamlid (90 seconden per persoon):

  1. Gedaan sinds de vorige standup — opgeleverd of gemerged, niet in uitvoering
  2. Gepland voor vandaag — wat je van plan bent af te ronden, geen ambitieus sprintwerk
  3. Blokkades — noem de verantwoordelijke; "wachten op de designreview" telt alleen als iemand verantwoordelijk is voor het deblokkeren

Na de ronde (resterende tijd):

  • Benodigde beslissingen — alles wat nu een knoop moet doorhakken; als het meer dan 2 minuten kost, plan dan een aparte vergadering
  • Mededelingen — één zin per punt, geen discussie tijdens de standup

Parkeerlijst: als er halverwege de ronde een onderwerp opduikt dat niet de hele groep aangaat, noteer het dan en handel het daarna of asynchroon af. De discussie op de parkeerlijst — meestal 2-3 mensen in plaats van het hele team — is vaak nuttiger dan de standup zelf.


Wat de meeste standup-sjablonen missen

De best gerangschikte standup-sjablonen vervallen in twee faalmodi.

Het kale geraamte ("Wat heb je gedaan? Wat ga je doen? Blokkades?") werkt prima totdat het team blokkades als optioneel gaat behandelen. Niemand noteert "wachten op de securityreview" omdat er niets gebeurt als ze dat doen. Afhankelijkheden raken verloren en worden gedeblokkeerd door wie er de volgende week toevallig naar vraagt.

De opgetuigde versie voegt 8 tot 12 vragen en een teamgezondheidscheck toe. Dat maakt van de standup een stafvergadering. Engineers letten niet meer op na de eerste twee sprekers.

Beide versies delen hetzelfde onderliggende probleem: ze kaderen de standup als een rapportageoefening. De standup is een afstemmingsoefening. Rapporteren levert informatie op; afstemmen levert actie op. Dat onderscheid is bepalend voor hoe je de tijd voor de vragen bewaakt en wat er gebeurt nadat de ronde is afgelopen.

Het tweede wat de sjablonen onbenoemd laten, is wat er met de informatie gebeurt na het gesprek. Zelfs goed geleide standups leveren blokkades op die niet worden opgevolgd, beslissingen die niemand opschrijft, en actiepunten zonder verantwoordelijke.

Waarom standup-samenvattingen instorten

De aanpak met een roulerende notulist knapt binnen een paar weken af. Wie aan de beurt is, wordt overspoeld, slaat de details over en post iets vaags dat niemand leest. Het team vertrouwt de notities niet meer, stopt met lezen, en dan houden de notities op enig nut te hebben.

Asynchrone standups — je update in Slack posten vóór het gesprek — lossen het aanwezigheidsprobleem op, maar verliezen het aspect van verantwoording dat voortkomt uit een live ronde. Mensen vragen later op de dag alsnog "wat hebben we over X besloten?".

De verborgen kosten stapelen zich snel op. Voor een blik op wat verloren standup-context een team over een kwartaal kost, zie De vergadertaks.

Hoe Pavleur de samenvatting afhandelt

Houd je standup met deze agenda en met Pavleur open. Wanneer het gesprek eindigt, wordt het rapport automatisch gegenereerd — geen notulist, geen 5 minuten opruimen na de standup. De samenvatting legt de gedaan/gepland/blokkades-punten van elke persoon vast, haalt de genomen beslissingen eruit en somt de actiepunten op met de verantwoordelijken zoals ze in de vergadering zijn genoemd.

Wat tools met alleen audio missen: als iemand halverwege de standup een PR-dashboard, een Jira-board of een deploymentgrafiek laat zien, legt Pavleur dat vast en neemt het met context op in het rapport. Tools zoals Otter of Fireflies geven je de woorden; de visuele vastlegging van wat er op het scherm stond, bestaat niet. Wie de standup heeft gemist, kan het volledige rapport lezen zonder te vragen wat er is gebeurd. Als je tools op dit vlak vergelijkt, behandelt de vergelijkingspagina de verschillen.

De tijdslimiet afdwingen

De discipline van 90 seconden per persoon knapt het vaakst af wanneer de EM halverwege de ronde vragen begint te beantwoorden. Train het reflex om te zeggen "dat pakken we daarna op" en noteer het op de parkeerlijst.

Als de standup stelselmatig langer dan 10 minuten duurt, is de oorzaak meestal een van deze: te veel mensen (splits de standup op), agendapunten die vanuit de sprintplanning binnensluipen, of een terugkerend discussieonderwerp dat een eigen terugkerende vergadering nodig heeft. Los de structurele oorzaak op in plaats van alleen het symptoom.

Sjabloon voor een dagelijkse standup-agenda (die engineers echt gebruiken) | Pavleur