Du vet allerede at standupen ikke funker. Det vanskelige er å si det.

Noen på teamet ditt har allerede skrevet meldingen. Noe i retning av “Jeg tror ikke den daglige standupen funker for oss.” Så leste de den om igjen, tenkte over hvordan den ville lande, slettet den og ble med i møtet.

Den slettingen er det denne teksten egentlig handler om. Forskningen på standups er ikke vanskelig å finne, og det meste av den peker samme vei. Det vanskelige er setningen. Du prøver å si noe som bærer tre ulike sosiale risikoer på én gang, og alle tre henger på deg personlig.

Risiko én: du høres lat ut. Enhver forespørsel om å fjerne et møte leses i utgangspunktet som et ønske om mindre innsyn i hva du driver med.

Risiko to: du høres ut som en som ikke er lagspiller. Standupen presenteres som det som holder alle samkjørte. Å protestere mot den høres ut som å protestere mot å være samkjørt.

Risiko tre: du angriper en person, ikke en prosess. Noen eier det møtet. En scrum master, en leder, eller den som satte det opp for to år siden. De hører kritikk av ritualet som kritikk av sin egen dømmekraft, for i de fleste rom er det nettopp det det er.

Så folk sier ingenting, og møtet ruller videre utelukkende i kraft av at ingen har funnet ordene.

Den gode nyheten er at ordene finnes, og at de ikke er kompliserte. De må bare settes sammen i en bestemt rekkefølge, og rekkefølgen betyr mer enn dokumentasjonen gjør.

---

Omformuleringen som vinner diskusjonen

Ikke argumenter for at standupen er bortkastet tid. Det argumentet taper, hver eneste gang, av de tre grunnene over.

Argumenter i stedet for at versjonen teamet ditt kjører, ikke er det møtet det er ment å være, og tilby et forsøk som kan rulles tilbake, som løsningen.

Scrum Guide er på din side her, og det er den delen nesten ingen slår opp. Guiden fra 2020¹ definerer Daily Scrum som et 15 minutters arrangement for utviklerne i scrumteamet, der de inspiserer fremdriften mot sprintmålet og tilpasser planen. Den er ikke definert som en rapport til en leder. Revisjonen fra 2020 fjernet også de tre foreskrevne spørsmålene som de fleste team fortsatt ramser opp hver morgen.¹

Hvis standupen deres kjøres som en runde der folk rapporterer i går og i dag til den som er mest senior i rommet, forsvarer du ikke Scrum ved å beholde den. Du kjører noe regelboka selv har droppet, og det kan du si høyt uten å beskylde noen for noe.

Det er hele grepet. Du ber ikke om mindre ansvarlighet. Du ber om å kjøre møtet slik rammeverket beskriver det, og om å teste om et billigere format holder.

---

Del 1: Argumentene som tåler et nærmere blikk

Jeg har kuttet mange av tallene som sirkulerer om dette temaet. Det ligger en note til slutt om hvilke og hvorfor. Det som følger, er det jeg ville lagt foran en skeptisk leder.

1. Den har blitt en statusrapport oppover, og rammeverket sier selv at den ikke skal være det. Den best dokumenterte feilformen. Stray, Sjøberg og Dingsøyrs grounded theory-studie av daily stand-ups fant at deltakerne satte pris på dem som informasjonsdeling og felles problemløsning, og at de reagerte negativt når møtet ble til statusrapportering til en leder eller gikk for ofte og for lenge.² Det samme funnet dukker opp i praktikerlitteraturen fra den samme forskergruppen.⁴

2. De tre spørsmålene produserer fortelling i stedet for koordinering. “I går jobbet jeg med ticketen, i dag jobber jeg videre med ticketen.” Ingen spør videre. Ingenting endrer seg som følge av det. Formatet oppfordrer til en oppvisning i aktivitet framfor en inspeksjon av fremdrift mot et mål, og det er derfor guiden fra 2020 droppet spørsmålene.¹

3. Seniorutviklere og store team får minst ut av den. Stray og kollegene hennes spurte profesjonelle utviklere og fant vurderinger som samlet seg rundt nøytralt, der juniorutviklere var mer positive, og seniorutviklere og folk på større team oftere så lite verdi.³ Hvis de mest erfarne folkene dine er de minst engasjerte i rommet, sier det noe om formatet, ikke om dem.

4. Den deler formiddagen i to. Paul Grahams argument fra 2009¹³ holder fortsatt. Folk som lager ting, trenger lange sammenhengende blokker, og ett enkelt møte midt på formiddagen kan ødelegge hele formiddagen ved å skjære den i to biter som begge er for små til å gjøre vanskelig arbeid i. En standup klokka 10.30 er skoleeksemplet. Det finnes også en forventningskostnad. Folk unngår å begynne på noe dypt i de 45 minuttene før.

5. Å bytte oppgave forringer arbeidet på begge sider av møtet. Sophie Leroys forskning introduserte begrepet attention residue: når du bytter fra én oppgave til en annen, blir en del av oppmerksomheten din hengende igjen på den første, og du presterer dårligere på den andre.⁵ En standup tvinger fram det byttet to ganger for hver eneste deltaker, én gang inn og én gang ut.

6. Det tar ekte tid å komme tilbake i arbeidet. Gloria Marks forskning på avbrytelser er kilden til det mye siterte tallet på rundt 23 minutter før du er tilbake i en avbrutt oppgave, og arbeidet hennes med Gudith og Klocke fant også at folk kompenserer for avbrytelser ved å jobbe raskere, mot mer stress, frustrasjon og opplevd arbeidsbelastning.⁶ Siter dette tallet forsiktig. Det er det mest misbrukte tallet i hele produktivitetssamtalen, og en leder som har sett det plukket fra hverandre, vil bruke det mot deg.

7. Blokkeringer blir nevnt, men ikke løst. Se etter dette i ditt eget team. Noen sier de står fast, alle nikker, og den faktiske løsningen skjer førti minutter senere i en DM mellom to personer. Er det mønsteret, løste ikke møtet blokkeringen. Det satte bare av tid til samtalen som gjorde det.

8. Møtebelastning hoper seg opp fysiologisk. Microsofts Human Factors Lab kjørte EEG på deltakere i møter på rad og fant stressmarkører som bygget seg opp gjennom rekken, der korte pauser dempet oppbyggingen.⁸ Steven Rogelbergs møteforskning dokumenterer det samme fra spørreundersøkelsessiden, sammen med restitusjonstiden folk bruker på å hente seg inn etter et dårlig møte, og den kommer på toppen av møtets egen lengde.⁷

9. Den passer ikke for distribuerte team. Det er alltid noen som tar den på et ubekvemt tidspunkt. GitLabs all remote-håndbok¹⁴ er det mest gjennomførte offentlige argumentet for å håndtere status asynkront i stedet, og den er nyttig nettopp fordi den kommer fra et selskap som jobber sånn i stor skala, og ikke fra en blogg.

10. En daglig kadens koster hver dag, uansett om det er noe å koordinere. På team der arbeidet er løst koblet, er det reelle koordineringsbehovet sporadisk. Det faste møtet betaler overpris hver eneste stille dag.

---

Del 2: Motargumentene, som du selv bør ta med

Gå inn med saken mot deg selv allerede lagt fram. Det er den raskeste veien til å bli tatt på alvor, og det fjerner følelsen lederen din ellers får av å stå alene om å forsvare møtet.

Standups som kjøres godt, gjør tre ting som er vanskelige å erstatte.

De får blokkeringer opp tidlig. Et problem som nevnes 09.30, og som ellers ville spist en hel dag, er verdt de femten minuttene helt på egen hånd. Dette er funksjonen erstatningen din absolutt må dekke.

De bygger et felles bilde av hvem som gjør hva, og det reduserer dobbeltarbeid og arbeid som motarbeider hverandre. Stray og Dingsøyr dokumenterer dette som en av de reelle fordelene folk rapporterer.²

De støtter psykologisk trygghet. Rietze og Zacher fant en positiv sammenheng mellom daglige stand-up-møter og psykologisk trygghet, som igjen hang sammen med arbeidsglede og opplevelsen av hvordan teamet presterer.¹⁰ Det ligger på toppen av Edmondsons grunnleggende arbeid som knytter psykologisk trygghet til læringsatferd i team.⁹ Et fast møtepunkt med lav innsats gjør noe med tilliten, særlig på nye eller distribuerte team.

Så gi dem rett der de har rett. Er teamet ditt lite, tett koblet, ferskt eller tre uker gammelt, tjener standupen sannsynligvis inn det den koster, og det bør du si.

---

Del 3: Skaff dine egne tall før du åpner munnen

To uker. Tre ting. Gjør det før samtalen, for mening mot ritual taper, og regnestykke mot ritual gjør ikke det.

Mål den faktiske lengden, ikke den planlagte. Ta tiden hver dag. De fleste team oppdager at 15-minuttersmøtet er et 22-minuttersmøte.

Gjør lønnsregnestykket. Antall deltakere ganget med faktisk varighet i timer, ganget med antall arbeidsdager i året. Et team på åtte med reelle 15 minutter er 2 persontimer om dagen, rundt 10 i uka, cirka 460 persontimer i året. Med en fullt belastet kostnad på 60 euro timen blir det rundt 27 000 euro, og det tallet ser bort fra restitusjonskostnaden på hver side. Bruk teamets egne tall, så ingen kan diskutere forutsetningene.

Tell blokkeringene. I ti arbeidsdager skriver du ned hver eneste blokkering som nevnes i standup, og markerer om den ble løst inne i møtet eller et annet sted etterpå. Det er som regel dette tallet som avslutter diskusjonen.

Spør teamet anonymt. Ett spørsmål. Hjelper standupen deg med å gjøre jobben din, ja eller nei, og hvorfor. Anonymiteten er det som gir deg det ekte svaret, og den betyr også at du snakker på vegne av teamet og ikke på vegne av deg selv, noe som fjerner risiko to fra lista øverst.

---

Del 4: Formuleringene

Fire situasjoner, fire manus. Tilpass detaljene, behold strukturen, for det er strukturen som gjør jobben.

Alle sammen følger de samme fire trinnene. Anerkjenn det den andre faktisk trenger. Sett tall på kostnaden i deres eget språk. Foreslå noe som kan rulles tilbake og har en sluttdato. Legg bevisbyrden og oppsettsjobben på deg selv.

Til lederen din, på en 1:1

“Jeg vil gjerne beskytte fokustiden til teamet uten at du mister oversikten, og jeg har to ukers tall på hvordan standupen vår faktisk brukes. Den varer 22 minutter, ikke 15. Det er rundt 675 persontimer i året for oss åtte. På ti dager ble det nevnt seks blokkeringer, og én av dem ble faktisk løst i møtet. Resten ble løst etterpå i DM-er.

Jeg har lyst til å kjøre dette i fire uker. Skriftlige oppdateringer i en felles kanal innen 09.30, som du kan lese når det passer deg, en egen blokkeringskanal der folk tagger deg direkte i det øyeblikket noe står fast, og én live-sync i uka. Jeg måler hvor lang tid det tar å løse blokkeringer, opp mot slik det er nå. Blir det verre, går vi tilbake, og da sier jeg det i retroen. Jeg setter opp alt sammen.”

Til scrum masteren din

“Jeg har lest guiden fra 2020 igjen. Den definerer Daily Scrum som et arrangement for utviklerne, og den droppet de tre spørsmålene. Vår har glidd over i en runde med oppdateringer rettet mot den som er mest senior i rommet, og det er akkurat det guiden prøver å hindre.

Kan vi prøve å kjøre den ut fra tavla i stedet for runden rundt bordet, i én sprint, og spørre utviklerne etterpå om den ble mer nyttig for dem?”

Legg merke til hva dette gjør. Det gir dem rammeverket som autoritet i stedet for deg, og det gjør dem til den som gjenoppretter praksisen i stedet for den som forsvarer en ødelagt versjon av den.

Til kollegene dine, før du gjør noe som helst annet

“Vær ærlig med meg. Hjelper standupen deg faktisk, eller er det bare noe du kommer deg gjennom? Jeg har lyst til å ta det opp, men bare hvis jeg snakker på vegne av teamet og ikke bare meg selv.”

Gjør dette først. Alltid. Hvis to personer sier at standupen er det eneste tidspunktet de får bedt om hjelp, må forslaget ditt ta vare på det, og nå vet du det før du har låst deg til et standpunkt offentlig.

I en retro

“Jeg vil inspisere én ting i dag. Jeg har målt standupen vår i to uker. Her er hva den koster, og her er hvor mange blokkeringer den faktisk løste. Jeg ber ikke om at vi avlyser den. Jeg spør om vi kan endre formatet i én sprint og se på tallene før vi bestemmer noe permanent.”

Som et skriftlig forslag

Emne: Fire ukers forsøk, asynkron standup

Slik det er nå, varer den daglige standupen vår 22 minutter med åtte personer, som er rundt 675 persontimer i året. De siste ti arbeidsdagene ble det nevnt seks blokkeringer i den, og én ble løst inne i møtet.

Forslag, fire uker, kan rulles helt tilbake:

Skriftlige innsjekker i #team-standup innen 09.30, tre linjer hver. Fremdrift mot sprintmålet, fokus for i dag, alt som står fast. Blokkeringer tagges direkte til rett person i det øyeblikket de dukker opp, i stedet for å ligge til neste morgen. Én live-sync på 30 minutter på mandag til planlegging og alt som trenger en samtale.

Jeg måler tid til løsning på blokkeringer, ledetid og en kort teampuls, og tar med alle tre til retroen den [dato]. Blir tiden til å løse blokkeringer verre, ruller vi tilbake. Jeg setter opp verktøyene og kjører forsøket.

Den eksplisitte betingelsen om å rulle tilbake er den viktigste linja i den meldingen. Det er den som gjør forslaget ditt om fra en endring til en test, og det er som regel den som gir deg ja-et.

---

Del 5: Hva de kommer til å svare

“Jeg trenger oversikt over hva alle holder på med.” Skriftlige oppdateringer gir deg mer enn et møte gjør. De er søkbare, de blir liggende, og du kan lese dem 07.00 eller 19.00 i stedet for å sitte i et rom 09.30.

“Blokkeringer kommer bare til å bli liggende.” Tvert imot. En blokkering som legges ut i det øyeblikket den dukker opp, får oppmerksomhet raskere enn en som spares til neste morgen. Det er akkurat den målingen jeg foreslår at vi følger, og det er den som ville fått meg til å avbryte forsøket.

“Det er jo bare femten minutter.” Det er femten minutter ganger åtte personer, hver eneste arbeidsdag, pluss tiden hver enkelt trenger for å komme tilbake i det de holdt på med. Her er tallet for et helt år.

“Scrum krever en Daily Scrum.” Scrum krever en Daily Scrum for utviklerne, og guiden fra 2020 fjernet de tre spørsmålene vi fortsatt bruker. Det vi kjører, er ikke det guiden beskriver.¹

“Teamet mister samholdet.” Det er en reell risiko, og det er derfor den ukentlige synken blir stående. Jeg måler også en teampuls gjennom forsøket, så hvis samholdet faller, ser vi det i stedet for å gjette.

---

Del 6: Fem måter folk taper denne diskusjonen på

Å ramme det inn som at du vil gjøre mindre. Det bekrefter nøyaktig den mistanken den andre kom inn med.

Å drepe møtet uten å peke på en erstatning. Rotet som følger, blir tilskrevet deg personlig, og det bør det.

Å bestemme alene. Et teamritual endres som en teambeslutning, ellers er det tilbake innen en måned.

Å hoppe over forsøket og målingene, som gjør et testbart forslag om til en meningskonkurranse mot status quo, og den konkurransen vinner status quo.

Å overse dem den faktisk funker for. Hvis junioren på teamet er avhengig av den, design rundt vedkommende og si det høyt i rommet. Det koster deg ingenting, og det fjerner den sterkeste innvendingen før noen rekker å komme med den.

---

Del 7: Hva som erstatter den

Sju alternativer, med den ærlige baksiden festet til hvert av dem.

Asynkrone skriftlige innsjekker via en bot. Geekbot, Standuply eller Range spør hver enkelt og legger svarene i en felles kanal.¹⁷ Funker på tvers av tidssoner og etterlater et søkbart spor. Kan forfalle til ulest statusteater hvis ingen svarer på det som legges ut.

Standup to ganger i uka. Beholder live-synken, kutter frekvensen. Enkel å selge inn fordi det er en liten endring. Trenger en kanal ved siden av til alt som haster.

Gå gjennom tavla i stedet for runden. Ta oppgavene fra høyre mot venstre og snakk om ticketene i stedet for om folkene. Dreper den personlige rapporteringsdynamikken med en gang. Funker bare hvis tavla faktisk er oppdatert.

En egen blokkeringskanal. Den enkeltdelen som gir mest verdi, og den billigste å legge til. Krever disiplin til å poste, og at noen faktisk følger med.

Parring ved behov. Raskest mulig løsning, uten publikum. Reduserer oversikten for hele teamet, så det trenger et skriftlig spor.

Én grundig sync i uka. Plass til samtalene et 15-minuttersmøte ikke rommer. For sjelden til å funke alene.

Møtefrie dager. Shopifys kalenderrydding i 2023 er det mest siterte eksempelet fra næringslivet, omtalt som at tusenvis av gjentakende møter ble fjernet fra selskapets kalender.¹⁵ Dette er en fokuspolicy og ikke en koordineringsmekanisme, så den må kombineres med et av punktene over.

Kombinasjonen som funker oftest: skriftlige oppdateringer for daglig oversikt, en blokkeringskanal for alt som haster, og én live-sync i uka til resten.

---

Del 8: Å designe forsøket så det overlever møtet med en retro

Velg suksessmålene før du starter, og velg noen lederen din allerede tror på.

Leveranse. Ett mål av DORA-typen, som regel ledetid for endringer eller deployfrekvens.¹² Syklustid funker hvis dere ikke deployer ofte.

Tid til å løse blokkeringer. Sikringen din på hovedrisikoen. Dette er målingen som skal kunne drepe forsøket, og at du sier det høyt, er det som gjør forsøket troverdig.

Teampuls. Ett spørsmål, ukentlig, anonymt. Det treffer tilfredshetsdimensjonen i SPACE-rammeverket, som finnes nettopp fordi produktivitetsmåling med ett enkelt tall går galt.¹¹ Uten den kan du øke gjennomstrømmingen mens du stille brenner ut folk, og aldri legge merke til det.

Fire uker er riktig lengde. To er for kort til å se noe forbi nyhetseffekten. Åtte er langt nok til at det å rulle tilbake begynner å føles som et offentlig nederlag, og da forsvarer folk forsøket i stedet for å lese det ærlig.

---

Den delen som faktisk er vanskelig

Alt over ligger tilgjengelig for hvem som helst som bruker en ettermiddag på å lese. De fleste som trenger det, kommer likevel ikke til å sende meldingen.

Det er ikke dokumentasjonen som mangler. Det som mangler, er en versjon av setningen som sier at møtet ikke funker, uten å antyde at personen som kjører det, ikke funker, og det er mye vanskeligere å skrive enn en kildeliste. Den blir skrevet om seks ganger i et Slack-felt og så forlatt.

Det gapet er grunnen til at vi bygger Subtext. De fleste meldingene folk ikke får sendt, er ikke kompliserte i innhold. Det er meldinger der det ikke holder å ha rett, og der formuleringen bærer hele risikoen. Et standup-forslag er en liten en. Den samme formen dukker opp når du skal be om lønnsøkning, si nei til mer scope, fortelle en gründer at veikartet er feil, eller si nei til en venn.

Hvis du tar med deg én ting herfra: send meldingen med betingelsen om å rulle tilbake i. “Blir tiden til å løse blokkeringer verre, går vi tilbake, og da sier jeg det.” Den ene setningen fjerner grunnen noen hadde til å si nei.

---

En note om tallene jeg utelot

Flere tall sirkulerer bredt om dette temaet uten at jeg kunne stå inne for dem, så de er ikke med i teksten over.

Påstanden om at 80 % av utviklere oppgir irrelevante oppdateringer som sin største frustrasjon ved standup, finnes ikke i Stray-undersøkelsen den vanligvis tilskrives. Påstanden om at 80 % av tiltakene fra møter aldri blir gjennomført, reiser rundt uten kilde. Den ofte siterte statistikken om “40 % lengre og 50 % flere feil”, som tilskrives en fersk artikkel i Journal of Experimental Psychology, ser ut til å være en forvrengt versjon av Rubinstein, Meyer og Evans fra 2001, som målte oppgavebytte i lab og ikke uten videre kan overføres til et formiddagsmøte.¹⁸ Ulike årlige beløp per team for bortkastet møtetid avhenger fullstendig av forutsetningene som ligger bak, og det er derfor regnestykket i del 3 heller bruker teamets egne tall.

Ett ærlig hull til. Jeg fant ingen streng, kontrollert studie som direkte sammenligner asynkrone skriftlige statusoppdateringer med synkrone statusmøter målt på leveranse. GitLab, Doist og Basecamp argumenterer alle for den skriftlige varianten, og alle tre har en posisjon å forsvare. Spør lederen din etter den sammenligningen, er det riktige svaret at den ikke ser ut til å finnes ennå, og at det fire uker lange forsøket ditt er måten dere lager den på for deres eget team.

---

Mener du at standupen deres er verdt det den koster, eller at jeg har lest dokumentasjonen feil? Si det til meg på LinkedIn.

Samet Durgun er medgründer av Subtext, en app som fanger opp den følelsesmessige tonen i meldingene dine og skriver dem om med dine egne ord. Han bor i Berlin.

---

Kilder

Hver lenke over går til primærkilden der det finnes en.

1. The Scrum Guide (2020), Ken Schwaber and Jeff Sutherland, scrumguides.org. Det enkeltdokumentet som er mest nyttig i denne diskusjonen. Les avsnittet om Daily Scrum direkte, og siter det ordrett. Slår fast at arrangementet er for utviklerne, varer 15 minutter, og at de tre spørsmålene ble fjernet i revisjonen 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. Fagfellevurdert. Dokumenterer både verdien (informasjonsdeling, felles problemløsning) og feilformene (statusrapportering til en leder, for høy frekvens og for lang varighet). Send denne 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økelse blant profesjonelle utviklere. Blant tallene som rapporteres, er 87 % av smidige team som holder daglige standups, med gjennomsnittsvurderinger rundt nøytralt, juniorutviklere mer positive, seniorutviklere og større team mindre. Jeg har brukt retningen i funnet framfor prosenttallet.

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 å følges som standard. Nøyaktig tittel og årstall er ubekreftet, og versjonen som sirkulerer på nett, inneholder deltakerantall jeg ikke fikk bekreftet.

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. Opphavet til attention residue. Sterk dokumentasjon utenfor smidigverdenen for at oppgavebytte forringer kvaliteten på det som kommer etterpå.

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 funnene om avbrutt arbeid og til tallet på rundt 23 minutter før du er tilbake i oppgaven, som sirkulerer overalt. Tallet er reelt, men blir ofte sitert med større presisjon enn forskningen bak bærer, så siter primærarbeidet og formuler det som “over 20 minutter”.

7. Rogelberg, S. G. (2019). The Surprising Science of Meetings. Oxford University Press. Standardverket om møtesløsing og restitusjon etter møter. Jeg har brukt det kvalitative funnet framfor en bestemt prosent, fordi tallene varierer fra undersøkelse til undersøkelse.

8. Microsoft Human Factors Lab, EEG study on breaks between meetings, published via Microsoft WorkLab and the 2021 Work Trend Index. Fysiologisk dokumentasjon for at stress hoper seg opp gjennom møter på rad, og at pauser demper det. Nyttig fordi det er måling og ikke spørreundersøkelse.

9. Edmondson, A. (1999). “Psychological Safety and Learning Behavior in Work Teams.” Administrative Science Quarterly. Den grunnleggende kilden om psykologisk trygghet. Handler om team generelt og ikke om standups spesifikt, så ikke påstå en årsakssammenheng som 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 sterkeste publiserte argumentet for standups, og det er nettopp derfor du bør ta det med selv. Utgivelsesåret er ubekreftet; versjonen som sirkulerer oppgir 2025, noe jeg ikke fikk uavhengig bekreftet.

11. Forsgren, N., Storey, M.-A., Maddila, C., Zimmermann, T., Houck, B., and Butler, J. (2021). “The SPACE of Developer Productivity.” ACM Queue. Fritt tilgjengelig. Bruk dimensjonen tilfredshet og trivsel til å begrunne at du følger en teampuls ved siden av leveransemå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-leveransemålene. Bruk ett av dem som gjennomstrømmingsmålet ditt, så målet kan forsvares i stedet for å være funnet opp for anledningen.

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

14. GitLab all remote handbook, about.gitlab.com/company/culture/all-remote. En stor organisasjon som offentlig kjører med asynkrone statusoppdateringer. Bevis på at modellen funker i stor skala, selv om GitLab har en interesse i argumentet.

15. Shopify calendar purge, January 2023, as reported by Bloomberg, Fortune and others. Omtalt som en opprydding som fjernet tusenvis av gjentakende møter fra firmakalenderen og forbød gjentakende møter med mer enn to deltakere på onsdager. Tallet for gjenvunne timer kommer fra selskapet selv, så tilskriv det Shopify i stedet for å presentere det som en målt kjensgjerning.

16. Atlassian Agile Coach, standup guidance. Bransjeveiledning som anbefaler at standups holdes korte og tilpasses teamets behov, inkludert asynkrone formater. Nyttig fordi den kommer fra en kilde lederen din allerede stoler på når det gjelder smidig praksis.

17. Verktøy: Geekbot og Standuply til asynkrone standups i Slack og Teams, Range til teaminnsjekker. Bekreft dagens priser og produktstatus før du anbefaler et av 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. Det faktiske opphavet til påstanden om “opptil 40 % av den produktive tiden” på grunn av oppgavebytte. Nevnt her så du kan sjekke det selv i stedet for å gjenta den forvrengte versjonen.