Lo standup: i quindici minuti che durano un'ora
Martedì mattina: il daily standup secondo la nuova formula dello Scrum Master dovrebbe durare quindici minuti, con tre domande canoniche e timer da due minuti a persona. Il Junior racconta il suo stato ma solleva un blocco reale del sistema, il Senior lo diagnostica rivelando un job legacy che conosce troppo bene, e l'aggiornamento diventa una sessione tecnica. Entra il Product Owner con una richiesta urgente del cliente e chiede una stima a voce, trasformando l'allineamento in un refinement improvvisato. Dopo un'ora lo Scrum Master propone una call di follow-up e una retrospettiva sugli standup troppo lunghi. La riunione si chiude con una nuova call ricorrente che avrà a sua volta il suo standup. Nessuno è rimasto in piedi.
Voci, personaggi e contenuti creativi generati con strumenti di intelligenza artificiale e approvati prima della pubblicazione.
Trascrizione
Narratore: Prima di iniziare, una precisazione: tutte le voci di questo podcast sono generate sinteticamente. Gli eventi, per quanto riguarda chi lavora nell'IT aziendale, potrebbero invece essere improvvisamente familiari.
Narratore: È martedì mattina. Il team si collega alla consueta call per l'allineamento quotidiano. Sono in dieci, seduti, dietro le proprie lavorazioni. In teoria, lo standup si fa in piedi. In teoria.
Junior Developer: Prima che si cominci, una domanda veloce: il timer lo gestisci tu o si autosponde da solo? Perché due minuti a persona, in dieci, fanno venti. E i saluti non li ho contati.
Senior Developer: Venti minuti. Poi il cliente scrive in chat e si arriva a quaranta. Sono otto anni che lo seguo: non serve il timer, serve il coraggio di riattaccare.
Scrum Master: Buongiorno team! Prima che qualcuno dica qualcosa: siamo quindici minuti, in piedi, come da manuale. E oggi ho una novità. Da questa settimana usiamo la formula ufficiale: tre domande canoniche. Cosa ho fatto ieri, cosa faccio oggi, cosa mi blocca. Nessun altro contenuto. E ognuno ha un timer personale di due minuti. Ho installato un timer apposta. È incluso anche un suono gentile quando il tempo scade.
Senior Developer: Non sono in piedi.
Scrum Master: In piedi è un concetto, Senior, è uno stato mentale di allineamento. Ci tengo alla disciplina: i temi lunghi non li trattiamo qui, li mettiamo in follow-up dopo la call. Giuro. Dai, partiamo da te, Junior. Il tuo stato.
Junior Developer: Ieri ho finito la verifica della funzione nuova, oggi faccio i test. Ma ho un blocco: quando salvo un ordine grande, il sistema resta appeso tre minuti e poi va avanti da solo. Qualcuno sa cosa c'è dietro? Io non trovo niente nella documentazione.
Scrum Master: Ottimo formato, Junior, brevissimo. Senti, il timer ti ha appena suonato il gong gentile, quindi il blocco lo prendiamo in follow-up, magari stasera dopo la...
Senior Developer: Aspetta. Lo conosco. È il job notturno che riprocessa gli ordini grandi in un file di appoggio, poi un altro processo lo rilegge. Tre minuti sono normali. Va tutto bene.
Junior Developer: E questo job dove è documentato? E chi è l'owner? Perché riprocessa gli ordini grandi invece di leggerli direttamente?
Senior Developer: Nessuna documentazione. Nessun owner: quello l'aveva scritto una persona uscita nel duemilaundici. E perché riprocessa? Perché nel 2013 il sistema non reggeva il volume. Era una soluzione temporanea.
Junior Developer: Se è temporaneo, quando lo togliamo?
Senior Developer: Fra poco.
Junior Developer: Ok, lo annoto comunque: serve un owner per il job e un piano per togliere il file di appoggio. Se aspetto che diventi urgente, lo diventerà lui per primo.
Scrum Master: Bellissima iniziativa, Junior, la trasformo subito in action item. Però la discutiamo nella retro, così non sforiamo oltre i nostri quindici minuti.
Narratore: Alla call si aggiunge il Product Owner, che aveva chiesto di esserci solo per ascoltare. La discussione tecnica, iniziata dopo il gong gentile, era nel suo ventunesimo minuto.
Product Owner: Scusate se intervengo, giusto mentre ascolto questo tema. Il cliente stamattina ha chiesto una cosa: vuole esportare gli ordini anche in un formato diverso, quello del loro gestore. Mi ha chiesto subito quanto ci vuole. C'è qualcuno qui che me lo dice a voce adesso? Una stima, anche approssimativa?
Senior Developer: Una stima a voce, senza aprire nulla, con il cliente in attesa di una mail. Ho visto nascere così almeno tre progetti che oggi chiamiamo legacy.
Product Owner: Lo so, lo so. Però se non do un numero entro oggi, domani il numero me lo danno loro. E quel numero sarà più basso.
Scrum Master: Ehm. Le stime non si fanno nello standup, sono un'attività di refinement. Nella formula delle tre domande canoniche non rientra. Però... il cliente è urgente?
Product Owner: Urgentissimo. Mi ha scritto alle nove e alle nove e dieci mi ha chiamato il commerciale. Se gli dico che servono due settimane di analisi, manda in crisi l'accordo di rinnovo. Dài, due minuti, tirate fuori un numero.
Senior Developer: Il formato del loro gestore è quello che nel duemiladodici eravamo in tre a dover supportare. L'avevamo tolto. Però se proprio... dipende da cosa tocca: se passa dallo stesso job di prima, tre giorni. Se tocca il flusso nuovo, tre settimane. E non lo sappiamo finché non apriamo il job.
Product Owner: Perfetto, quindi diciamo una settimana di media. Al cliente gli dico una settimana e mezza, così risulto prudente.
Senior Developer: Una settimana di media fra tre giorni e tre settimane. È la prima stima della mia vita che funziona solo in statistica.
Product Owner: Tranquillo, nel riepilogo scrivo da confermare. Poi lo confermiamo nel follow-up, dove peraltro discutiamo anche del job. Che tra l'altro... il file di appoggio esiste davvero, no?
Junior Developer: Ma nessuno ha stimato nulla. Abbiamo detto due numeri opposti e fatto la media. Questo finisce nel backlog come cosa già decisa?
Scrum Master: Ok. Ok. Fermiamo tutti un secondo. Siamo a... quasi un'ora. Erano quindici minuti. Io credo molto nel controllo, e controllando il timer ho scoperto che nessuno di noi è più in piedi. Propongo di chiudere qui e di fissare una call di follow-up dedicata ai temi emersi: il job legacy, la stima dell'export, e magari un mini-refinement. Poi, e questa è l'idea di cui vado più fiero, una retrospettiva su come rendere gli standup più brevi.
Senior Developer: Una riunione su come abbreviare la riunione. Ci avevo scommesso.
Junior Developer: Posso chiedere una cosa sulla retro? Chi la facilita? Perché se anche lì c'è un timer da due minuti a persona, prevedo già un follow-up del follow-up.
Scrum Master: Non una riunione, Senior. Un momento strutturato di miglioramento continuo. Con action item misurabili. E appena finisce il follow-up, vi giro io l'invito alla retro. Ho già creato la board.
Narratore: La call finisce. I temi irrisolti vanno in una nuova riunione ricorrente, ogni martedì. La riunione, per allinearsi prima di iniziare, avrà un suo standup di apertura di quindici minuti. Nessuno, in tutto questo, si è alzato dalla sedia.
Senior Developer: Martedì prossimo porto un cuscino sulla sedia. Per stare in piedi, concettualmente.