Alternative al daily standup: dati e frasi pronte

Qualcuno nel tuo team quel messaggio l’ha già scritto. Qualcosa tipo “secondo me il daily standup non ci sta funzionando”. Poi l’ha riletto, ha pensato a come sarebbe arrivato, l’ha cancellato ed è entrato in call.

È quella cancellazione il vero argomento di questo articolo. Le ricerche sugli standup non sono difficili da trovare e quasi tutte puntano nella stessa direzione. La parte difficile è la frase. Stai cercando di dire una cosa che porta con sé tre rischi sociali insieme, e tutti e tre ricadono su di te personalmente.

Rischio uno: sembri pigro. Qualsiasi richiesta di togliere una riunione si legge, di default, come una richiesta di essere controllato di meno.

Rischio due: sembri uno che non fa gioco di squadra. Lo standup viene presentato come la cosa che tiene tutti allineati. Contestarlo suona come contestare l’allineamento.

Rischio tre: stai attaccando una persona, non un processo. Quella riunione ha un proprietario. Uno scrum master, un manager, o chi l’ha messa in piedi due anni fa. Sentiranno una critica al rituale come una critica al loro giudizio, perché nella maggior parte delle stanze è esattamente così.

Così nessuno dice niente, e la riunione continua a esistere solo perché nessuno ha trovato le parole.

La buona notizia è che le parole esistono e non sono complicate. Vanno solo montate in un ordine preciso, e l’ordine conta più dei dati.

Il ribaltamento che vince la discussione

Non sostenere che lo standup è una perdita di tempo. Quell’argomento perde sempre, per i tre motivi qui sopra.

Sostieni invece che la versione che fa il tuo team non è la riunione che dovrebbe essere, e proponi un esperimento reversibile per sistemarla.

La Scrum Guide qui sta dalla tua parte, ed è la parte che quasi nessuno va a controllare. La Guida del 2020¹ definisce il Daily Scrum come un evento di 15 minuti per i Developer dello Scrum Team, per ispezionare il progresso verso lo Sprint Goal e adattare il piano. Non lo definisce come un report a un manager. La revisione del 2020 ha anche eliminato le tre domande prescritte che la maggior parte dei team continua a recitare ogni mattina.¹

Se il vostro standup gira come un cerchio di persone che raccontano ieri e oggi a chi ha più galloni nella stanza, tenendolo in piedi non state difendendo Scrum. State facendo una cosa che il regolamento ha già buttato via, e questo lo puoi dire ad alta voce senza accusare nessuno di niente.

La mossa è tutta qui. Non stai chiedendo meno responsabilità. Stai chiedendo di fare la riunione come la descrive il framework, e di verificare se un formato più economico regge.

Parte 1: Le ragioni che reggono a un esame serio

Ho tagliato parecchi dei numeri che circolano su questo tema. Alla fine c’è una nota che spiega quali e perché. Quello che segue è ciò che metterei davanti a un manager scettico.

1. È diventato un report di stato verso l’alto, che è proprio quello che il framework dice che non dovrebbe essere. Il modo di fallire meglio documentato. Lo studio di grounded theory di Stray, Sjøberg e Dingsøyr sui daily stand-up ha rilevato che i partecipanti li apprezzavano per la condivisione di informazioni e la risoluzione comune dei problemi, e reagivano male quando la riunione diventava un report di stato per un manager o quando era troppo frequente e troppo lunga.² La stessa cosa emerge nella letteratura per professionisti dello stesso gruppo di ricerca.⁴

2. Le tre domande producono narrazione invece che coordinamento. “Ieri ho lavorato sul ticket, oggi continuo sul ticket.” Nessuno chiede altro. Non cambia niente. Il formato premia una recita dell’attività invece di un’ispezione del progresso verso un obiettivo, ed è per questo che la Guida del 2020 ha eliminato le domande.¹

3. Gli ingegneri senior e i team grandi sono quelli che ne ricavano meno. Stray e colleghi hanno somministrato un questionario a sviluppatori professionisti e hanno trovato valutazioni concentrate intorno al neutro, con i junior più positivi e i senior e i membri dei team più grandi più propensi a vederci poco valore.³ Se le persone più esperte sono le meno coinvolte nella stanza, quello è un segnale sul formato, non su di loro.

4. Spacca la mattina. L’argomento di Paul Graham del 2009¹³ regge ancora. Chi costruisce cose ha bisogno di blocchi lunghi e senza interruzioni, e una sola riunione a metà mattina può rovinare tutta la mattina, tagliandola in due pezzi troppo piccoli per farci qualcosa di difficile. Uno standup alle 10:30 è l’esempio da manuale. E c’è anche un costo di attesa: nei 45 minuti prima nessuno inizia niente di impegnativo.

5. Cambiare attività peggiora il lavoro da entrambe le parti della riunione. La ricerca di Sophie Leroy ha introdotto il residuo attentivo: quando passi da un’attività a un’altra, una parte della tua attenzione resta indietro sulla prima e la tua performance sulla seconda ne risente.⁵ Uno standup impone quel passaggio due volte a ogni partecipante, una all’andata e una al ritorno.

6. Rientrare nel lavoro costa tempo vero. La ricerca di Gloria Mark sulle interruzioni è la fonte del dato citatissimo dei circa 23 minuti per tornare a un’attività interrotta, e il suo lavoro con Gudith e Klocke ha anche rilevato che le persone compensano le interruzioni lavorando più in fretta, al prezzo di più stress, più frustrazione e un carico di lavoro percepito più alto.⁶ Questo citalo con cura. È il numero più abusato di tutta la conversazione sulla produttività, e un manager che l’ha già visto smontare lo userà contro di te.

7. I blocker vengono nominati ma non risolti. Guarda se succede nel tuo team. Qualcuno dice che è bloccato, tutti annuiscono, e la risoluzione vera arriva quaranta minuti dopo in un DM tra due persone. Se il pattern è questo, la riunione non ha risolto il blocker. Ha solo fissato la conversazione che l’ha risolto.

8. Il carico di riunioni si accumula anche a livello fisiologico. Lo Human Factors Lab di Microsoft ha misurato con l’EEG persone impegnate in riunioni una dietro l’altra e ha visto i marcatori dello stress salire lungo la sequenza, con le pause brevi che riducevano quell’accumulo.⁸ Il lavoro di Steven Rogelberg sulla scienza delle riunioni documenta la stessa cosa dal lato dei sondaggi, insieme al tempo di recupero che le persone passano a decomprimere dopo una brutta riunione, che si somma alla durata della riunione stessa.⁷

9. Non funziona con i team distribuiti. C’è sempre qualcuno che se lo prende a un orario scomodo. Il manuale all remote di GitLab¹⁴ è l’argomentazione pubblica più completa a favore di gestire lo stato in asincrono, ed è un riferimento utile proprio perché arriva da un’azienda che lavora così su larga scala e non da un blog.

10. Una cadenza quotidiana fa pagare un prezzo quotidiano, che ci sia o meno qualcosa da coordinare. Nei team in cui il lavoro è poco accoppiato, il bisogno reale di coordinamento è intermittente. La riunione fissa paga troppo in ogni giornata tranquilla.

Parte 2: Le prove contrarie, che dovresti portare tu

Presentati con la tesi contro di te già montata. È la strada più rapida per essere preso sul serio, e impedisce al tuo manager di sentirsi costretto a difendere la riunione da solo.

Gli standup, fatti bene, fanno tre cose difficili da sostituire.

Fanno emergere presto i blocker. Un problema sollevato alle 09:30 che altrimenti si sarebbe mangiato una giornata intera vale da solo i quindici minuti. Questa è la funzione che il tuo sostituto deve assolutamente coprire.

Costruiscono un quadro condiviso di chi sta facendo cosa, e questo riduce il lavoro duplicato e in conflitto. Stray e Dingsøyr lo documentano come uno dei benefici reali che le persone riportano.²

Sostengono la sicurezza psicologica. Rietze e Zacher hanno trovato una relazione positiva tra i daily stand-up e la sicurezza psicologica, a sua volta collegata alla soddisfazione sul lavoro e alla percezione della performance del team.¹⁰ Il tutto si appoggia sul lavoro fondativo di Edmondson, che collega la sicurezza psicologica ai comportamenti di apprendimento del team.⁹ Un punto di contatto regolare e a bassa posta fa qualcosa per la fiducia, soprattutto nei team nuovi o distribuiti.

Quindi concedi il punto dove è vero. Se il tuo team è piccolo, molto accoppiato, junior, o esiste da tre settimane, probabilmente lo standup si sta ripagando e faresti bene a dirlo.

Parte 3: Procurati i tuoi dati prima di aprire bocca

Due settimane. Tre cose. Falle prima della conversazione, perché l’opinione contro il rituale perde e l’aritmetica contro il rituale no.

Misura la durata vera, non quella in calendario. Cronometrala ogni giorno. La maggior parte dei team scopre che la riunione da 15 minuti è una riunione da 22.

Fai il conto degli stipendi. Partecipanti, per la durata reale in ore, per i giorni lavorativi in un anno. Un team di otto persone a 15 minuti veri fa 2 ore persona al giorno, circa 10 a settimana, all’incirca 460 ore persona all’anno. A un costo pieno di 60 euro l’ora sono circa 27.000 euro, e quella cifra ignora il costo di recupero prima e dopo. Usa i numeri del tuo team, così nessuno può discutere sui dati di partenza.

Conta i blocker. Per dieci giorni lavorativi annota ogni blocker sollevato in standup, e segna se è stato risolto dentro la riunione o altrove, dopo. Di solito è questo il numero che chiude il dibattito.

Chiedi al team in forma anonima. Una domanda. Lo standup ti aiuta a fare il tuo lavoro, sì o no, e perché. È l’anonimato che ti dà la risposta vera, e vuol dire anche che stai parlando a nome del team e non tuo, il che toglie di mezzo il rischio due dell’elenco all’inizio.

Parte 4: Le parole

Quattro situazioni, quattro copioni. Adatta i dettagli, tieni la struttura, perché è la struttura a fare il lavoro.

Ognuno di questi segue gli stessi quattro tempi. Riconosci quello di cui l’altra persona ha davvero bisogno. Dai un nome al costo nei suoi termini. Proponi qualcosa di reversibile e con una scadenza. Prenditi addosso l’onere della prova e il lavoro di messa in piedi.

Al tuo manager, in un uno a uno

“Vorrei proteggere il tempo di concentrazione del team senza farti perdere visibilità, e ho due settimane di dati su come viene usato davvero il nostro standup. Dura 22 minuti, non 15. Sono circa 675 ore persona all’anno per noi otto. In dieci giorni sono stati sollevati sei blocker e uno solo è stato risolto davvero in riunione. Gli altri si sono risolti dopo, in DM.

Mi piacerebbe provare così per quattro settimane. Aggiornamenti scritti in un canale condiviso entro le 09:30, che puoi leggere quando ti pare, un canale dedicato ai blocker dove le persone ti taggano direttamente appena qualcosa si inceppa, e un sync dal vivo a settimana. Traccio il tempo di risoluzione dei blocker e lo confronto con quello di adesso. Se peggiora torniamo indietro, e lo dico io in retro. Metto in piedi tutto io.”

Al tuo scrum master

“Ho ripreso in mano la Guida del 2020. Definisce il Daily Scrum come un evento per i developer, e ha tolto le tre domande. Il nostro è scivolato in un giro di aggiornamenti rivolti a chi ha più galloni nella stanza, che è esattamente la cosa che la Guida cerca di evitare.

Possiamo provare a farlo sulla board invece che a giro, per uno sprint, e poi chiedere ai developer se per loro è diventato più utile?”

Nota cosa fa questo messaggio. Mette il framework come autorità al posto tuo, e rende l’altra persona quella che ripristina la pratica, invece di quella che difende una versione rotta.

Ai tuoi colleghi, prima di qualsiasi altra cosa

“Dimmelo onestamente. Lo standup ti serve davvero, o è solo una cosa che ti tocca sopportare? Vorrei sollevare la questione, ma lo faccio solo se sto parlando a nome del team e non solo per me.”

Fallo per primo. Sempre. Se due persone ti dicono che lo standup è l’unico momento in cui riescono a chiedere aiuto, la tua proposta deve tenere quella cosa, e adesso lo sai prima di aver preso posizione in pubblico.

In una retrospettiva

“Oggi vorrei ispezionare una cosa sola. Ho monitorato il nostro standup per due settimane. Ecco quanto costa, ed ecco quanti blocker ha risolto davvero. Non sto chiedendo di cancellarlo. Sto chiedendo se cambiamo formato per uno sprint e guardiamo i numeri prima di decidere qualcosa di definitivo.”

Come proposta scritta

Oggetto: Esperimento di quattro settimane, standup asincrono

Al momento il nostro standup quotidiano dura 22 minuti per otto persone, cioè circa 675 ore persona all’anno. Negli ultimi dieci giorni lavorativi ci sono stati sollevati sei blocker e uno è stato risolto dentro la riunione.

Proposta, quattro settimane, completamente reversibile:

Check-in scritti in #team-standup entro le 09:30, tre righe a testa. Progresso verso lo sprint goal, focus di oggi, cose bloccate. Blocker taggati direttamente alla persona giusta nel momento in cui compaiono, invece di tenerli fermi fino alla mattina dopo. Un sync dal vivo di 30 minuti il lunedì, per la pianificazione e per tutto quello che ha bisogno di una conversazione.

Traccio tempo di risoluzione dei blocker, cycle time e un breve polso del team, e porto tutti e tre alla retro del [data]. Se il tempo di risoluzione dei blocker peggiora, torniamo indietro. Configuro io gli strumenti e seguo io la prova.

La condizione esplicita di ritorno indietro è la riga più importante di quel messaggio. È quello che trasforma la tua proposta da un cambiamento a un test, ed è di solito quello che ti fa arrivare il sì.

Parte 5: Cosa ti risponderanno

“Mi serve visibilità su cosa sta facendo ognuno.” Gli aggiornamenti scritti ti danno più di una riunione. Sono ricercabili, restano, e puoi leggerli alle 07:00 o alle 19:00 invece di stare in una stanza alle 09:30.

“I blocker resteranno lì fermi.” Al contrario. Un blocker postato nel momento in cui compare riceve attenzione più in fretta di uno tenuto in caldo fino alla mattina dopo. È proprio la metrica che sto proponendo di monitorare, ed è quella che mi farebbe interrompere la prova.

“Sono solo quindici minuti.” Sono quindici minuti per otto persone, ogni giorno lavorativo, più il tempo che serve a ciascuno per rientrare in quello che stava facendo. Ecco il numero annuale.

“Scrum prevede il Daily Scrum.” Scrum prevede un Daily Scrum per i developer, e la Guida del 2020 ha tolto le tre domande che noi usiamo ancora. Quello che facciamo non è la cosa che descrive la Guida.¹

“Il team perderà coesione.” È un rischio reale, ed è per questo che il sync settimanale resta. Durante la prova monitoro anche un polso del team, così se la coesione cala lo vediamo invece di tirare a indovinare.

Parte 6: Cinque modi per perdere questa discussione

Presentarla come voglia di fare di meno. Conferma esattamente il sospetto con cui l’altra persona è entrata nella stanza.

Ammazzare la riunione senza nominare un sostituto. Il casino che segue verrà attribuito a te personalmente, ed è giusto così.

Decidere da solo. Un rituale di team si cambia con una decisione di team, altrimenti torna nel giro di un mese.

Saltare la prova e le metriche, il che trasforma una proposta verificabile in una gara di opinioni contro lo status quo, e quelle le vince lo status quo.

Ignorare le persone a cui serve. Se il junior del team ci si appoggia, progetta intorno a lui e dillo davanti a tutti. Non ti costa niente e toglie di mezzo l’obiezione più forte prima che qualcuno la sollevi.

Parte 7: Cosa lo sostituisce

	Standup quotidiano dal vivo	Aggiornamenti scritti in asincrono	Sync settimanale più canale blocker
Costo in tempo	Alto, cresce con il numero di persone	Costo sincrono quasi nullo	Basso
Costo di interruzione	Alto, ogni giorno, a metà mattina	Minimo, te lo pianifichi tu	Basso, un punto fisso
Velocità sui blocker	Fino a 24 ore di attesa	Immediata se tagghi	Immediata se tagghi
Traccia	Nessuna, se non la scrive qualcuno	Ricercabile di default	Parziale
Funziona tra fusi orari	Male	Bene	Discretamente
Coesione	Buona se gestito bene	Debole da sola	Buona

Sette opzioni, con lo svantaggio onesto attaccato a ciascuna.

Check-in scritti in asincrono con un bot. Geekbot, Standuply o Range fanno la domanda a ognuno e pubblicano su un canale condiviso.¹⁷ Funziona tra fusi orari diversi, lascia una traccia ricercabile. Può degenerare in teatrino di stato che nessuno legge, se nessuno risponde a quello che viene pubblicato.

Standup due volte a settimana. Tiene il sync dal vivo, taglia la frequenza. Facile da far passare perché è un cambiamento piccolo. Serve un canale di appoggio per le urgenze.

Giro sulla board invece che sulle persone. Passa in rassegna gli item da destra a sinistra e parla dei ticket invece che delle persone. Ammazza subito la dinamica del rapportino personale. Funziona solo se la board è davvero aggiornata.

Un canale dedicato ai blocker. Il pezzo con più valore in assoluto e il più economico da aggiungere. Richiede la disciplina di postare, e qualcuno che lo guardi.

Pairing su richiesta. Risoluzione più rapida possibile, senza pubblico. Riduce la visibilità su tutto il team, quindi ha bisogno di una traccia scritta.

Un sync settimanale approfondito. Spazio per le conversazioni che una riunione da 15 minuti non riesce a contenere. Troppo raro per funzionare da solo.

Giorni senza riunioni. La ripulita del calendario fatta da Shopify nel 2023 è l’esempio aziendale più citato, riportato come rimozione di migliaia di riunioni ricorrenti dal calendario dell’azienda.¹⁵ È una politica di focus più che un meccanismo di coordinamento, quindi va combinata con una delle voci qui sopra.

La combinazione che funziona più spesso: aggiornamenti scritti per la consapevolezza quotidiana, un canale blocker per le urgenze, un sync dal vivo a settimana per tutto il resto.

Parte 8: Progettare la prova perché sopravviva all’impatto con una retro

Scegli le metriche di successo prima di iniziare, e scegli quelle in cui il tuo manager già crede.

Consegna. Una misura in stile DORA, di solito lead time for changes o deployment frequency.¹² Il cycle time va bene se non rilasciate spesso.

Tempo di risoluzione dei blocker. La tua protezione sul rischio principale. È la metrica che deve poter uccidere l’esperimento, e dirlo ad alta voce è quello che rende credibile l’esperimento.

Polso del team. Una domanda, ogni settimana, anonima. Corrisponde alla dimensione della soddisfazione nel framework SPACE, che esiste proprio perché misurare la produttività con una metrica sola va a finire male.¹¹ Senza, puoi migliorare il throughput mentre bruci le persone in silenzio e non accorgertene mai.

Quattro settimane è la durata giusta. Due sono troppo poche per vedere qualcosa oltre l’effetto novità. Otto sono abbastanza da far sembrare il ritorno indietro un fallimento pubblico, e a quel punto le persone difendono la prova invece di leggerla con onestà.

La parte davvero difficile

Tutto quello che c’è qui sopra è alla portata di chiunque passi un pomeriggio a leggere. La maggior parte delle persone a cui serve comunque non manderà il messaggio.

Non sono le prove a mancare. Quello che manca è una versione della frase che dica che la riunione non funziona senza far intendere che la persona che la gestisce non funziona, e quella è molto più difficile da scrivere di un elenco di citazioni. Viene riscritta sei volte nella casella delle bozze di Slack, e poi abbandonata.

È quel vuoto il motivo per cui costruiamo Subtext. La maggior parte dei messaggi che le persone non riescono a mandare non sono complicati nel contenuto. Sono messaggi in cui avere ragione non basta, e sono le parole a portarsi addosso tutto il rischio. Una proposta sullo standup è uno dei casi piccoli. La stessa forma torna quando chiedi un aumento, quando rifiuti altro lavoro, quando dici a un founder che la roadmap è sbagliata, e quando dici di no a un amico.

Se ti porti via una cosa sola: manda il messaggio con dentro la condizione di ritorno indietro. “Se il tempo di risoluzione dei blocker peggiora, torniamo indietro e lo dico io.” Quella singola frase toglie il motivo che chiunque avrebbe avuto per dirti di no.

Una nota sui numeri che ho lasciato fuori

Su questo tema circolano parecchie cifre che non me la sono sentita di sostenere, quindi nel testo qui sopra non ci sono.

L’affermazione che l’80% degli sviluppatori indica gli aggiornamenti irrilevanti come la principale frustrazione dello standup non compare nel questionario di Stray a cui viene di solito attribuita. L’affermazione che l’80% delle azioni decise in riunione non viene mai completata gira senza fonte. La statistica citatissima del “40% di tempo in più e 50% di errori in più”, attribuita a un recente articolo del Journal of Experimental Psychology, sembra una versione storpiata di Rubinstein, Meyer ed Evans del 2001, che misurava il cambio di attività in laboratorio e non si estende così, di peso, a una riunione mattutina.¹⁸ Le varie cifre annuali per team sul tempo di riunione sprecato dipendono interamente dalle assunzioni che ci stanno dietro, ed è per questo che l’aritmetica della Parte 3 usa i dati del tuo team.

Un’ultima lacuna, detta con onestà. Non sono riuscito a trovare uno studio controllato rigoroso che confronti direttamente gli aggiornamenti di stato scritti in asincrono con le riunioni di stato sincrone, sui risultati di consegna. GitLab, Doist e Basecamp sostengono tutti la versione scritta, e tutti e tre hanno una posizione da difendere. Se il tuo manager chiede quel confronto, la risposta onesta è che a quanto pare non esiste ancora, e che la tua prova di quattro settimane è il modo di generarlo per il tuo team.

Pensi che il vostro standup si ripaghi, o che io abbia letto male le prove? Dimmelo su LinkedIn.

Samet Durgun è co-fondatore di Subtext, un’app che coglie il tono emotivo dei tuoi messaggi e li riscrive con la tua voce. Vive a Berlino.

Fonti

Ogni link qui sopra porta alla fonte primaria, dove esiste.

The Scrum Guide (2020), Ken Schwaber and Jeff Sutherland, scrumguides.org. Il documento più utile che esista per questa discussione. Leggi direttamente la sezione sul Daily Scrum e citala alla lettera. Stabilisce che l’evento è per i Developer, che dura 15 minuti, e che le tre domande sono state tolte nella revisione del 2020.
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. Con revisione paritaria. Documenta sia il valore (condivisione di informazioni, risoluzione comune dei problemi) sia i modi di fallire (report di stato a un manager, frequenza e durata eccessive). Questo mandalo a uno 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. Questionario a sviluppatori professionisti. Tra le cifre pubblicate c’è che l’87% dei team agile fa standup quotidiani, con valutazioni medie vicine al neutro, i junior più positivi, i senior e i team grandi meno. Ho usato la direzione del risultato e non la percentuale.
Stray, V. and Moe, N. B., practitioner writing in IEEE Software on adapting daily stand-up practice. Sostiene che i rituali rigidi dello standup andrebbero adattati al team invece che seguiti per default. Titolo e anno esatti non confermati, e la versione che circola online include numeri di partecipanti che non ho potuto confermare.
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. L’origine del residuo attentivo. Prove solide, fuori dal mondo agile, che cambiare attività degrada la qualità di quello che viene dopo.
Mark, G., Gudith, D., and Klocke, U. (2008). “The Cost of Interrupted Work: More Speed and Stress.” CHI 2008. E Mark, G. (2023). Attention Span. Hanover Square Press. Origine dei risultati sul lavoro interrotto e della cifra di circa 23 minuti per riprenderlo, che circola ovunque. La cifra è reale, ma viene citata con più precisione di quanta la ricerca di base ne regga, quindi cita il lavoro originale e formulala come “oltre 20 minuti”.
Rogelberg, S. G. (2019). The Surprising Science of Meetings. Oxford University Press. Il riferimento standard sullo spreco delle riunioni e sul recupero dopo. Ho usato il risultato qualitativo invece di una percentuale precisa, perché i numeri variano da sondaggio a sondaggio.
Microsoft Human Factors Lab, EEG study on breaks between meetings, published via Microsoft WorkLab and the 2021 Work Trend Index. Prove fisiologiche che lo stress si accumula lungo riunioni consecutive e che le pause lo riducono. Utile perché è misurazione e non sondaggio.
Edmondson, A. (1999). “Psychological Safety and Learning Behavior in Work Teams.” Administrative Science Quarterly. La citazione fondativa sulla sicurezza psicologica. Parla di team in generale e non di standup in particolare, quindi non attribuirle un nesso causale che non ha.
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. L’argomento pubblicato più forte a favore degli standup, che è esattamente il motivo per cui dovresti portarlo tu. Anno di pubblicazione non confermato; la versione che circola dà una data del 2025 che non ho potuto confermare.
Forsgren, N., Storey, M.-A., Maddila, C., Zimmermann, T., Houck, B., and Butler, J. (2021). “The SPACE of Developer Productivity.” ACM Queue. Liberamente leggibile. Usa la dimensione della soddisfazione e del benessere per giustificare il monitoraggio di un polso del team accanto alle metriche di consegna.
Forsgren, N., Humble, J., and Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press. Origine delle quattro metriche di consegna DORA. Usane una come misura di ritmo, così la metrica è difendibile e non inventata per l’occasione.
Graham, P. (2009). “Maker’s Schedule, Manager’s Schedule.” paulgraham.com/makersschedule.html. Corto, gratuito, e la cosa più convincente da inoltrare a un collega che non ha ancora deciso da che parte stare.
GitLab all remote handbook, about.gitlab.com/company/culture/all-remote. Una grande organizzazione che opera pubblicamente con aggiornamenti di stato asincroni. La prova che il modello funziona su larga scala, anche se GitLab ha un interesse in questa tesi.
Shopify calendar purge, January 2023, as reported by Bloomberg, Fortune and others. Riportato come rimozione di migliaia di riunioni ricorrenti dal calendario aziendale e divieto di riunioni ricorrenti con più di due persone il mercoledì. La cifra precisa delle ore recuperate arriva dall’azienda, quindi attribuiscila a Shopify invece di darla per fatto misurato.
Atlassian Agile Coach, standup guidance. Linee guida di settore che raccomandano di tenere gli standup brevi e di adattarli alle esigenze del team, formati asincroni compresi. Utile perché arriva da una fonte di cui il tuo manager già si fida in materia di pratica agile.
Strumenti: Geekbot e Standuply per gli standup asincroni su Slack e Teams, Range per i check-in di team. Verifica prezzo attuale e stato del prodotto prima di consigliarne uno internamente.
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. La vera origine dell’affermazione che il cambio di attività si porta via “fino al 40% del tempo produttivo”. Lo metto qui così puoi controllarlo tu invece di ripetere la versione storpiata.