Alternatieven voor de daily standup: bewijs en scripts

Iemand in je team heeft dat bericht allang getypt. Iets in de trant van “ik denk niet dat de daily standup voor ons werkt.” Toen keek diegene ernaar, bedacht hoe het zou vallen, wiste het en klikte de call in.

Dat wissen is waar dit stuk eigenlijk over gaat. Het onderzoek naar standups is niet moeilijk te vinden en wijst grotendeels dezelfde kant op. Wat moeilijk is, is de zin zelf. Je probeert iets te zeggen dat drie sociale risico’s tegelijk met zich meebrengt, en alle drie plakken ze aan jou persoonlijk.

Risico één: je klinkt lui. Elk verzoek om een meeting te schrappen leest standaard als een verzoek om minder in de gaten gehouden te worden.

Risico twee: je klinkt als iemand die niet meedoet met het team. De standup wordt neergezet als het ding dat iedereen op één lijn houdt. Bezwaar maken tegen de standup klinkt dan als bezwaar maken tegen op één lijn zitten.

Risico drie: je valt een persoon aan, geen proces. Iemand is eigenaar van die meeting. Een scrum master, een manager, of degene die hem twee jaar geleden heeft ingepland. Die persoon hoort kritiek op het ritueel als kritiek op zijn oordeel, want in de meeste teams is dat het ook.

Dus zegt niemand iets, en blijft de meeting bestaan puur omdat niemand de juiste woorden heeft gevonden.

Het goede nieuws: die woorden bestaan wel, en ze zijn niet ingewikkeld. Ze moeten alleen in een bepaalde volgorde staan, en die volgorde doet meer werk dan het bewijs.

De omkering die de discussie wint

Betoog niet dat de standup tijdverspilling is. Dat argument verliest, elke keer weer, om de drie redenen hierboven.

Betoog in plaats daarvan dat de versie die jullie draaien niet de meeting is die het hoort te zijn, en bied een omkeerbaar experiment aan om dat te repareren.

De Scrum Guide staat hier aan jouw kant, en dat is precies het stuk dat bijna niemand nakijkt. De Guide uit 2020¹ omschrijft de Daily Scrum als een event van 15 minuten voor de Developers van het Scrum Team, om de voortgang richting het Sprint Goal te inspecteren en het plan aan te passen. Er staat nergens dat het een rapportage aan een manager is. De herziening van 2020 schrapte ook de drie voorgeschreven vragen die de meeste teams elke ochtend nog opdreunen.¹

Als jullie standup een rondje is waarin mensen gisteren en vandaag rapporteren aan wie het hoogst in rang is, verdedig je Scrum niet door hem te houden. Je draait iets wat het reglement zelf al heeft laten vallen, en dat kun je hardop zeggen zonder iemand ergens van te beschuldigen.

Dat is de hele beweging. Je vraagt niet om minder verantwoording. Je vraagt om de meeting te draaien zoals het framework hem beschrijft, en om te testen of een goedkoper format standhoudt.

Deel 1: De argumenten die overeind blijven

Ik heb veel van de cijfers die over dit onderwerp rondgaan geschrapt. Achteraan staat een noot over welke en waarom. Wat hier volgt is wat ik een sceptische manager zou voorleggen.

1. Het is een statusrapport naar boven geworden, en het framework zegt juist dat het dat niet moet zijn. De best gedocumenteerde manier waarop het misgaat. De grounded theory-studie van Stray, Sjøberg en Dingsøyr naar daily stand-ups liet zien dat deelnemers ze waardeerden om het delen van informatie en het samen oplossen van problemen, en negatief reageerden zodra de meeting veranderde in statusrapportage aan een manager of te vaak en te lang werd gehouden.² Dezelfde bevinding komt terug in de praktijkliteratuur van dezelfde onderzoeksgroep.⁴

2. De drie vragen leveren verhaaltjes op in plaats van coördinatie. “Gisteren heb ik aan het ticket gewerkt, vandaag ga ik verder met het ticket.” Niemand vraagt door. Er verandert niets door. Het format nodigt uit tot een opvoering van bedrijvigheid in plaats van tot een inspectie van de voortgang richting een doel, en precies daarom schrapte de Guide van 2020 die vragen.¹

3. Senior engineers en grote teams halen er het minst uit. Stray en collega’s ondervroegen professionele developers en zagen de beoordelingen over het geheel rond neutraal blijven hangen: junior developers waren positiever, senior developers en mensen uit grotere teams zagen er vaker weinig waarde in.³ Als je meest ervaren mensen het minst betrokken zijn in de meeting, zegt dat iets over het format, niet over hen.

4. Het hakt je ochtend doormidden. Het betoog van Paul Graham uit 2009¹³ gaat nog steeds op. Mensen die dingen maken hebben lange, ononderbroken blokken nodig, en één meeting midden in een ochtend kan die hele ochtend slopen door hem in twee stukken te knippen die allebei te klein zijn voor moeilijk werk. Een standup om 10.30 uur is het klassieke voorbeeld. Er zitten ook kosten in de aanloop. In de 45 minuten ervoor begint niemand nog aan iets diepgaands.

5. Wisselen van taak verslechtert het werk aan beide kanten van de meeting. Het onderzoek van Sophie Leroy introduceerde attention residue: als je van de ene taak naar de andere schakelt, blijft een deel van je aandacht achter bij de eerste en lijdt je prestatie op de tweede daaronder.⁵ Een standup dwingt die wissel twee keer af bij iedere deelnemer, één keer erin en één keer eruit.

6. Terugkomen in je werk kost echt tijd. Het onderbrekingsonderzoek van Gloria Mark is de bron van het veelgeciteerde getal van ongeveer 23 minuten om terug te keren naar een onderbroken taak, en haar werk met Gudith en Klocke liet ook zien dat mensen onderbrekingen compenseren door sneller te werken, ten koste van meer stress, frustratie en ervaren werkdruk.⁶ Citeer deze voorzichtig. Het is het meest misbruikte getal in het hele productiviteitsdebat, en een manager die de ontkrachting ervan heeft gezien, gebruikt dat tegen je.

7. Blockers worden benoemd, niet opgelost. Let hier eens op in je eigen team. Iemand zegt dat hij vastzit, iedereen knikt, en de echte oplossing komt veertig minuten later in een DM tussen twee mensen. Als dat het patroon is, heeft de meeting de blocker niet opgelost. Hij heeft alleen het gesprek ingepland dat dat wel deed.

8. Meetingdruk stapelt zich fysiek op. Het Human Factors Lab van Microsoft deed EEG-metingen bij mensen in aaneengesloten meetings en zag stressmarkers oplopen naarmate de reeks vorderde, terwijl korte pauzes die opbouw remden.⁸ Het meetingonderzoek van Steven Rogelberg documenteert hetzelfde vanuit de enquêtekant, inclusief de hersteltijd die mensen kwijt zijn aan bijkomen van een slechte meeting, en die komt boven op de duur van de meeting zelf.⁷

9. Het past niet bij verspreide teams. Er is altijd iemand die hem op een beroerd tijdstip moet doen. Het all remote-handboek van GitLab¹⁴ is het meest complete openbare pleidooi om status in plaats daarvan asynchroon af te handelen, en het is juist een bruikbare referentie omdat het van een bedrijf komt dat zo op schaal werkt, en niet van een blog.

10. Een dagelijkse cadans rekent een dagelijkse prijs, ook als er niets te coördineren valt. In teams waarvan het werk losjes gekoppeld is, komt de echte coördinatiebehoefte met horten en stoten. De vaste meeting betaalt te veel op elke rustige dag.

Deel 2: Het tegenbewijs, dat je zelf moet meebrengen

Loop naar binnen met het verhaal tegen jezelf al verteld. Dat is de snelste route naar serieus genomen worden, en het voorkomt dat je manager het gevoel krijgt dat hij de meeting in zijn eentje moet verdedigen.

Goed uitgevoerde standups doen drie dingen die lastig te vervangen zijn.

Ze halen blockers vroeg naar boven. Een probleem dat om 09.30 uur op tafel komt en anders een hele dag had opgeslokt, is die vijftien minuten in zijn eentje al waard. Dit is de functie die je vervanging absoluut moet afdekken.

Ze bouwen een gedeeld beeld op van wie waarmee bezig is, waardoor er minder dubbel en tegen elkaar in gewerkt wordt. Stray en Dingsøyr documenteren dit als een van de echte voordelen die mensen noemen.²

Ze ondersteunen psychologische veiligheid. Rietze en Zacher vonden een positief verband tussen daily stand-ups en psychologische veiligheid, wat op zijn beurt samenhing met werkplezier en met het beeld dat mensen hadden van de teamprestatie.¹⁰ Dat komt boven op het fundamentele werk van Edmondson, dat psychologische veiligheid koppelt aan leergedrag in teams.⁹ Een regelmatig contactmoment met lage inzet doet iets voor het vertrouwen, zeker in nieuwe of verspreide teams.

Geef dus toe waar het klopt. Is je team klein, strak gekoppeld, junior of drie weken oud, dan verdient de standup zijn kosten waarschijnlijk terug, en dat mag je gerust hardop zeggen.

Deel 3: Haal je eigen data op voordat je je mond opendoet

Twee weken. Drie dingen. Doe dit vóór het gesprek, want een mening verliest het van een ritueel en rekenwerk niet.

Meet de echte lengte, niet de ingeplande lengte. Klok hem elke dag. De meeste teams ontdekken dat de meeting van 15 minuten een meeting van 22 minuten is.

Reken het door in salaris. Aantal deelnemers, maal de echte duur in uren, maal het aantal werkdagen per jaar. Een team van acht bij eerlijke 15 minuten is 2 manuren per dag, ongeveer 10 per week, zo’n 460 manuren per jaar. Bij een all-in kostprijs van 60 euro per uur is dat rond de 27.000 euro, en dat getal laat de hersteltijd aan weerskanten nog buiten beschouwing. Gebruik de cijfers van je eigen team, dan kan niemand over de invoer vallen.

Tel de blockers. Schrijf tien werkdagen lang elke blocker op die in de standup genoemd wordt, en noteer erbij of hij in de meeting zelf is opgelost of ergens anders daarna. Dit is meestal het getal dat de discussie beslecht.

Vraag het team anoniem. Eén vraag. Helpt de standup je bij je werk, ja of nee, en waarom. Anonimiteit is wat je het echte antwoord oplevert, en het betekent ook dat je namens het team spreekt in plaats van namens jezelf, waarmee risico twee van het lijstje bovenaan verdwijnt.

Deel 4: De formulering

Vier situaties, vier scripts. Pas de details aan, houd de structuur, want de structuur doet het werk.

Ze volgen allemaal dezelfde vier stappen. Erken wat de ander echt nodig heeft. Benoem de kosten in zijn termen. Stel iets voor dat omkeerbaar is en een einddatum heeft. Leg de bewijslast en het inrichtwerk bij jezelf.

Tegen je manager, in een een-op-een

“Ik wil de focustijd van het team beschermen zonder dat jij zicht kwijtraakt, en ik heb twee weken data over hoe onze standup echt gebruikt wordt. Hij duurt 22 minuten, geen 15. Dat is ongeveer 675 manuren per jaar voor ons achten. In tien dagen zijn er zes blockers genoemd en is er één echt in de meeting opgelost. De rest is daarna in DM’s opgelost.

Ik zou dit vier weken willen proberen. Geschreven updates in een gedeeld kanaal voor 09.30 uur, die jij kunt lezen wanneer het jou uitkomt, een apart blockerkanaal waarin mensen jou meteen taggen zodra iets vastloopt, en één live sync per week. Ik houd de oplostijd van blockers bij en zet die af tegen wat we nu hebben. Wordt het slechter, dan gaan we terug en zeg ik dat zelf in de retro. Ik zet het allemaal op.”

Tegen je scrum master

“Ik heb de Guide van 2020 er weer eens bij gepakt. Die omschrijft de Daily Scrum als een event voor de developers, en de drie vragen zijn eruit gehaald. De onze is afgedreven naar een rondje updates richting wie het hoogst in rang is, en dat is precies wat de Guide probeert te voorkomen.

Zullen we hem één sprint lang vanaf het board draaien in plaats van het rondje langs de mensen, en daarna aan de developers vragen of het voor hen nuttiger werd?”

Let op wat dit doet. Het maakt het framework de autoriteit in plaats van jou, en het maakt hem degene die de praktijk herstelt in plaats van degene die een kapotte versie ervan verdedigt.

Tegen je collega’s, voordat je iets anders doet

“Zeg het eerlijk. Helpt de standup je echt, of is het gewoon iets wat je doorstaat? Ik wil het aankaarten, maar alleen als ik namens het team praat en niet alleen namens mezelf.”

Doe dit eerst. Altijd. Als twee mensen zeggen dat de standup het enige moment is waarop ze om hulp durven vragen, moet je voorstel dat overeind houden, en nu weet je dat voordat je je in het openbaar hebt vastgelegd.

In een retrospective

“Ik wil vandaag één ding inspecteren. Ik heb onze standup twee weken bijgehouden. Dit is wat hij kost en dit is hoeveel blockers hij echt heeft opgelost. Ik vraag niet om hem te schrappen. Ik vraag of we het format één sprint veranderen en naar de cijfers kijken voordat we iets definitiefs besluiten.”

Als geschreven voorstel

Onderwerp: experiment van vier weken, async standup

Op dit moment duurt onze daily standup 22 minuten met acht mensen, wat neerkomt op zo’n 675 manuren per jaar. In de afgelopen tien werkdagen zijn er zes blockers in genoemd en werd er één binnen de meeting opgelost.

Voorstel, vier weken, volledig omkeerbaar:

Geschreven check-ins in #team-standup voor 09.30 uur, drie regels per persoon. Voortgang richting het sprintdoel, focus voor vandaag, waar het vastloopt. Blockers worden meteen bij de juiste persoon getagd zodra ze opduiken, in plaats van bewaard tot de volgende ochtend. Eén live sync van 30 minuten op maandag voor de planning en alles waar een gesprek voor nodig is.

Ik houd de oplostijd van blockers bij, de doorlooptijd en een korte teampuls, en breng alle drie mee naar de retro op [datum]. Wordt de oplostijd van blockers slechter, dan draaien we het terug. Ik richt de tooling in en begeleid de proef.

De expliciete terugdraaivoorwaarde is de belangrijkste regel in dat bericht. Die maakt van je voorstel een test in plaats van een verandering, en die levert meestal de ja op.

Deel 5: Wat ze terug gaan zeggen

“Ik moet zicht houden op wat iedereen doet.” Geschreven updates geven je meer dan een meeting. Ze zijn doorzoekbaar, ze blijven staan, en je kunt ze om 07.00 uur of om 19.00 uur lezen in plaats van om 09.30 uur in een kamer te zitten.

“Blockers blijven liggen.” Precies andersom. Een blocker die geplaatst wordt op het moment dat hij opduikt, krijgt sneller aandacht dan een blocker die tot de volgende ochtend blijft liggen. Dat is precies de metriek die ik voorstel om bij te houden, en het is degene waarop ik de proef zou afblazen.

“Het is maar een kwartier.” Het is een kwartier maal acht mensen, elke werkdag, plus de tijd die iedereen nodig heeft om terug te komen in waar hij mee bezig was. Dit is het jaarcijfer.

“Scrum schrijft een Daily Scrum voor.” Scrum schrijft een Daily Scrum voor de developers voor, en de Guide van 2020 heeft de drie vragen geschrapt die wij nog steeds gebruiken. Wat wij draaien is niet wat de Guide beschrijft.¹

“Het team verliest zijn samenhang.” Dat is een echt risico, en daarom blijft de wekelijkse sync staan. Ik houd tijdens de proef ook een teampuls bij, dus als de samenhang afneemt, zien we dat in plaats van dat we ernaar gissen.

Deel 6: Vijf manieren waarop mensen deze discussie verliezen

Het brengen als minder willen doen. Dat bevestigt precies het vermoeden waarmee de ander binnenkwam.

De meeting schrappen zonder een vervanging te noemen. De rommel die daarop volgt wordt aan jou persoonlijk toegeschreven, en terecht.

In je eentje beslissen. Een teamritueel verandert als teambesluit, of het is binnen een maand terug.

De proef en de cijfers overslaan, waarmee je een toetsbaar voorstel verandert in een meningenwedstrijd tegen de status quo, en die wint de status quo.

De mensen negeren voor wie het wel werkt. Als de junior in het team erop leunt, ontwerp je eromheen en zeg je dat hardop in de meeting. Het kost je niets en het haalt het sterkste bezwaar weg voordat iemand het maakt.

Deel 7: Wat ervoor in de plaats komt

	Live daily standup	Async geschreven updates	Wekelijkse sync plus blockerkanaal
Tijdskosten	Hoog, schaalt mee met de teamgrootte	Vrijwel geen synchrone kosten	Laag
Onderbrekingskosten	Hoog, dagelijks, midden in de ochtend	Minimaal, je plant het zelf	Laag, één vast moment
Snelheid bij blockers	Tot 24 uur wachten	Direct, als er getagd wordt	Direct, als er getagd wordt
Vastlegging	Geen, tenzij iemand het opschrijft	Standaard doorzoekbaar	Gedeeltelijk
Werkt over tijdzones heen	Slecht	Goed	Redelijk
Samenhang	Goed als het goed gedaan wordt	Zwak op zichzelf	Goed

Zeven opties, met bij elke optie het eerlijke nadeel erbij.

Async geschreven check-ins via een bot. Geekbot, Standuply of Range vragen iedereen om input en plaatsen die in een gedeeld kanaal.¹⁷ Werkt over tijdzones heen en laat een doorzoekbaar spoor achter. Kan verworden tot ongelezen statustheater als niemand reageert op wat er geplaatst wordt.

Twee standups per week. Houdt de live sync, halveert de frequentie. Makkelijk te verkopen omdat het een kleine verandering is. Heeft een kanaal ernaast nodig voor alles wat haast heeft.

Langs het board in plaats van langs de kring. Loop de werkitems van rechts naar links langs en praat over de tickets in plaats van over de mensen. Slaat de persoonlijke rapportagedynamiek meteen dood. Werkt alleen als het board echt bij is.

Een apart blockerkanaal. Het onderdeel met de meeste waarde en tegelijk het goedkoopst om toe te voegen. Vraagt de discipline om te posten, en iemand die meekijkt.

Pairen op afroep. De snelst mogelijke oplossing, zonder publiek. Vermindert het zicht voor het hele team, dus er moet een schriftelijk spoor bij.

Eén diepe sync per week. Ruimte voor de gesprekken die niet in een meeting van 15 minuten passen. Te weinig frequent om alleen te werken.

Dagen zonder meetings. De agenda-opschoning van Shopify in 2023 is het meest geciteerde voorbeeld uit het bedrijfsleven, waarbij naar verluidt duizenden terugkerende meetings uit de bedrijfsagenda verdwenen.¹⁵ Dit is een focusbeleid en geen coördinatiemechanisme, dus het moet gecombineerd worden met een van de bovenstaande.

De combinatie die het vaakst werkt: geschreven updates voor het dagelijkse overzicht, een blockerkanaal voor alles wat haast heeft, en één live sync per week voor de rest.

Deel 8: Zo ontwerp je de proef dat hij een retro overleeft

Kies je succesmetrieken voordat je begint, en kies metrieken waar je manager al in gelooft.

Oplevering. Eén maatstaf in DORA-stijl, meestal lead time for changes of deployment frequency.¹² Doorlooptijd werkt ook, als je niet vaak deployt.

Oplostijd van blockers. Je waarborg op het grootste risico. Dit is de metriek die het experiment moet kunnen afschieten, en dat hardop zeggen is wat het experiment geloofwaardig maakt.

Teampuls. Eén vraag, wekelijks, anoniem. Dit sluit aan op de satisfaction-dimensie van het SPACE-framework, dat juist bestaat omdat productiviteit meten met één enkele metriek misgaat.¹¹ Zonder die vraag kun je de doorstroom verbeteren terwijl je stilletjes mensen opbrandt, en dat nooit merken.

Vier weken is de juiste lengte. Twee is te kort om iets voorbij het nieuwtje te zien. Acht is lang genoeg dat terugdraaien gaat voelen als een publieke mislukking, waardoor mensen de proef gaan verdedigen in plaats van hem eerlijk te lezen.

Het stuk dat echt moeilijk is

Alles hierboven ligt klaar voor iedereen die er een middag voor gaat zitten. De meeste mensen die het nodig hebben, sturen dat bericht alsnog niet.

Het bewijs is niet wat ontbreekt. Wat ontbreekt is een versie van de zin die zegt dat de meeting niet werkt zonder te impliceren dat de persoon die hem leidt niet werkt, en dat is veel moeilijker te schrijven dan een lijstje bronnen. Hij wordt zes keer herschreven in een Slack-invoerveld en dan alsnog weggegooid.

Dat gat is de reden dat we Subtext bouwen. De meeste berichten die mensen niet verstuurd krijgen zijn inhoudelijk niet ingewikkeld. Het zijn berichten waarin gelijk hebben niet genoeg is en de formulering het hele risico draagt. Een standupvoorstel is een kleintje. Dezelfde vorm zie je terug bij om opslag vragen, scope afwijzen, een oprichter vertellen dat de roadmap niet klopt, en nee zeggen tegen een vriend.

Als je één ding meeneemt: stuur het bericht met de terugdraaivoorwaarde erin. “Wordt de oplostijd van blockers slechter, dan gaan we terug en zeg ik dat zelf.” Die ene zin haalt de reden weg die iemand had om nee te zeggen.

Een noot over de cijfers die ik heb weggelaten

Er gaan verschillende cijfers rond over dit onderwerp waar ik niet achter kon staan, dus die staan niet in de tekst hierboven.

De bewering dat 80% van de developers irrelevante updates als hun grootste standupfrustratie noemt, staat niet in de Stray-survey waaraan hij meestal wordt toegeschreven. De bewering dat 80% van de actiepunten uit meetings nooit wordt afgerond, reist rond zonder bron. De veelgeciteerde statistiek van “40% langer en 50% meer fouten”, toegeschreven aan een recent artikel in Journal of Experimental Psychology, blijkt een verhaspelde versie van Rubinstein, Meyer en Evans uit 2001, dat taakwisselingen in een lab mat en zich niet zomaar laat doortrekken naar een ochtendmeeting.¹⁸ Allerlei jaarlijkse bedragen per team voor verspilde meetingtijd hangen volledig af van de aannames erachter, en precies daarom rekent deel 3 met de cijfers van je eigen team.

Nog een eerlijk gat. Ik kon geen degelijk gecontroleerd onderzoek vinden dat asynchrone geschreven statusupdates rechtstreeks vergelijkt met synchrone statusmeetings op opleverresultaten. GitLab, Doist en Basecamp pleiten alle drie voor de geschreven versie en hebben alle drie een belang te verdedigen. Vraagt je manager om die vergelijking, dan is het eerlijke antwoord dat die nog niet lijkt te bestaan, en dat je proef van vier weken precies is hoe je hem voor je eigen team maakt.

Vind je dat jullie standup zijn kosten waard is, of dat ik het bewijs verkeerd lees? Laat het me weten op LinkedIn.

Samet Durgun is medeoprichter van Subtext, een app die de emotionele toon van je berichten opmerkt en ze herschrijft in je eigen woorden. Hij woont in Berlijn.

Bronnen

Elke link hierboven gaat naar de primaire bron, waar die bestaat.

The Scrum Guide (2020), Ken Schwaber en Jeff Sutherland, scrumguides.org. Het nuttigste document voor dit betoog. Lees de sectie over de Daily Scrum rechtstreeks en citeer hem letterlijk. Legt vast dat het event voor de developers is, 15 minuten duurt, en dat de drie vragen in de herziening van 2020 zijn geschrapt.
Stray, V., Sjøberg, D. I. K., and Dingsøyr, T. (2016). “The daily stand-up meeting: A grounded theory study.” Journal of Systems and Software, volume 114. Peer reviewed. Documenteert zowel de waarde (informatie delen, samen problemen oplossen) als de manieren waarop het misgaat (statusrapportage aan een manager, te hoge frequentie en te lange duur). Stuur deze naar een scrum master.
Stray, V., Moe, N. B., and Bergersen, G. R. (2017). “Are Daily Stand-up Meetings Valuable? A Survey of Developers in Software Teams.” XP 2017, Lecture Notes in Business Information Processing. Enquête onder professionele developers. Gerapporteerde cijfers zijn onder meer 87% van de agile teams die een daily standup houden, met gemiddelde beoordelingen rond neutraal, junior developers positiever, senior developers en grotere teams minder. Ik heb de richting van de bevinding gebruikt en niet het percentage.
Stray, V. en Moe, N. B., praktijkartikel in IEEE Software over het aanpassen van de daily stand-up. Betoogt dat starre standuprituelen aan het team aangepast horen te worden in plaats van standaard gevolgd. De exacte titel en het jaar zijn onbevestigd, want de versie die online rondgaat noemt aantallen deelnemers die ik niet kon bevestigen.
Leroy, S. (2009). “Why is it so hard to do my work? The challenge of attention residue when switching between work tasks.” Organizational Behavior and Human Decision Processes, volume 109, issue 2. De oorsprong van attention residue. Sterk bewijs van buiten de agile hoek dat taakwisselen de kwaliteit van wat erna komt aantast.
Mark, G., Gudith, D., and Klocke, U. (2008). “The Cost of Interrupted Work: More Speed and Stress.” CHI 2008. En Mark, G. (2023). Attention Span. Hanover Square Press. De bron van de bevindingen over onderbroken werk en van het getal van ongeveer 23 minuten hersteltijd dat overal rondgaat. Het getal is echt, maar wordt vaak met meer precisie geciteerd dan het onderliggende onderzoek toelaat, dus citeer het primaire werk en formuleer het als “meer dan 20 minuten”.
Rogelberg, S. G. (2019). The Surprising Science of Meetings. Oxford University Press. De standaardreferentie over verspilling in meetings en over herstel achteraf. Ik heb de kwalitatieve bevinding gebruikt en geen specifiek percentage, omdat de cijfers per enquête verschillen.
Microsoft Human Factors Lab, EEG-onderzoek naar pauzes tussen meetings, gepubliceerd via Microsoft WorkLab en de Work Trend Index van 2021. Fysiologisch bewijs dat stress zich opstapelt over opeenvolgende meetings en dat pauzes dat remmen. Bruikbaar omdat het meting is en geen enquête.
Edmondson, A. (1999). “Psychological Safety and Learning Behavior in Work Teams.” Administrative Science Quarterly. De fundamentele bron over psychologische veiligheid. Gaat over teams in het algemeen en niet specifiek over standups, dus claim geen causaal verband dat er niet staat.
Rietze, S. en Zacher, H., onderzoek naar daily stand-ups, psychologische veiligheid, werkplezier en het beeld van teamprestaties, European Journal of Work and Organizational Psychology. Het sterkste gepubliceerde argument vóór standups, en precies daarom moet je het zelf meebrengen. Het publicatiejaar is onbevestigd; de versie die rondgaat noemt 2025, wat ik niet kon bevestigen.
Forsgren, N., Storey, M.-A., Maddila, C., Zimmermann, T., Houck, B., and Butler, J. (2021). “The SPACE of Developer Productivity.” ACM Queue. Vrij te lezen. Gebruik de dimensie satisfaction and wellbeing om te onderbouwen waarom je naast opleveringscijfers ook een teampuls bijhoudt.
Forsgren, N., Humble, J., and Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press. De bron van de vier DORA-opleveringsmetrieken. Gebruik er één als je doorstroommaat, dan is de metriek verdedigbaar en niet voor de gelegenheid verzonnen.
Graham, P. (2009). “Maker’s Schedule, Manager’s Schedule.” paulgraham.com/makersschedule.html. Kort, gratis, en het overtuigendste wat je kunt doorsturen naar een collega die nog twijfelt.
GitLab all remote handbook, about.gitlab.com/company/culture/all-remote. Een grote organisatie die openlijk met asynchrone statusupdates werkt. Bewijs dat het model op schaal werkt, al heeft GitLab zelf belang bij dat betoog.
De agenda-opschoning van Shopify, januari 2023, zoals gerapporteerd door Bloomberg, Fortune en anderen. Gerapporteerd als het verwijderen van duizenden terugkerende meetings uit de bedrijfsagenda en een verbod op terugkerende meetings met meer dan twee mensen op woensdag. Het getal over teruggewonnen uren komt van het bedrijf zelf, dus schrijf het toe aan Shopify in plaats van het te brengen als gemeten feit.
Atlassian Agile Coach, richtlijnen voor standups. Advies uit de industrie om standups kort te houden en aan te passen aan wat het team nodig heeft, inclusief asynchrone vormen. Bruikbaar omdat het van een bron komt die je manager al vertrouwt op het gebied van agile.
Tools: Geekbot en Standuply voor async standups in Slack en Teams, Range voor teamcheck-ins. Controleer de huidige prijzen en de status van het product voordat je er intern een aanbeveelt.
Rubinstein, J. S., Meyer, D. E., and Evans, J. E. (2001). “Executive Control of Cognitive Processes in Task Switching.” Journal of Experimental Psychology: Human Perception and Performance. De echte oorsprong van de claim over “tot 40% van je productieve tijd” bij taakwisselen. Hier vermeld zodat je het zelf kunt nakijken in plaats van de verhaspelde versie te herhalen.