La retrospettiva: l'action item che diventa un progetto

Narratore: Attenzione: questo podcast è prodotto con voci sintetiche. È venerdì pomeriggio, ore sedici e trenta. Il team è in call per la retrospettiva di fine sprint. Lo Scrum Master ha promesso che, con il nuovo formato, durerà quarantacinque minuti.

Scrum Master: Benvenuti alla retrospettiva! Oggi usiamo il nuovo formato: quattro fasi, post-it digitali, timer visibile a tutti. Prima cosa andata bene, poi cosa migliorare, poi azioni concrete, infine una regola di metallo. Si parte!

Junior Developer: Io parto con le cose da migliorare. Una: l'ambiente di test è giù tre volte questa settimana. Due: le priorità sono cambiate tre volte dentro lo stesso sprint. Tre: le review sono ferme da giorni e la release non esce.

Scrum Master: Ottimo materiale! Li trasformo subito in post-it digitali. Due problemi, tre problemi... perfetto. E tu, Senior, che dici?

Senior Developer: Lo dici perché l'archivio non lo hai ancora aperto. Diciamo che il miglioramento più concreto oggi sarebbe uscire dalla call prima delle diciotto.

Junior Developer: Posso aggiungerne un quarto? Ogni volta che l'ambiente cade, il workaround sta su un wiki di due anni fa, e un job riparte lo stesso. E nessuno sa chi l'ha messo lì.

Senior Developer: Una domanda. La retro di due sprint fa ha prodotto dodici action item. Dove sono?

Scrum Master: Sul board delle retrospettive, nella sezione archivio.

Senior Developer: L'archivio non è un registro delle azioni completate. È un cimitero. E c'è un'altra cosa: la retro prima di quella aveva risolto proprio il problema delle review. Lo avevamo scritto anche noi, in un post-it giallo.

Scrum Master: Il post-it giallo c'è ancora, l'ho verificato ieri. Ed è un punto interessante: il problema è documentato, la soluzione anche. Manca solo l'azione.

Junior Developer: Quindi l'abbiamo già risolta una volta. E adesso la stiamo risolvendo di nuovo. La cosa che migliora più velocemente è il post-it.

Scrum Master: Giusto! Proprio per questo il nuovo formato introduce la regola di metallo: ogni retro produce al massimo un'azione, la meno ambiziosa possibile. Piccola, immediata, misurabile. Adesso, però, passiamo alla fase degli stakeholder, e per questo oggi abbiamo un ospite.

Narratore: Entra il Product Owner. È stato convocato per portare nella retro il punto di vista del cliente.

Product Owner: Grazie per avermi convocato, ma prima di sentire il punto di vista del cliente devo chiedervi una cosa, perché il cliente me l'ha chiesta a me: queste azioni di miglioramento, quanto tempo ci metterebbero? Mi serve una stima, anche a voce, entro lunedì.

Junior Developer: Aspetta. Le azioni di miglioramento non esistono ancora. Come facciamo a stimare qualcosa che stiamo decidendo adesso?

Product Owner: Con una stima approssimativa. T-shirt size, come facciamo di solito. E se potete mandarmeli in backlog, meglio: così li porto alla call con gli stakeholder di martedì.

Junior Developer: Nel backlog però finirebbero in fondo, sotto le storie del cliente. Le azioni di miglioramento devono competere con le feature? E chi le prioritizza?

Senior Developer: Le prioritizza lo sprint. E lo sprint è già pieno.

Product Owner: Allora le metto in un backlog a parte, così non competono con nessuno. Un backlog di miglioramento, con la sua colonna di prioritizzati e la sua call di revisione.

Senior Developer: Quindi stiamo facendo un refinement dentro una retrospettiva.

Scrum Master: Direi di non usare la parola refinement, per non confondere il formato. Chiamiamola stima esplorativa. Veniamo alle azioni: qualcuno ha una proposta concreta?

Junior Developer: Io ce l'ho, ed è minima. Nessuno sa chi sono gli owner dei job legacy. Mezza pagina: un nome accanto a ogni job. La scrivo io, ci metto un pomeriggio. Fine dell'azione.

Senior Developer: Approvo. Alcuni di quei job li ho scritti io dieci anni fa, e anche io non ricordo chi sono gli owner. Compresi io.

Product Owner: Ottima idea, solo che allora io al cliente devo spiegare che un pomeriggio è diventato un progetto. Per farlo mi servono un titolo ufficiale e uno sponsor da citare.

Junior Developer: E lo sponsor chi è?

Scrum Master: Bellissima! Ed è talmente importante che merita di più di un'azione. La trasformo in iniziativa: board dedicata, uno sponsor, e una cadenza settimanale di verifica degli avanzamenti. La chiamo Progetto Owner — nome di lavorazione, we can improve.

Junior Developer: Ma era un pomeriggio. Ora board, sponsor e verifica settimanale... per mezza pagina.

Scrum Master: Tutto ciò che è importante va tracciato. Chi traccia il tracciamento lo capirà la retro dei processi. Ricapitolando: l'elenco finale è di nove azioni, una tematica per ciascuna. Ambienti, priorità, review, documentazione, onboarding, sicurezza, test, comunicazione e, ovviamente, il progetto Owner.

Senior Developer: Nove azioni. La regola di metallo era una.

Junior Developer: Una domanda sul regime speciale. Lo possiamo usare anche la prossima volta? Perché altrimenti la regola di metallo vale solo quando la retro va bene.

Product Owner: Da stakeholder apprezzo l'onestà, ma se posso: delle nove azioni al cliente interessano soprattutto le prime due. Le altre sono più... aziendali.

Scrum Master: La regola di metallo vale per le retro ordinarie. Questa è una retro di transizione al nuovo formato, quindi ha un regime speciale. E per decidere quali delle nove azioni prioritizzare, convoco una retro dedicata alle retro. Campo libero, mezza giornata, a gennaio.

Narratore: La retrospettiva si conclude dopo un'ora e dieci. Il timer visibile a tutti era impostato a quarantacinque minuti. Nessuno l'ha notato.

Narratore: Tre settimane dopo, il team è di nuovo nella stessa call. La retro delle retro ha prodotto il suo unico risultato: un documento condiviso che elenca le nove azioni, ancora tutte non iniziate.

Junior Developer: Ho letto il documento. La mezza pagina degli owner dei job è ancora vuota. Però nella board del progetto Owner ci sono già tre card di kickoff.

Senior Developer: Il kickoff è stato rinviato due volte. In attesa dell'allineamento. Che, sembra, sarà la retro di apertura.

Scrum Master: Ragazzi, il documento è un grande passo avanti: abbiamo piena visibilità su quello che non stiamo facendo. E ho un'idea per il prossimo sprint: inizieremo con una retro di apertura, per allinearci su cosa fare prima di fare. Sarà breve, ve lo prometto.

Senior Developer: Una retro prima dello sprint. Per decidere se fare la retro di fine sprint.

Junior Developer: Posso proporre già adesso l'azione? Un'ora sola, un pomeriggio, nessuna board. Lo dico prima che diventi un progetto.

Scrum Master: Proposta valida! La trascrivo subito come primo post-it della retro di apertura. Che, appunto, deciderà se e quando fare la retro di apertura.

Narratore: La call si chiude. Il documento condiviso delle nove azioni resta aperto nel browser di tutti. Nessuno lo chiude.