Ringraziamo l’autore Jason Godesky che ci ha permesso di tradurre il suo articolo in Italiano. Potete leggere il suo post originale su medium.
Questa cosa onnipresente chiamata "Scrum" è uno strumento oppressivo di micromanagement. È tutto incentrato sugli story point e sulla velocità. Si è guadagnato il totale disprezzo di sviluppatori, designer, product manager e middle manager. L'aspetto sconcertante è che esistono soluzioni ben note a tutti questi problemi, che si possono trovare in un documento conciso di 14 pagine chiamato Scrum Guide.
La Guida è piuttosto chiara su ciò che è e non è Scrum:
Il quadro di riferimento di Scrum, come delineato nel presente documento, è immutabile. È possibile implementare solo alcune parti di Scrum, ma il risultato non è Scrum.
Pochissimi di noi hanno mai lavorato in un team Scrum (come lo definisce la Scrum Guide), ma non mancano coloro che hanno lavorato in The Scrum Cargo Cult. [L’autore fa riferimento ad un suo precedente articolo in cui racconta come le isole del pacifico, abitate da indigeni, durante la seconda guerra mondiale divennero logisticamente strategiche e luoghi in cui grandi quantità di mezzi militare e cargo le utilizzarono come depositi. Alla fine del conflitto i cargo scomparvero. Questo indusse gli indigeni a costruire dei modelli di aerei con i bambù nella speranza che i “cargo” e le attività frenetiche attorno ad essi ritornassero. Godesky utilizza questo fenomeno antropologico come metafora sull’applicazione di scrum che molte organizzazioni hanno adottato, sottolinenando la distanza tra il modello in bambù di un Boeing 737 e il reale aeroplano per esprimere la distanza tra lo scrum adottato e scrum reale (NdR)].
Non c'è alcuna virtù nel seguire Scrum di per sé. L'agilità è importante, ma Scrum è solo un modo per ottenerla. Ma quasi tutti coloro che "adottano Scrum" eliminano gli elementi cruciali che lo fanno funzionare prima di iniziare anche un solo sprint. Non si tratta di una devozione religiosa ai capitoli e ai versi della Scrum Guide, ma semplicemente di capire come funziona. Ecco perché usiamo la metafora del The Scrum Cargo Cult, perché finiamo per imitare l'aspetto esteriore del sistema rimuovendo i pezzi vitali che lo fanno funzionare.
Ciò solleva una domanda più profonda: perché tutti seguiamo un processo chiamato Scrum, ma nessuno segue effettivamente il processo che la Scrum Guide definisce Scrum?
Sono molti i problemi che sorgono nelle trasformazioni agili, ma trovo due passaggi della Guida di Scrum che emergono con particolare frequenza:
I team Scrum sono interfunzionali, il che significa che i membri hanno tutte le competenze necessarie per creare valore in ogni Sprint. Sono anche autogestiti, cioè decidono internamente chi fa cosa, quando e come.
e:
L'intero team Scrum è responsabile della creazione di un incremento utile e di valore ad ogni Sprint.
L'incremento
Anche se separati in modo scomodo negli estratti precedenti, il secondo passaggio e la prima frase del primo passaggio vanno di pari passo.
- I team Scrum sono interfunzionali, il che significa che i membri hanno tutte le competenze necessarie per creare valore in ogni Sprint.
- L'intero team Scrum è responsabile della creazione di un incremento utile e di valore ad ogni Sprint.
È necessario un team interfunzionale per creare un incremento utile e di valore a ogni Sprint. Se i team sono suddivisi per funzione, è necessario che il team UX lavori prima del team di sviluppo (come raccomanda Nielsen Norman Group), ma ciò significa che il team UX non rilascia un incremento a ogni sprint: sta solo producendo elementi del backlog per il team di sviluppo. Questo probabilmente rende difficile anche per il team di sviluppo produrre un incremento utile e di valore. Se non possiamo usare il software funzionante come misura principale dei progressi, allora che scelta abbiamo se non quella di affidarci alle stime? È così che Scrum si concentra sugli story point e sulla velocità, invece che sui clienti e sul valore. Ma come afferma chiaramente il primo principio del Manifesto per lo sviluppo Agile del Software:
La nostra massima priorità è soddisfare il cliente attraverso la consegna tempestiva e continua di software di valore.
Ciò significa che se non state consegnando continuamente software di valore ai clienti, qualsiasi cosa stiate facendo non è agile. Un team Scrum che non consegna un incremento utile e di valore a ogni sprint non è un team Scrum. Nel suo saggio su "Dark Scrum" (già linkato in precedenza), Ron Jeffries (sì, lo stesso Ron Jeffries il cui nome è stato apposto sul Manifesto di cui sopra) sottolinea il ruolo critico dell'incremento e come gran parte dell'opprimente "Scrum" che tutti conosciamo e detestiamo derivi dalla sua mancanza.
... più l'incremento del prodotto è vero e reale, più influenzerà le persone a guardare alla realtà e a basare la loro gestione su di essa. Contrariamente a quanto spesso pensiamo, i nostri leader non sono stupidi. Stanno facendo del loro meglio con le informazioni che hanno. Se possiamo fornire loro informazioni migliori, sotto forma di software funzionante, inizieranno a usarle. Usando queste informazioni, ricorreranno a meno pressioni e meno abusi.
Ci sono ragioni per cui non lo facciamo. Uno di queste è un problema organizzativo: siamo divisi in gruppi funzionali, il che rende logisticamente (o forse politicamente) difficile, se non impossibile, la formazione di gruppi interfunzionali. Un altro motivo è che è davvero difficile suddividere un grande progetto in fette verticali. Un terzo motivo è che anche quando lo facciamo, come scrive Ron Jeffries nello stesso saggio:
...l'incremento deve funzionare davvero. Deve essere davvero testato, integrato, pronto per essere spedito e contenere tutti gli elementi del backlog che ci siamo impegnati a fare.
Questa è la parte in cui Scrum mette in discussione il modo normale di fare le cose, quindi piuttosto che cambiare il modo in cui facciamo le cose, ci diciamo che siamo un'eccezione; che questo potrebbe funzionare altrove, ma non può funzionare davvero per noi, quindi dovremo fare un compromesso con la realtà. Questo non è quasi mai vero, ovviamente. Diamo per scontato che le organizzazioni che lo hanno fatto lo abbiano fatto perché era più facile per loro, invece di affrontare il fatto che per loro era altrettanto difficile, ma lo hanno fatto comunque per raggiungere gli obiettivi che desideravano.
È vero che la Scrum Guide non approfondisce i motivi per cui l'incremento è importante; si limita a dire che è necessario seguire tutto ciò che è contenuto nella guida, e in alcuni casi è piuttosto sintetico. Si tratta di uno dei punti più importanti del framework, il cuore pulsante che fa funzionare l'intera struttura, ma sarebbe facile non accorgersene a una lettura casuale. Per essere un documento conciso di 14 pagine, la Scrum Guide si aspetta che i lettori la prendano sul serio e scoprano perché e come si incastra il tutto usandola qualche volta, ma poiché è così raro che le organizzazioni formino team interfunzionali e si aspettino un incremento di lavoro alla fine di ogni sprint, pochi sperimentano come e perché funziona tutto questo.
Il team che si autogestisce
A volte sentiamo parlare dell'importanza dell'autogestione quando si tratta di rimanere fino a tardi per risolvere i bug o di assumersi la responsabilità per le interruzioni del server o i tempi di inattività, ma quante volte i team Scrum decidono di sviluppare meno nuove funzionalità in questo sprint per potersi concentrare sulla scrittura di più test unitari? O per pagare un po' del loro crescente debito tecnico? Quante volte i team Scrum decidono di assumere un nuovo membro del team? O di rimuovere qualcuno dal team?
Una delle domande più grandi in molte trasformazioni agili è dove si inseriscono i manager in Scrum. Sono gli Scrum Master? I product owner? La Scrum Guide è abbastanza chiara su questo punto:
I [team Scrum] sono anche autogestiti, cioè decidono internamente chi fa cosa, quando e come.
Allen Holub è il mio critico preferito di Scrum. Ha scritto e parlato molto di questo preciso argomento e del perché spesso porta al fallimento di Scrum. I manager si rendono conto che l'agilità è una minaccia esistenziale per loro, quindi si coalizzano naturalmente per sabotarla. A volte questo è consapevole, ma altrettanto spesso (se non di più) è benigno. Cercano di capire dove si inseriscono nel nuovo ordine e modificano il processo per fare spazio a se stessi. Possono persino convincersi che stanno togliendo responsabilità agli sviluppatori, in modo che possano concentrarsi maggiormente sul lavoro. Però come ha scritto Mike Cohn:
... sì, agile è una questione di micromanagement, ma è una questione di micromanagement da parte del team e per il proprio beneficio.
Quindi, per quanto i manager possano sperare di essere utili, togliendo i compiti di gestione dalle spalle dei loro team, stanno togliendo loro l'autonomia e trasformando il processo in uno strumento di controllo oppressivo.
Allen Holub sottolinea che se una trasformazione agile significa che i dirigenti saranno tutti disoccupati, allora il fallimento della trasformazione è assicurato. Per avere successo, una trasformazione deve offrire un futuro a tutte le persone i cui ruoli attuali verrebbero eliminati dalla trasformazione stessa. Secondo lui, in un'azienda umana, si cercherebbero modi per far sì che i manager diventino Scrum Master, product owner o membri del team, in base alle loro competenze e interessi. Se ciò significa una nuova formazione, questa può essere fornita. E se non vogliono far parte del nuovo futuro agile, l'azienda dovrebbe mantenerli, con stipendio e benefit, mentre li aiuta a trovare un'altra posizione più adatta a loro.
Senza questo trattamento umano, il management diventa un ostacolo radicato all'agilità, che lotta contro i nostri sforzi per la propria sopravvivenza. È improbabile che una trasformazione che crea fazioni all'interno dell'organizzazione e le mette l'una contro l'altra abbia successo, soprattutto quando la fazione più combattuta è quella che prende tutte le decisioni.
David Marquet ha sostenuto l'approccio "leader-leader" alla leadership, con il principio che le decisioni dovrebbero essere prese, per quanto possibile, dalle persone che conoscono meglio l'argomento in questione. Si tratta quasi sempre delle persone che svolgono il lavoro, non di un manager o di un dirigente.
Scrum porta le organizzazioni a questo tipo di leadership definendo un team Scrum come autogestito. Fornire un incremento utile e di valore a ogni sprint è una responsabilità importante. Non possiamo aspettarci che i team Scrum mantengano questa responsabilità se non li mettiamo in condizione di prendere le decisioni necessarie per farlo. Non si può essere agili, perché c'è un apparato di comando e controllo che deve passare attraverso l'approvazione delle decisioni, il che rappresenta un ulteriore ritardo, rendendo più lungo il ciclo di ispezione e adattamento. Se c'è qualcuno che gestisce il vostro lavoro, allora non fate parte di un team che si autogestisce: quindi, qualunque cosa sia il vostro team, secondo la Scrum Guide, non è un team Scrum.
Il problema della zampa di scimmia di Scrum
(“La zampa di scimmia" è un racconto dell’orrore di WW Jacobs. Il problema che si presenta ne "La zampa di scimmia" è che quando esprimono dei desideri sulla zampa, le conseguenze non sono quelle che si aspettavano)
Secondo un sondaggio pubblicato da Parabol, i motivi principali per cui le aziende cercano di aumentare l'agilità sono:
- consegna più rapida ai clienti (83%)
- migliorare la produttività (76%)
- aumento della prevedibilità, della trasparenza e della visibilità (70%)
- migliorare l'efficienza (69%)
- migliorare i metodi di organizzazione del lavoro (68%)
I punti #1, #2 e #4 sono tutti strettamente correlati, quasi ma non del tutto sinonimi. Ripensare il modo in cui lavoriamo insieme entra nella top five, ma solo per poco. In questo divario, possiamo vedere il presupposto che l'azienda sta andando bene - abbiamo solo bisogno di quegli sviluppatori per fare di più.
Scrum è visto principalmente in questi termini: come un mezzo per aumentare la produzione e come qualcosa di rilevante solo per il team di sviluppo software. Se lo sviluppo del software richiede uno Scrum Master, il manager può farlo; se richiede un Product Owner, il project manager può farlo. Possiamo mappare tutti i nostri ruoli e processi esistenti in termini di Scrum abbastanza facilmente. Possiamo creare istanze Jira e programmare revisioni di sprint e stand-up giornalieri. Nulla di tutto ciò rappresenta un grande ostacolo al modo in cui abbiamo sempre fatto le cose. Ma un team interfunzionale significherebbe sconvolgere le divisioni dipartimentali che l'azienda ha formato (e forse anche la gerarchia di rapporti formata intorno a tali divisioni). I team autogestiti potrebbero mettere a rischio tutti i manager dell'organizzazione come gruppo. Suggerimenti come questi vanno al di là dell'obiettivo della trasformazione agile, perché il vero obiettivo non è trasformare l'organizzazione in una più agile, ma trasformare il team di sviluppo in un team che produca più risultati.
Per questo motivo le organizzazioni sono spesso insofferenti alle prime fasi turbolente di una trasformazione agile (le fasi di "storming" e di "norming" nel modello di Tuckman), quando l'interruzione di un nuovo cambiamento rallenta il lavoro. Questo è il momento in cui molte organizzazioni intervengono per imporre modifiche a Scrum, per renderlo "più affidabile" o "adattarlo" al loro lavoro. Questo spesso significa una maggiore attenzione agli story point, alla velocità e ad altre metriche, in modo che l'azienda possa assicurarsi che il team stia mantenendo i livelli di output. La legge di Goodhart entra in vigore, poiché il team diventa abile nel produrre le metriche di cui è responsabile, anche se non produce più software funzionante di quanto non abbia mai fatto prima.
Scrum fallisce per lo stesso motivo per cui è onnipresente. Si è guadagnato la reputazione di essere un modo rapido e relativamente indolore per aumentare la produttività dei team di sviluppo. Ma proprio perché è visto come un modo rapido e relativamente indolore per aumentare la produzione di un team di sviluppo, le organizzazioni spesso resistono ai suggerimenti di coinvolgere più del solo team di sviluppo, o di apportare modifiche che non siano rapide o indolori, o di accettare un calo della produzione (anche temporaneo). Noterete che le due parti critiche della Scrum Guide che abbiamo discusso come spesso ignorate dalle organizzazioni sono proprio le parti di Scrum che vanno oltre il team di sviluppo e chiedono all'organizzazione di trasformarsi veramente. Per citare ancora una volta Allen Holub:
Agilità oltre Scrum
Spero che la Scrum Alliance non mi tolga la certificazione per averlo detto ad alta voce, ma credo che Scrum abbia superato la sua utilità. Il cuore di Scrum è il suo ciclo di ispezione e adattamento. Come continuo a parafrasare Dave Thomas, l'algoritmo di base dell'agilità è:
- Capire dove ci si trova.
- Fare un piccolo passo verso l'obiettivo.
- Adattare la propria comprensione in base a ciò che si è appreso.
- Tornare alla fase 1.
Lo Scrum descritto nella Scrum Guide fa questo, ma è stato commercializzato come una panacea in modo tale che le aziende ignorano parti critiche di ciò che lo fa funzionare. Come ha sottolineato Tim "Agile Otter" Ottinger:
Il problema inizia con la semplice constatazione che quasi tutte le politiche e i processi di sviluppo del software esistono per evitare che il software venga rilasciato.
Quindi, quando le organizzazioni decidono quali parti di Scrum prendere o lasciare, lo fanno con un orientamento verso i processi che conoscono e capiscono - processi che hanno come scopo quello di impedire il rilascio del software. Il che rende molto più difficile l'esecuzione del passo 2 del nostro algoritmo, che allunga i cicli e che, in ultima analisi, morde l'intero scopo dell’esercizio.
Quando è stato sviluppato negli anni '90, mettere nelle mani dei clienti un software utile e di valore ogni due settimane era un'idea radicale. Scrum offriva il ciclo di ispezione e adattamento più rapido in circolazione. Oggi, invece, la consegna continua significa che mettiamo abitualmente software utile e di valore nelle mani dei nostri clienti più volte al giorno.
La consegna continua rende Scrum obsoleto. L'agilità - come l'approccio al lavoro a cui sarete portati se prenderete sul serio i valori e i principi del Manifesto per lo sviluppo Agile del Software - rimane importante come non lo è mai stata. Scrum avrebbe potuto essere un'incredibile forza per il bene; purtroppo, invece, è diventato un altro strumento di oppressione e abuso. Le soluzioni a questi problemi esistono già - nella stessa Scrum Guide, tragicamente - ma a questo punto c'è davvero speranza di salvare Scrum dal Complesso Industriale Agile?
Forse è giunto il momento di esplorare l'agilità al di là di Scrum. La consegna continua prende il nome dal primo principio del Manifesto, citato in precedenza, e porta questa premessa a un livello che poteva sembrare impossibile nel 2001. Ci permette di fare passi ancora più piccoli, abbastanza piccoli da eseguire l'algoritmo di Dave più volte al giorno.
Nello stesso articolo che ho citato sopra, Tim Ottinger suggerisce che un modo per aggirare i loop, le code e i ritardi incorporati nei nostri processi abituali di consegna del software (senza sacrificare i nostri standard di qualità) è quello di...
...riunire le persone che si sarebbero passate il lavoro tra loro e farle lavorare insieme su un elemento di lavoro, rivedendolo e testandolo al volo. Questo include sviluppatori, tester, UX, UI, sicurezza... tutte le persone.
Una delle cose più importanti da mantenere di Scrum è quella che quasi tutti noi stavamo tagliando fuori prima di provarlo: il team autonomo, autogestito e interfunzionale. In realtà, dobbiamo andare oltre. Non basta assemblare un team di questo tipo; dobbiamo anche fare in modo che “mob development” diventi la norma per loro. Si tratta di una tecnica che integra in modo eccezionale la continuous delivery.
C'è solo una pratica prescritta dal Manifesto, però. È il principio finale:
A intervalli regolari, il team riflette su come diventare più efficace, quindi mette a punto e regola il proprio comportamento di conseguenza.
Non serve una struttura per diventare agili. Serve un team che si impegni a diventare più agile, serve un'organizzazione aperta a sperimentare cose nuove e serve una retrospettiva programmata regolarmente. Se si dispone di questo, una buona retrospettiva produrrà tutti gli altri processi e le pratiche necessarie, creando un approccio particolare all'agilità, fatto su misura per il lavoro che si svolge.