La riunione c'è stata. Che cosa abbiamo visto?

C'è una domanda che gira nei gruppi più di quanto ammettiamo: «abbiamo fatto la call?». Sembra innocua, quasi diligente. Eppure, quando diventa la misura del nostro lavoro, è il segnale che qualcosa si è già spostato. La domanda utile non è se la call si è tenuta. È un'altra, e costa molto di più: che cosa è diventato visibile grazie a quella call? Le due si somigliano soltanto finché non provi a rispondere alla seconda davanti a qualcuno.

Mettiamola così. Un'organizzazione può prendere in prestito tutto l'apparato di Scrum. I ruoli: il product owner, che decide che cosa vale la pena fare; lo scrum master, che aiuta il gruppo a lavorare meglio; gli sviluppatori. Gli eventi: la pianificazione, la review, la retrospettiva, il refinement, cioè il lavoro di chiarire le voci prima che entrino in un ciclo. Il vocabolario, con i suoi incrementi e i suoi backlog. E può continuare a funzionare esattamente come prima. Stesso controllo dall'alto, stesse deleghe mai dichiarate. Stessi problemi risolti in privato fra due persone, fuori dalla stanza. La forma c'è tutta. La sostanza non si è mossa di un centimetro.

Che cosa dovrebbe far emergere

Per me è qui che sta il fraintendimento più costoso. Scrum non è un insieme di riunioni da spuntare. È un modo per rendere leggibile un sistema di lavoro. Dovrebbe far venire fuori cinque cose. Com'è messo il prodotto. Chi ha in mano che cosa. Quali risposte arrivano da chi lo usa. Quali decisioni prendiamo, e dove passano i confini fra le persone. Se dopo tre mesi di eventi puntuali quelle cinque cose non sono più chiare, non è che ci manchi ortodossia. È il rito che sta girando a vuoto.

La guida di Scrum, del resto, appoggia tutto su tre pilastri: trasparenza, ispezione, adattamento. Senza trasparenza non c'è niente da ispezionare. Senza ispezione non si adatta niente. Gli eventi esistono per tenere in piedi questi tre, non per riempire un calendario. È una cosa che si dimentica in fretta, e c'è un motivo: il calendario si vede, i tre pilastri no.

Il rischio non è l'assenza di Scrum, è lo Scrum che copre

Un rituale ha una qualità scomoda: rassicura. Se il calendario è pieno di eventi con il nome giusto, tutti possono dirsi tranquilli. Stiamo facendo agile. Il refinement è al suo posto, la retrospettiva pure. Eppure una retrospettiva può benissimo essere il luogo in cui non si decide niente. E il refinement può diventare un aggiornamento di stato travestito da confronto. Quando succede, la cerimonia smette di essere una lente e diventa una tenda. Copre. Ci fa sentire allineati senza che il sistema sia cambiato di un grammo. Ed è più pericoloso dell'assenza di metodo, perché l'assenza almeno si vede. La forma vuota, no: ha l'aria di essere sana.

C'è un modo di rispettare il metodo alla lettera che serve soltanto a non doversi guardare.

La salsa e il pesce

Ho in mente l'immagine della salsa e del pesce. Ci si trova per mangiare un buon pesce, che sarebbe il valore vero di quell'incontro. E ci si ritrova con un piatto pieno di salsa e niente sotto. La salsa è tutto quello che aggiungiamo intorno per farlo sembrare completo: la puntualità, il formato, il fatto stesso di averlo tenuto. Ottima, per carità. Nessuno di noi ha voglia di difendere le riunioni disordinate. Ma se copre il pesce, abbiamo sbagliato pranzo.

Aggiornare non è ispezionare

La versione più diffusa di questo scivolamento è quando gli eventi diventano luoghi di aggiornamento invece che momenti di ispezione. Il product owner arriva e racconta a che punto è. Lo scrum master mette a verbale. Il management ascolta e, se serve, corregge. Sembra ordinato, e in effetti lo è. Ma nessuno sta ispezionando qualcosa insieme, e quindi nessuno sta adattando niente. Ci si scambiano fatti. Nessuna delle idee di partenza viene messa in dubbio.

La differenza è sottile, e cambia tutto. Ispezionare vuol dire prendere un risultato e chiedersi se stiamo andando dove volevamo. Aggiornare vuol dire dire dove siamo, senza che quel «dove siamo» produca una decisione. Il primo è una responsabilità condivisa. Il secondo è un rendiconto. E un rendiconto puntuale, ripetuto ogni due settimane, può convivere per mesi con un prodotto che sta andando nella direzione sbagliata. Nessuno mente, in tutto questo. Semplicemente, nessuno viene mai messo nella posizione di dover decidere.

La prova, all'uscita

Non propongo di essere più fedeli alla lettera di Scrum: sarebbe curare il sintomo con altro sintomo. Propongo una prova più onesta, da fare ogni volta che un evento finisce. Chiediti se, uscendo da quella stanza, qualcosa è diventato più leggibile di quando sei entrato, oppure è passato nelle mani di qualcuno. Se c'è una decisione che prima non c'era. Se una zona grigia sul chi-fa-cosa si è chiarita. Se una parte del lavoro che stava sottotraccia è emersa e ha trovato un posto. Se la risposta è no, e capita più spesso di quanto vorremmo, quell'evento non ti sta servendo. Ti sta consolando.

Per come la vedo, la salute di un'adozione non si misura dal numero di cerimonie rispettate. Si misura da quanto il sistema, dopo quelle cerimonie, si vede meglio da solo. Un buon rito lascia dietro di sé più chiarezza di quanta ne avesse trovata. Un rito che gira a vuoto lascia soltanto la sensazione di aver fatto la propria parte. È una sensazione piacevole, e proprio per questo regge tanto a lungo.

Per me la cosa da riportare nei gruppi è proprio un cambio di verbo. Smettere di chiedere se l'abbiamo fatta. Cominciare a chiedere che cosa abbiamo reso visibile. È una domanda più scomoda, perché a volte la risposta è niente. E quel niente, quando qualcuno trova il coraggio di dirlo ad alta voce, è già l'inizio del lavoro vero. Non serve un metodo migliore per arrivarci. Serve che qualcuno faccia la domanda mentre gli altri sono ancora seduti.

Una risposta vuota, pronunciata davanti a tutti, vale più di un calendario rispettato per un trimestre.

Riferimenti

• Ken Schwaber, Jeff Sutherland, La Guida a Scrum (2020)