Du ved godt, at jeres standup ikke fungerer. Det svære er at sige det.

Nogen på dit team har allerede skrevet beskeden. Noget i retning af “Jeg synes ikke, vores daily standup fungerer.” Så kiggede de på den, tænkte over, hvordan den ville lande, slettede den og gik med i mødet.

Den sletning er det, den her tekst egentlig handler om. Forskningen i standups er ikke svær at finde, og det meste af den peger samme vej. Det svære er sætningen. Du prøver at sige noget, der bærer tre forskellige sociale risici på én gang, og alle tre hænger på dig personligt.

Risiko et: du lyder doven. Enhver anmodning om at fjerne et møde læses som udgangspunkt som et ønske om, at der bliver holdt mindre øje med dig.

Risiko to: du lyder som en, der ikke er teamplayer. Standuppen bliver præsenteret som det, der holder alle på linje. At protestere mod den lyder som at protestere mod at være på linje.

Risiko tre: du angriber en person, ikke en proces. Der er nogen, der ejer det møde. En scrum master, en leder eller den, der satte det op for to år siden. De hører kritik af ritualet som kritik af deres dømmekraft, for i de fleste rum er det præcis, hvad det er.

Så folk siger ingenting, og mødet kører videre alene i kraft af, at ingen har fundet ordene.

Den gode nyhed er, at ordene findes, og at de ikke er komplicerede. De skal bare sættes sammen i en bestemt rækkefølge, og rækkefølgen betyder mere end dokumentationen gør.

---

Den omformulering, der vinder diskussionen

Argumentér ikke for, at standuppen er spild af tid. Det argument taber, hver gang, af de tre grunde ovenfor.

Argumentér i stedet for, at den version, jeres team kører, ikke er det møde, den er tænkt som, og tilbyd et forsøg, der kan rulles tilbage, som løsningen.

Scrum Guide er på din side her, og det er den del, de færreste får slået op. Guiden fra 2020¹ definerer Daily Scrum som en begivenhed på 15 minutter for udviklerne i scrumteamet, hvor de inspicerer fremdriften mod sprintmålet og tilpasser planen. Den er ikke defineret som en rapport til en leder. Revisionen fra 2020 fjernede desuden de tre foreskrevne spørgsmål, som de fleste teams stadig remser op hver morgen.¹

Hvis jeres standup kører som en runde, hvor folk rapporterer i går og i dag til den mest seniore i rummet, forsvarer du ikke Scrum ved at beholde den. Du kører noget, regelbogen selv har droppet, og det kan du sige højt uden at beskylde nogen for noget.

Det er hele manøvren. Du beder ikke om mindre ansvarlighed. Du beder om at køre mødet, som frameworket beskriver det, og om at teste, om et billigere format holder.

---

Del 1: De argumenter, der holder til et nærmere kig

Jeg har skåret en masse af de tal væk, der cirkulerer om det her emne. Der er en note til sidst om hvilke og hvorfor. Det følgende er det, jeg ville lægge foran en skeptisk leder.

1. Den er blevet en statusrapport opad, og det siger frameworket selv, den ikke skal være. Den bedst dokumenterede fejlform. Stray, Sjøberg og Dingsøyrs grounded theory-studie af daily stand-ups fandt, at deltagerne satte pris på dem som informationsdeling og fælles problemløsning, og at de reagerede negativt, når mødet blev til statusrapportering til en leder eller kørte for ofte og for længe.² Det samme fund dukker op i praktikerlitteraturen fra den samme forskergruppe.⁴

2. De tre spørgsmål producerer fortælling i stedet for koordinering. “I går arbejdede jeg på ticketen, i dag arbejder jeg videre på ticketen.” Ingen spørger ind. Der sker ingenting som følge af det. Formatet opfordrer til en opvisning i aktivitet frem for en inspektion af fremdrift mod et mål, og det er derfor, guiden fra 2020 droppede spørgsmålene.¹

3. Seniorudviklere og store teams får mindst ud af den. Stray og kolleger spurgte professionelle udviklere og fandt vurderinger, der samlede sig omkring neutral, hvor juniorudviklere var mere positive, og seniorudviklere og folk på større teams oftere så begrænset værdi.³ Hvis dine mest erfarne folk er de mindst engagerede i rummet, siger det noget om formatet, ikke om dem.

4. Den flækker formiddagen. Paul Grahams argument fra 2009¹³ holder stadig. Folk, der laver ting, har brug for lange uafbrudte blokke, og et enkelt møde midt på formiddagen kan ødelægge hele formiddagen ved at skære den i to stykker, der begge er for små til svært arbejde. En standup klokken 10.30 er skoleeksemplet. Der er også en forventningsomkostning. Folk undgår at gå i gang med noget dybt i de 45 minutter, der ligger før.

5. At skifte opgave forringer arbejdet på begge sider af mødet. Sophie Leroys forskning introducerede begrebet attention residue: når du skifter fra én opgave til en anden, bliver en del af din opmærksomhed hængende ved den første, og din præstation i den anden lider under det.⁵ En standup tvinger det skifte igennem to gange for hver eneste deltager, én gang ind og én gang ud.

6. Det tager rigtig tid at komme tilbage i arbejdet. Gloria Marks forskning i afbrydelser er kilden til det ofte citerede tal på cirka 23 minutter, før man er tilbage i en afbrudt opgave, og hendes arbejde med Gudith og Klocke fandt også, at folk kompenserer for afbrydelser ved at arbejde hurtigere, til gengæld for mere stress, frustration og oplevet arbejdsbyrde.⁶ Citér det her tal forsigtigt. Det er det mest misbrugte tal i hele produktivitetssamtalen, og en leder, der har set det pillet fra hinanden, vil bruge det imod dig.

7. Blokeringer bliver nævnt, men ikke løst. Hold øje med det i dit eget team. Nogen siger, at de er blokeret, alle nikker, og den faktiske løsning sker fyrre minutter senere i en DM mellem to personer. Er det mønstret, løste mødet ikke blokeringen. Det satte kun tid af til den samtale, der gjorde.

8. Mødebelastning hober sig op fysiologisk. Microsofts Human Factors Lab kørte EEG på deltagere i møder i træk og fandt stressmarkører, der byggede sig op hen over rækken, hvor korte pauser dæmpede opbygningen.⁸ Steven Rogelbergs mødeforskning dokumenterer det samme fra spørgeskemasiden, sammen med den restitutionstid, folk bruger på at komme sig efter et dårligt møde, og den ligger oven i mødets egen længde.⁷

9. Den passer ikke til distribuerede teams. Der er altid nogen, der tager den på et skævt tidspunkt. GitLabs all remote-håndbog¹⁴ er det mest gennemførte offentlige argument for at håndtere status asynkront i stedet, og den er brugbar netop fordi den kommer fra en virksomhed, der arbejder sådan i stor skala, og ikke fra en blog.

10. En daglig kadence koster hver dag, uanset om der er noget at koordinere. På teams, hvor arbejdet er løst koblet, er det reelle koordineringsbehov sporadisk. Det faste møde betaler overpris på hver eneste stille dag.

---

Del 2: Modargumenterne, som du selv skal have med

Gå ind med sagen mod dig selv allerede fremlagt. Det er den hurtigste vej til at blive taget alvorligt, og det fjerner følelsen hos din leder af at stå alene med at forsvare mødet.

Standups, der køres godt, gør tre ting, som er svære at erstatte.

De får blokeringer frem tidligt. Et problem, der bliver nævnt klokken 09.30, og som ellers havde ædt en hel dag, er de femten minutter værd helt af sig selv. Det er den funktion, din erstatning ubetinget skal dække.

De bygger et fælles billede af, hvem der laver hvad, og det reducerer dobbeltarbejde og arbejde, der modarbejder hinanden. Stray og Dingsøyr dokumenterer det som en af de reelle fordele, folk rapporterer.²

De understøtter psykologisk tryghed. Rietze og Zacher fandt en positiv sammenhæng mellem daglige stand-up-møder og psykologisk tryghed, som igen hang sammen med arbejdsglæde og oplevelsen af teamets præstation.¹⁰ Det ligger oven på Edmondsons grundlæggende arbejde, der forbinder psykologisk tryghed med læringsadfærd i teams.⁹ Et fast mødepunkt med lave indsatser gør noget for tilliden, især på nye eller distribuerede teams.

Så giv dem ret, hvor de har ret. Hvis jeres team er lille, tæt koblet, juniort eller tre uger gammelt, tjener standuppen sandsynligvis sin pris ind, og det skal du sige.

---

Del 3: Skaf dine egne tal, før du åbner munden

To uger. Tre ting. Gør det før samtalen, for holdning mod ritual taber, og det gør et regnestykke mod ritual ikke.

Mål den rigtige længde, ikke den planlagte. Tag tid på den hver dag. De fleste teams opdager, at mødet på 15 minutter er et møde på 22 minutter.

Lav lønregnestykket. Antal deltagere gange den faktiske varighed i timer gange antal arbejdsdage på et år. Et team på otte med reelt 15 minutter er 2 persontimer om dagen, cirka 10 om ugen, omkring 460 persontimer om året. Med en fuldt belastet omkostning på 60 euro i timen er det omkring 27.000 euro, og det tal ser bort fra restitutionsomkostningen på begge sider. Brug jeres eget teams tal, så ingen kan diskutere forudsætningerne.

Tæl blokeringerne. Skriv i ti arbejdsdage hver eneste blokering ned, der bliver nævnt i standup, og markér, om den blev løst inde i mødet eller et andet sted bagefter. Det er som regel det tal, der afslutter diskussionen.

Spørg teamet anonymt. Ét spørgsmål. Hjælper standuppen dig med at lave dit arbejde, ja eller nej, og hvorfor. Anonymiteten er det, der giver dig det ægte svar, og den betyder også, at du taler på teamets vegne og ikke på dine egne, hvilket fjerner risiko to fra listen øverst.

---

Del 4: Formuleringerne

Fire situationer, fire manuskripter. Tilpas detaljerne, behold strukturen, for det er strukturen, der gør arbejdet.

De følger alle sammen de samme fire takter. Anerkend, hvad den anden faktisk har brug for. Sæt tal på prisen i deres sprog. Foreslå noget, der kan rulles tilbage og har en slutdato. Læg bevisbyrden og arbejdet med opsætningen på dig selv.

Til din leder, på en 1:1

“Jeg vil gerne beskytte teamets fokustid, uden at du mister overblikket, og jeg har to ugers tal på, hvordan vores standup faktisk bliver brugt. Den varer 22 minutter, ikke 15. Det er cirka 675 persontimer om året for os otte. På ti dage blev der nævnt seks blokeringer, og én af dem blev rent faktisk løst i mødet. Resten blev løst bagefter i DM’er.

Jeg vil gerne køre det her i fire uger. Skriftlige opdateringer i en fælles kanal inden 09.30, som du kan læse, når det passer dig, en dedikeret blokeringskanal, hvor folk tagger dig direkte i samme øjeblik noget går i stå, og én live sync om ugen. Jeg måler, hvor lang tid det tager at løse blokeringer, op mod det, vi har nu. Bliver det værre, går vi tilbage, og så siger jeg det i retroet. Jeg sætter det hele op.”

Til jeres scrum master

“Jeg har læst guiden fra 2020 igen. Den definerer Daily Scrum som en begivenhed for udviklerne, og den droppede de tre spørgsmål. Vores er drevet hen imod en runde opdateringer rettet mod den mest seniore i rummet, og det er præcis det, guiden prøver at forhindre.

Kunne vi prøve at køre den ud fra boardet i stedet for rundt i cirklen, en enkelt sprint, og bagefter spørge udviklerne, om den blev mere brugbar for dem?”

Læg mærke til, hvad det gør. Det giver dem frameworket som autoritet i stedet for dig, og det gør dem til den, der genopretter praksissen, i stedet for den, der forsvarer en ødelagt udgave af den.

Til dine kolleger, før du gør noget som helst andet

“Vær helt ærlig. Hjælper standup dig rent faktisk, eller er det bare noget, du kommer igennem? Jeg har lyst til at tage det op, og det vil jeg kun, hvis jeg taler på teamets vegne og ikke bare på mine egne.”

Gør det først. Altid. Hvis to siger, at standuppen er det eneste tidspunkt, hvor de får bedt om hjælp, skal dit forslag bevare det, og nu ved du det, før du har bundet dig til en holdning offentligt.

I et retrospektiv

“Jeg vil gerne inspicere én ting i dag. Jeg har fulgt vores standup i to uger. Her er, hvad den koster, og her er, hvor mange blokeringer den rent faktisk løste. Jeg beder ikke om, at vi aflyser den. Jeg spørger, om vi ændrer formatet en enkelt sprint og kigger på tallene, før vi beslutter noget permanent.”

Som et skriftligt forslag

Emne: Forsøg på fire uger, asynkron standup

Lige nu varer vores daglige standup 22 minutter for otte personer, og det er cirka 675 persontimer om året. Over de sidste ti arbejdsdage blev der nævnt seks blokeringer i den, og én blev løst inde i mødet.

Forslag, fire uger, kan rulles helt tilbage:

Skriftlige check ins i #team-standup inden 09.30, tre linjer hver. Fremdrift mod sprintmålet, fokus i dag, noget der er blokeret. Blokeringer tagges direkte til den relevante person i samme øjeblik de opstår, i stedet for at blive gemt til næste morgen. Én live sync på 30 minutter om mandagen til planlægning og alt det, der kræver en samtale.

Jeg måler tiden, det tager at løse blokeringer, cycle time og en kort teampuls, og tager alle tre med til retroet den [dato]. Bliver tiden til at løse blokeringer værre, ruller vi tilbage. Jeg sætter værktøjerne op og kører forsøget.

Den eksplicitte betingelse for at rulle tilbage er den vigtigste linje i den besked. Det er den, der forvandler dit forslag fra en ændring til en test, og det er som regel den, der henter ja’et hjem.

---

Del 5: Det, de siger tilbage

“Jeg har brug for at kunne se, hvad alle laver.” Skriftlige opdateringer giver dig mere, end et møde gør. De kan søges i, de bliver stående, og du kan læse dem klokken 07.00 eller 19.00 i stedet for at sidde i et rum klokken 09.30.

“Blokeringer bliver bare liggende.” Tværtimod. En blokering, der bliver lagt op i samme øjeblik den opstår, får opmærksomhed hurtigere end en, der bliver gemt til næste morgen. Det er præcis det mål, jeg foreslår vi følger, og det er det, der ville få mig til at aflyse forsøget.

“Det er kun femten minutter.” Det er femten minutter gange otte personer, hver eneste arbejdsdag, plus den tid hver enkelt skal bruge på at komme tilbage i det, de var i gang med. Her er tallet for et helt år.

“Scrum kræver et Daily Scrum.” Scrum kræver et Daily Scrum for udviklerne, og guiden fra 2020 fjernede de tre spørgsmål, vi stadig bruger. Det, vi kører, er ikke det, guiden beskriver.¹

“Teamet mister sammenhængskraften.” Det er en reel risiko, og det er derfor, den ugentlige sync bliver. Jeg måler også en teampuls undervejs i forsøget, så hvis sammenhængskraften falder, kan vi se det i stedet for at gætte om det.

---

Del 6: Fem måder folk taber den her diskussion på

At sætte det op som et ønske om at lave mindre. Det bekræfter præcis den mistanke, den anden kom ind ad døren med.

At dræbe mødet uden at pege på en erstatning. Rodet, der følger, bliver skrevet på din regning personligt, og det bør det.

At beslutte alene. Et teamritual ændrer sig som en teambeslutning, ellers er det tilbage inden for en måned.

At springe forsøget og målingerne over, hvilket forvandler et testbart forslag til en holdningskonkurrence mod status quo, og den slags vinder status quo.

At overse dem, den virker for. Hvis junioren på teamet læner sig op ad den, så design omkring vedkommende og sig det højt i rummet. Det koster dig ingenting, og det fjerner det stærkeste modargument, før nogen når at fremføre det.

---

Del 7: Hvad der erstatter den

Syv muligheder, hver med den ærlige ulempe klistret på.

Asynkrone skriftlige check ins via en bot. Geekbot, Standuply eller Range spørger hver enkelt og lægger svaret i en fælles kanal.¹⁷ Virker på tværs af tidszoner og efterlader en søgbar dokumentation. Kan forfalde til ulæst statusteater, hvis ingen reagerer på det, der bliver lagt op.

Standup to gange om ugen. Beholder den fælles live sync og skærer i frekvensen. Nem at sælge, fordi det er en lille ændring. Kræver en kanal ved siden af til alt, der haster.

Gå boardet igennem i stedet for cirklen. Gennemgå opgaverne fra højre mod venstre og tal om ticketsene i stedet for om personerne. Dræber den personlige rapporteringsdynamik med det samme. Virker kun, hvis boardet faktisk er opdateret.

En dedikeret kanal til blokeringer. Den enkeltdel med størst værdi og den billigste at tilføje. Kræver disciplin til at skrive i den og nogen, der holder øje med den.

Parprogrammering efter behov. Hurtigst mulige løsning, uden publikum. Giver mindre overblik for hele teamet, så det kræver et skriftligt spor.

Én dyb sync om ugen. Plads til de samtaler, et møde på 15 minutter ikke kan rumme. For sjælden til at stå alene.

Mødefri dage. Shopifys kalenderudrensning i 2023 er det mest citerede eksempel fra erhvervslivet, beskrevet som en oprydning, der fjernede tusindvis af tilbagevendende møder fra firmakalenderen.¹⁵ Det er en fokuspolitik og ikke en koordineringsmekanisme, så den skal kombineres med en af mulighederne ovenfor.

Den kombination, der oftest virker: skriftlige opdateringer til den daglige fornemmelse, en blokeringskanal til alt, der haster, og én live sync om ugen til resten.

---

Del 8: Design forsøget, så det overlever kontakten med et retro

Vælg dine succesmål, før du går i gang, og vælg nogle, din leder allerede tror på.

Levering. Ét mål i DORA-stil, som regel lead time for changes eller deployment frequency.¹² Cycle time fungerer, hvis I ikke deployer så tit.

Tid til at løse blokeringer. Din sikring mod hovedrisikoen. Det er det mål, der skal kunne dræbe forsøget, og det er, når du siger det højt, at forsøget bliver troværdigt.

Teampuls. Ét spørgsmål, ugentligt, anonymt. Det svarer til tilfredshedsdimensionen i SPACE-frameworket, som findes netop fordi produktivitetsmåling på ét enkelt tal går galt.¹¹ Uden den kan du forbedre gennemløbet, mens du stille og roligt brænder folk af, uden nogensinde at opdage det.

Fire uger er den rigtige længde. To er for kort til at se noget ud over nyhedsværdien. Otte er langt nok til, at det at rulle tilbage begynder at føles som en offentlig fiasko, og så forsvarer folk forsøget i stedet for at læse det ærligt.

---

Den del, der faktisk er svær

Alt det ovenfor er tilgængeligt for enhver, der bruger en eftermiddag på at læse. De fleste, der har brug for det, sender stadig ikke beskeden.

Det er ikke dokumentationen, der mangler. Det, der mangler, er en version af sætningen, der siger, at mødet ikke fungerer, uden at antyde, at den, der kører det, ikke fungerer, og det er meget sværere at skrive end en liste med kildehenvisninger. Den bliver skrevet om seks gange i et Slack-felt og så droppet.

Det hul er grunden til, at vi bygger Subtext. De fleste af de beskeder, folk ikke kan få sendt, er ikke komplicerede i indhold. Det er beskeder, hvor det ikke er nok at have ret, og hvor formuleringen bærer hele risikoen. Et standupforslag er en lille en af slagsen. Den samme form dukker op, når du beder om lønforhøjelse, siger fra over for mere arbejde, fortæller en founder, at roadmappet er forkert, eller siger nej til en ven.

Hvis du tager én ting med herfra: send beskeden med betingelsen for at rulle tilbage i. “Bliver tiden til at løse blokeringer værre, går vi tilbage, og det siger jeg selv højt.” Den ene sætning fjerner grunden til, at nogen skulle sige nej.

---

En note om de tal, jeg har udeladt

Flere tal cirkulerer bredt om det her emne, og jeg kunne ikke stå inde for dem, så de er ikke med i teksten ovenfor.

Påstanden om, at 80 % af udviklere angiver irrelevante opdateringer som deres største frustration ved standup, findes ikke i den Stray-undersøgelse, den plejer at blive tilskrevet. Påstanden om, at 80 % af mødernes action items aldrig bliver gennemført, rejser rundt uden kilde. Den ofte citerede statistik om “40 % længere og 50 % flere fejl”, der tilskrives et nyere studie i Journal of Experimental Psychology, ser ud til at være en forvansket udgave af Rubinstein, Meyer og Evans fra 2001, som målte opgaveskift i laboratoriet og ikke uden videre kan overføres til et formiddagsmøde.¹⁸ Diverse årlige kronebeløb per team for spildt mødetid afhænger fuldstændig af de antagelser, der ligger bag, og det er derfor, regnestykket i del 3 bruger jeres eget teams tal i stedet.

Endnu et ærligt hul. Jeg kunne ikke finde et stringent kontrolleret studie, der direkte sammenligner asynkrone skriftlige statusopdateringer med synkrone statusmøder målt på leveringsresultater. GitLab, Doist og Basecamp argumenterer alle for den skriftlige version, og alle tre har en position at forsvare. Hvis din leder beder om den sammenligning, er det rigtige svar, at den tilsyneladende ikke findes endnu, og at jeres forsøg på fire uger er måden, I selv skaber den på for jeres eget team.

---

Synes du, at jeres standup tjener sin pris ind, eller at jeg har læst dokumentationen forkert? Sig det til mig på LinkedIn.

Samet Durgun er medstifter af Subtext, en app der fanger den følelsesmæssige tone i dine beskeder og skriver dem om med dine egne ord. Han bor i Berlin.

---

Kilder

Hvert link ovenfor fører til den primære kilde, hvor der findes en.

1. The Scrum Guide (2020), Ken Schwaber and Jeff Sutherland, scrumguides.org. Det mest brugbare enkeltdokument til den her diskussion. Læs afsnittet om Daily Scrum direkte, og citér det ordret. Fastslår, at begivenheden er for udviklerne, varer 15 minutter, og at de tre spørgsmål blev fjernet i revisionen fra 2020.

2. 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. Fagfællebedømt. Dokumenterer både værdien (informationsdeling, fælles problemløsning) og fejlformerne (statusrapportering til en leder, for høj frekvens og for lang varighed). Send den her til en scrum master.

3. 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. Undersøgelse blandt professionelle udviklere. Blandt de rapporterede tal er 87 % af agile teams, der holder daglige standups, med gennemsnitlige vurderinger omkring neutral, juniorudviklere mere positive, seniorudviklere og større teams mindre. Jeg har brugt retningen i fundet frem for procenttallet.

4. Stray, V. and Moe, N. B., practitioner writing in IEEE Software on adapting daily stand-up practice. Argumenterer for, at stive standup-ritualer bør tilpasses teamet i stedet for at blive fulgt som standard. Den præcise titel og årstal er ubekræftede, og den version, der cirkulerer online, indeholder deltagerantal, jeg ikke kunne bekræfte.

5. 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. Oprindelsen til attention residue. Stærk dokumentation uden for agile-verdenen for, at opgaveskift forringer kvaliteten af det, der kommer bagefter.

6. Mark, G., Gudith, D., and Klocke, U. (2008). “The Cost of Interrupted Work: More Speed and Stress.” CHI 2008. Og Mark, G. (2023). Attention Span. Hanover Square Press. Kilden til fundene om afbrudt arbejde og til tallet på cirka 23 minutter, før man er tilbage i opgaven, som cirkulerer overalt. Tallet er reelt, men bliver ofte citeret med større præcision, end den underliggende forskning bærer, så citér primærarbejdet og formulér det som “over 20 minutter”.

7. Rogelberg, S. G. (2019). The Surprising Science of Meetings. Oxford University Press. Standardværket om mødespild og restitution efter møder. Jeg har brugt det kvalitative fund frem for en bestemt procent, fordi tallene varierer fra undersøgelse til undersøgelse.

8. Microsoft Human Factors Lab, EEG study on breaks between meetings, published via Microsoft WorkLab and the 2021 Work Trend Index. Fysiologisk dokumentation for, at stress hober sig op hen over møder i træk, og at pauser reducerer den. Brugbar, fordi det er måling og ikke spørgeskema.

9. Edmondson, A. (1999). “Psychological Safety and Learning Behavior in Work Teams.” Administrative Science Quarterly. Den grundlæggende kilde til psykologisk tryghed. Handler om teams generelt og ikke om standups specifikt, så påstå ikke en årsagssammenhæng, der ikke er der.

10. Rietze, S. and Zacher, H., research on daily stand-up meetings, psychological safety, work satisfaction and team performance perceptions, European Journal of Work and Organizational Psychology. Det stærkeste offentliggjorte argument for standups, og det er præcis derfor, du selv skal have det med. Udgivelsesåret er ubekræftet; den version, der cirkulerer, angiver 2025, hvilket jeg ikke kunne bekræfte.

11. Forsgren, N., Storey, M.-A., Maddila, C., Zimmermann, T., Houck, B., and Butler, J. (2021). “The SPACE of Developer Productivity.” ACM Queue. Frit tilgængelig. Brug dimensionen tilfredshed og trivsel til at begrunde, at du følger en teampuls ved siden af leveringsmålene.

12. Forsgren, N., Humble, J., and Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press. Kilden til de fire DORA-leveringsmål. Brug et af dem som dit gennemløbsmål, så målet kan forsvares i stedet for at være opfundet til lejligheden.

13. Graham, P. (2009). “Maker’s Schedule, Manager’s Schedule.” paulgraham.com/makersschedule.html. Kort, gratis og det mest overbevisende at sende videre til en kollega, der er i tvivl.

14. GitLab all remote handbook, about.gitlab.com/company/culture/all-remote. En stor organisation, der offentligt kører med asynkrone statusopdateringer. Bevis på, at modellen virker i stor skala, selvom GitLab har en interesse i argumentet.

15. Shopify calendar purge, January 2023, as reported by Bloomberg, Fortune and others. Beskrevet som en oprydning, der fjernede tusindvis af tilbagevendende møder fra firmakalenderen og forbød tilbagevendende møder med mere end to deltagere om onsdagen. Tallet for de genvundne timer kommer fra virksomheden selv, så tilskriv det Shopify frem for at fremstille det som en målt kendsgerning.

16. Atlassian Agile Coach, standup guidance. Branchevejledning, der anbefaler, at standups holdes korte og tilpasses teamets behov, inklusive asynkrone formater. Brugbar, fordi den kommer fra en kilde, din leder allerede stoler på, når det gælder agil praksis.

17. Tools: Geekbot og Standuply til asynkrone standups i Slack og Teams, Range til teamcheck ins. Bekræft aktuelle priser og produktstatus, før du anbefaler et af dem internt.

18. 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. Den faktiske oprindelse til påstanden om “op til 40 % af den produktive tid” på grund af opgaveskift. Nævnt her, så du selv kan tjekke det i stedet for at gentage den forvanskede udgave.