Een korte stand-up met een remote team

Een goede stand-up met een remote team duurt een kwartier en gaat over werk dat vastzit. Status hoort er nauwelijks in, want die staat al op het bord. Schrap je het statusrondje, dan houd je tijd over voor de vragen waarvoor developers elkaar nodig hebben.

Waarom het statusrondje op afstand niet werkt

De bekende vorm is een rondje met drie vragen per persoon: wat deed je gisteren, wat doe je vandaag en zit je ergens vast. In een videocall loopt dat snel uit. Iedereen wacht op zijn beurt, en na een paar mensen luistert de rest niet meer. Het meeste wat er gezegd wordt, staat ook al in de tickets of in de pull requests.

De Scrum Guide schrijft die vragen sinds de versie van 2020 ook niet meer voor. Wat overblijft, is een Daily Scrum van 15 minuten voor de developers, om de voortgang naar het sprintdoel te bekijken en het werk voor de komende dag bij te stellen. Hoe het team dat doet, mag het zelf kiezen.

Loop het bord langs

Ik zou de stand-up rond het bord doen. Deel je scherm en loop de kolommen van rechts naar links door: eerst wat bijna af is, dan wat in review staat, daarna wat in uitvoering is. Bij elk ticket zegt de eigenaar alleen iets als er iets te melden is.

Zo komt vanzelf boven wat blijft hangen, zoals een PR die al twee dagen op een review wacht of een ticket dat al een week op "in progress" staat. Daar gaat het gesprek dan over. Wie niets op het bord heeft staan, valt ook op, en dat is meteen een vraag voor na de stand-up.

Van rechts naar links werkt omdat werk afmaken meer oplevert dan nieuw werk beginnen. Een ticket dat bijna af is en op één antwoord wacht, wil je vandaag nog dicht hebben.

Wat er niet in de stand-up hoort

Een paar dingen lijken handig in de stand-up, maar maken hem lang:

• Technische discussies. Beginnen twee mensen erover, spreek dan af dat ze er direct na de stand-up samen naar kijken.
• Uitgebreide updates. Wat iemand gisteren heeft gedaan, staat in de commits en de tickets.
• Prioriteiten verschuiven of werk herverdelen. Dat hoort in de planning of bij de product owner.
• Mededelingen voor iedereen. Die zet je in de chat.

Wat overblijft, is kort: wat zit er vast en wie heeft daar iemand anders voor nodig.

Een vast tijdstip, niet als eerste van de dag

Kies een vast moment waarop iedereen er is. Met een team in Servië is dat eenvoudig, want Servië zit in dezelfde tijdzone als Nederland. Een stand-up om half tien is in Belgrado ook half tien.

Plan de stand-up niet als eerste afspraak van de dag. Wie om negen uur begint, heeft dan nog niet gekeken wat er sinds gisteren is gebeurd. Een half uur later heeft iedereen de mail, de reviews en de chat bijgelezen.

Houd het tijdstip ook vast als er iets tussenkomt, want een stand-up die steeds verschuift, gaan mensen overslaan.

Camera, afspraken en wie het leidt

Een camera aan helpt, vooral als er nieuwe mensen in het team zitten: je ziet sneller dat iemand twijfelt of iets niet begrijpt. Maak er geen regel van die je moet handhaven. Als de rest de camera aan heeft, doet een nieuwe collega dat meestal ook. Hoe je iemand de eerste weken op weg helpt, staat in een remote developer onboarden.

Notuleer niet alles, maar leg de afspraken wel vast. Wie kijkt na de stand-up met wie naar welk probleem? Dat is één regel in het teamkanaal, zodat wie er niet bij was weet wat er is afgesproken.

Laat de stand-up ook niet altijd door dezelfde persoon leiden. Voert de lead aan de kant van de opdrachtgever elke dag het woord, dan wordt het al snel een rapportage aan de baas. Laat je het binnen het team rouleren, dan blijft het een overleg tussen developers.

Async als aanvulling

Een geschreven stand-up in de chat kan een call vervangen op dagen dat de helft van het team vrij is of in andere afspraken zit. Elke developer schrijft dan twee regels: waar werk ik aan en waar wacht ik op. Hoe je dat zo opschrijft dat een ander er iets mee kan, staat in async werken: wat schrijf je op.

Ik zou async niet de standaard maken. Een korte call houdt een team dat op verschillende plekken zit bij elkaar. Je hoort het als iemand ergens mee worstelt, en dat lees je zelden in twee regels tekst.

Als de stand-up te lang duurt

Duurt de stand-up structureel langer dan een kwartier, dan is het team te groot of wordt de stand-up voor iets anders gebruikt. Mijn grens ligt bij ongeveer acht mensen. Daarboven splits je op per stroom van werk, en stemmen de leads daarna kort met elkaar af.

Horen developers in de stand-up dingen voor het eerst die al in een ticket hadden moeten staan, dan zit het probleem in de voorbereiding van het werk, en een langere stand-up lost dat niet op. Kijk dan eerst naar je tickets, bijvoorbeeld met de punten uit tickets die een remote developer begrijpt.

Bronnen

• The Scrum Guide (2020)
• Scrum Guide, overzicht van de revisies