Scrum Anti-Pattern: gli errori più comuni (e cosa fare invece)

Scrum è un framework semplice. È composto da un Product Owner, uno Scrum Master, un gruppo di Developer, cinque eventi, tre artefatti, tre accountabilities (o responsabilità). In dieci minuti si può raccontare. In un anno si può ancora star imparando ad applicarlo bene.

La differenza tra un team che usa Scrum e uno che lo subisce risiede spesso in quello che le regole, fraintese o applicate meccanicamente, diventano nella pratica quotidiana.

Quello che segue è un elenco di dieci comportamenti ricorrenti. Li ho visti in più team, in più organizzazioni e in più contesti. Ognuno ha una descrizione, il motivo per cui è problematico e una direzione per uscirne.

Lo Sprint come fase

Il team lavora per due settimane, poi c'è la Sprint Review, poi il Retrospective, poi lo Sprint Planning, e poi si riparte. Il ciclo è chiaro. Il problema arriva quando lo Sprint viene interpretato come una fase di sviluppo: si inizia, si produce, si consegna, si ricomincia.

In Scrum lo Sprint è un contenitore per l'ispezione e l'adattamento. Ogni evento ha uguale importanza e finalità: il Daily Scrum aiuta a ispezionare il progresso verso lo Sprint Goal, la review a ispezionare il prodotto, la retrospettiva a ispezionare il processo.

Se il team vive lo Sprint come una semplice fase, tende a saltare gli eventi o a svuotarli di significato. Il Daily Scrum diventa uno status report, la review una demo, la retrospettiva un'ora di chiacchiere.

Cosa fare invece: tratta ogni evento come una pausa utile e un'occasione per apprendere, piuttosto che come un'interruzione. Se il team vede il valore della review, della retrospettiva e del Daily Scrum, non li vive come una perdita di tempo.

Il Daily Scrum come report di stato

Il Developer A dice cosa ha fatto ieri. Il Developer B dice cosa farà oggi. Lo Scrum Master prende appunti. Il Product Owner ascolta. Tutti aspettano il proprio turno, spesso senza prestare attenzione a cosa dicono gli altri.

Il Daily Scrum è nato per pianificare le prossime ventiquattro ore insieme, non per riferire a qualcuno. La domanda principale non dovrebbe essere "cosa hai fatto?" ma "cosa possiamo fare oggi per avvicinarci allo Sprint Goal?".

Se il Daily Scrum diventa un giro di "status report", il team perde l'occasione di riorganizzarsi. I problemi emergono ma nessuno li affronta perché non è il momento. O peggio, emergono e lo Scrum Master li prende in carico, trasformandosi in un centro di smistamento.

Cosa fare invece: sposta l'attenzione dal passato al futuro. Se i Developer parlano di quello che faranno insieme nelle prossime ore, il Daily Scrum torna a essere un momento chiave per coordinare il lavoro. Lo Scrum Master e il Product Owner possono partecipare se ne traggono valore, ma non sono tenuti a essere presenti o a intervenire: l'evento appartiene ai Developer.

Il Product Owner assente durante lo Sprint

Il Product Owner partecipa alla pianificazione, definisce le priorità, poi scompare. Durante lo Sprint non risponde alle domande dei Developer e non è al corrente di ciò che il team sta sviluppando. Ricompare alla review e scopre che quello che è stato sviluppato non corrisponde a quello che si aspettava.

In Scrum il Product Owner è responsabile del valore del prodotto. Questa responsabilità non si ferma alla pianificazione. Il Product Owner deve essere disponibile durante lo Sprint per chiarire dubbi, rivedere ipotesi e prendere decisioni. Se non lo fa, i Developer lavorano in condizioni di incertezza e aumenta la probabilità di dover rifare il lavoro.

Cosa fare invece: il Product Owner deve impegnarsi a essere disponibile durante lo Sprint per rispondere alle domande dei Developer entro poche ore, valutare i lavori in corso e supportare le decisioni quando l'apprendimento emerso dallo sviluppo richiede di aggiustare la direzione. Al team basta poter contare su di lui quando serve. Non serve che partecipi a ogni riunione.

Lo Scrum Master come segretario

Lo Scrum Master prenota le sale riunioni, aggiorna il calendario, tiene traccia delle azioni della retrospettiva, prepara la presentazione della review. Intanto il team continua a lavorare con gli stessi problemi organizzativi di sempre.

Lo Scrum Master non è un amministratore. Il suo compito è rendere il team più autonomo e aiutare a rimuovere gli ostacoli che il team da solo non può risolvere. Se lo Scrum Master viene usato come segretario, il team non impara a gestire il proprio processo e l'organizzazione non cambia.

Cosa fare invece: lo Scrum Master smette di fare cose che il team potrebbe fare da solo e si concentra su quello che richiede la sua competenza: facilitazione, coaching, rimozione degli ostacoli sistemici e gestione del cambiamento a livello di organizzazione. I "ticket" possono aggiornarseli da soli.

Il Product Backlog come lista di task

Il Product Backlog contiene voci come "configurare il database", "aggiungere logging", "refactor del modulo X". Sono attività tecniche, forse anche utili, ma non comunicano il valore che portano all'utente.

In realtà il Product Backlog è un elenco ordinato di ciò che serve per migliorare il prodotto. Ogni voce dovrebbe rendere chiaro perché è importante e quale contributo dà al Product Goal. Se il backlog è pieno di attività tecniche, diventa difficile ordinarlo per valore e il Product Owner non ha gli elementi per decidere cosa sia più urgente.

Cosa fare invece: inizia a esprimere le voci del backlog in termini di risultato, piuttosto che di attività. "Aggiungere logging" diventa "rendere disponibili i log degli errori per il team di supporto". Invece di cercare una formula precisa per ogni voce, serve rendere visibile il motivo per cui quella voce esiste, anche a chi non scrive codice.

Lo Sprint Planning troppo lungo o troppo corto

Due casi opposti, stesso problema. In un caso la pianificazione dura quattro ore perché il team cerca di definire ogni dettaglio, ogni attività, ogni dipendenza. Nell'altro caso dura venti minuti perché tanto si decide strada facendo.

Lo Sprint Planning serve ad allineare il team sull'obiettivo dello Sprint e sul lavoro necessario per raggiungerlo. Non deve produrre un piano perfetto. Se dura troppo, il team sta cercando una "certezza" che Scrum di per sé non dà. Se dura troppo poco, il team parte senza una direzione condivisa e rischia di perdersi strada facendo.

Cosa fare invece: concentra la pianificazione sullo Sprint Goal prima ancora che sui dettagli. Se il team capisce dove vuole arrivare, i dettagli sul "come" emergono durante lo Sprint, nei Daily Scrum e nelle conversazioni informali. Uno Sprint Goal ben definito dà al team un criterio per decidere cosa continuare a sviluppare e cosa rimandare quando le priorità cambiano.

La Sprint Review senza conversazione

Il team mostra quello che ha fatto. Gli stakeholder annuiscono. Qualcuno fa una domanda tecnica. Il Product Owner dice "grazie a tutti". Finito.

La Sprint Review è l'occasione per ispezionare il prodotto insieme alle persone che hanno interesse a vederlo migliorare. Se manca la parte di conversazione, o gli stakeholder non contribuiscono con il loro punto di vista, oppure se il team ignora i feedback che possano orientare il lavoro dei prossimi Sprint, la review perde il suo scopo.

Cosa fare invece: invita stakeholder che usano il prodotto e hanno opinioni da condividere. Struttura la review intorno a domande per cui vorresti una risposta. Evita di presentare delle slide. Mostra il prodotto funzionante e chiedi: "cosa cambieresti?". La conversazione vale più della presentazione. Alla fine, il Product Owner aggiorna il Product Backlog con quello che è emerso: la review non guarda solo indietro, ma prepara le prossime mosse.

Sprint Retrospective senza cambiamento

Quante retrospettive hai visto che sembravano andare bene e non hanno prodotto nessun cambiamento? Il team si riunisce, parla dei problemi come se fosse una terapia di gruppo, scrive azioni su un post-it, poi torna al lavoro e non succede niente. Alla retrospettiva successiva gli stessi problemi rispuntano.

La Retrospective serve a identificare cambiamenti che migliorano il modo di lavorare. Se questi cambiamenti non vengono implementati, la retrospettiva si svuota di significato e diventa un rituale. Il team smette di crederci e magari chiede di eliminare questo evento fondamentale dal calendario.

Cosa fare invece: cambia formato di tanto in tanto. Prova a partire da un problema concreto o da una domanda specifica, invece che dal solito giro di "cosa è andato bene e cosa no". Usa la retrospettiva anche per rivedere la Definition of Done: è ancora adatta al contesto del team o va aggiornata? Limita le azioni a una o due per Sprint e assegna un responsabile. Alla retrospettiva successiva, comincia da lì: cosa è cambiato? Se non è cambiato nulla, chiediti perché. Un'azione realizzata vale più di dieci azioni scritte e dimenticate.

Velocity come obiettivo

Il team misura la velocity, la riporta in un grafico, e a un certo punto qualcuno comincia a dire "dobbiamo aumentare la velocity". Oppure, peggio, la velocity diventa un parametro per valutare il team.

La velocity non è una metrica di performance. Dice solo quanto lavoro il team ha completato in media negli Sprint passati, senza dire nulla sul valore di quel lavoro per l'utente o per il prodotto. Usarla per fissare un target è come misurare la temperatura e poi decidere che deve salire.

In teoria la velocity può servire per fare previsioni. In pratica, quando i Developer sanno che la loro velocity viene osservata, cominciano ad aggiustare le stime per non sforare il target. Il numero diventa stabile, il grafico è bellissimo, e la metrica non dice più nulla: la velocity si trasforma così in una "vanity metric". Nella maggior parte dei casi, ho visto la velocity diventare completamente inutile proprio per questo motivo.

Cosa fare invece: se proprio vuoi usare la velocity, fallo solo per fare previsioni approssimative, senza trasformarla in un indicatore di produttività. Se il team vuole migliorare, lavora sulla qualità del prodotto, sulla riduzione del debito tecnico, sulla chiarezza del backlog. Le metriche di throughput sono più utili della velocity per capire il flusso di lavoro.

Membri del team divisi su più progetti

Un Developer partecipa a due Sprint paralleli. Segue il Daily Scrum del team A e parte di quello del team B. Risponde a messaggi su tre canali diversi. A fine Sprint ha completato metà del lavoro su ogni fronte.

L'efficacia di Scrum dipende dalla capacità del team di concentrarsi su un obiettivo alla volta. Se le persone sono divise su più progetti, non sono mai completamente disponibili per nessuno dei due team. Il lavoro rimane in sospeso durante il cambio di contesto (context switching) e la qualità del contributo diminuisce su entrambi i fronti.

Cosa fare invece: proteggi il focus del team. Se una persona serve su due progetti, l'organizzazione deve scegliere: o partecipa a uno Sprint per volta, oppure accetta che la produttività sarà inferiore su entrambi i fronti.

Errore o anti-pattern?

Nessuno di questi comportamenti definisce un anti-pattern se accade una sola volta. Il problema nasce quando lo stesso comportamento si ripete Sprint dopo Sprint, e diventa difficile uscirne anche quando il team lo riconosce.

Questo è ciò che distingue un errore da un anti-pattern: la ripetizione e la resistenza al cambiamento. Il team sa che il Daily Scrum è diventato un aggiornamento di stato, ma continua a farlo perché è comodo. Sa che la retrospettiva non produce cambiamenti, ma la fa lo stesso perché fa parte della cadenza. E così via.

Quanti di questi comportamenti riconosci nel tuo team? O, magari, ce n'è qualcun altro che noti durante il tuo lavoro quotidiano e che non ho elencato in questo articolo?