Ringraziamo l’autore David Pereira che ci ha permesso di tradurre il suo articolo in Italiano. Potete leggere il suo post originale su medium.
Il mercato si sta spostando in una nuova direzione, c’è ancora posto per Scrum?
È impossibile ignorare quanto Scrum sia conosciuto. Per anni, Scrum è stato la prima scelta tra i framework Agile per la maggior parte delle aziende di tutto il mondo; solo poche lo contestavano. Ma di recente qualcosa è cambiato: le organizzazioni stanno perdendo fiducia in Scrum. Dopo aver fallito nell'ottenere risultati significativi, in molti stanno sostituendo Scrum con SAFe, Kanban o altri framework.
Oltre alle organizzazioni insoddisfatte, i professionisti esperti sono riluttanti a lavorare con Scrum. Molti si sentono addirittura in imbarazzo a essere chiamati Product Owner o Scrum Master. Il mercato si sta spostando in una nuova direzione, ci sarà ancora spazio per Scrum?
Le aziende vogliono essere Agili, ma faticano a rinunciare al vecchio stile di comando e controllo.
Permettetemi di spiegare perché ritengo che i giochi siano finiti per Scrum.
Avviso: Il contenuto di questo articolo si basa sulla mia esperienza e sulle mie osservazioni degli ultimi dieci anni. Per questo vi invito a condividere anche il vostro punto di vista.
Scrum non è un processo!
Lo sviluppo del software è ancora qualcosa di nuovo; il primo software è apparso solo nel 1948. Credo che Tom Kilburn non potesse immaginare la velocità con cui il mondo sarebbe progredito grazie allo sviluppo del software.
L'informatico Tom Kilburn è responsabile della scrittura del primo software al mondo, eseguito alle 11 del 21 giugno 1948 presso l'Università di Manchester, in Inghilterra.
- Micah Yost, A brief history of Software Development
Fino al nuovo millennio, le aziende non disponevano di tecniche per soddisfare le aspettative dei clienti. La maggior parte delle aziende si concentrava sul miglioramento dei processi di sviluppo del software. Nonostante gli sforzi per implementare processi gravosi come il Rational Unified Process, la qualità era ancora discutibile e i clienti insoddisfatti. La creazione di software inutile frustrava molte persone; era necessaria una rivoluzione.
Sebbene esistessero già framework agili come Scrum e eXtreme Programming, è stato nel 2001 che è stato adottato il Manifesto per lo Sviluppo Agile del Software, che ha cambiato in modo significativo il modo in cui il software viene sviluppato a livello globale. In seguito, il framework Scrum è diventato il più popolare tra le alternative.
Data la situazione all'inizio di questo millennio, Scrum sarebbe stato in grado di risolvere tutti i problemi di sviluppo del software? Era essenziale capire la causa principale, ma molte aziende hanno ignorato questo passaggio e hanno deciso di trovare un nuovo processo. Sostituire semplicemente il processo di lavoro delle persone non poteva essere sufficiente. Questo è il motivo per cui la maggior parte delle organizzazioni non è riuscita a trarre vantaggio da Scrum.
La causa principale non era il processo, ma la mancanza di una mentalità Agile.
Utilizziamo il calcio come esempio: il Barcellona ha vinto 14 titoli in quattro anni sotto la guida di Pep Guardiola. Dal 2008 al 2012, il Barcellona è stato in assoluto la migliore squadra di calcio del mondo. Molti attribuiscono il successo al modo in cui Guardiola ha allenato la squadra. Uno degli aspetti notevoli era il gioco dominante: il Barcellona aveva spesso più del 70% del possesso palla. Significa che applicare il "Tiki Taka“ a un'altra squadra è sufficiente per ottenere risultati simili?
Guardiola ha allenato il Bayern Monaco dal 2013 al 2016, applicando lo stesso stile del Barcellona. Tuttavia, il successo non è stato paragonabile a quello del Barcellona; con il Bayern Monaco ha vinto cinque titoli nazionali e nessun titolo europeo. Il solo processo non è sufficiente per raggiungere la grandezza; è necessario qualcosa di più.
Le aziende che hanno trattato Scrum come un processo hanno fallito. Nessun framework Agile può portare i team al successo senza cambiamenti più significativi. Finché le aziende non risolveranno le loro disfunzioni, l'ambiente non permetterà ai team di eccellere.
Ho osservato molti team Scrum impotenti perché l'ambiente era disfunzionale. Le disfunzioni più comuni sono
- Mancanza di fiducia
- Mancanza di direzione
- Priorità basate sul titolo
- Micromanagement
Il fallimento di Scrum è inevitabile per le aziende disfunzionali. Eppure, Scrum si prenderà la colpa.
Scrum non è un framework per le organizzazioni che temono il cambiamento. È impossibile avere successo con Scrum senza cambiare la cultura. Molte persone conoscono a memoria i ruoli, gli eventi e gli artefatti, ma poche conoscono i valori. Senza vivere i valori alla base di Scrum, è impossibile ottenere ciò che Scrum promette.
Perché Scrum sta per collassare?
Scrum sostiene di essere semplice da capire ma difficile da padroneggiare. Quasi tutti i miei conoscenti sono d'accordo con questa affermazione, ma vorrei mettere in discussione la semplicità di Scrum. Viene spesso ignorata una parte critica del framework: provate a chiedere a qualche team quali sono i valori. Rimarrete sorpresi: quasi nessuno li conosce. Tuttavia, i valori sono una parte cruciale di Scrum.
Il successo di Scrum dipende dal fatto che le persone diventino più abili nel vivere cinque valori:
Impegno, Focalizzazione, Apertura, Rispetto e Coraggio.
- La Guida di Scrum, novembre 2020
Quando le organizzazioni trattano Scrum come un processo da implementare, le battute d'arresto sono inevitabili. Per sua natura, Scrum è incompleto e nessun team può avere successo senza adattarlo al proprio scenario. Ad esempio, la gestione dei prodotti non fa parte di Scrum, eppure è una disciplina fondamentale per realizzare prodotti significativi.
Per avere successo con Scrum, le organizzazioni devono passare attraverso una massiccia trasformazione. Purtroppo, la maggior parte dei dirigenti non è disposta a fare il necessario per preparare un ambiente che permetta ai team di prosperare. Mi sono imbattuto nei seguenti paradigmi aziendali:
- Responsabilizzazione contro micromanagement
- Risultato contro produzione
- Allineamento contro consenso
- Assumere rischi piuttosto che seguire un piano
"Il top management ritiene che sia troppo rischioso avere team veramente autogestiti. Questo è il motivo per cui Scrum si scontra con un soffitto di vetro".
- Willem-Jan Ageling, Scrum has hit the Glass Ceiling
Il top management spesso non è in grado di responsabilizzare gli individui perché vuole mantenere il controllo. Ecco perché prendono la scorciatoia. Prima si cambia l'esecuzione. Poi, se Scrum dimostra il suo valore, si cambia la cultura. Ma non funziona così e il risultato è una frustrazione per tutti. Quando Scrum diventa un processo, i ruoli mutano in qualcosa di inutile. Permettetemi di condividere alcuni dei miei insegnamenti.
Foto di Maria Teneva su Unsplash
Il Product Owner
Senza essere responsabili della definizione delle priorità, i Product Owner si comportano come camerieri. Prendono le ordinazioni, suggeriscono un contorno e danno l'ordine alla cucina. È frustrante essere un esecutore di ordini; l'unico obbligo che avete è quello di gestire le aspettative degli stakeholder e di creare un ponte di comunicazione con gli sviluppatori.
Purtroppo, le mutazioni nel ruolo di Product Owner sono più la regola che l'eccezione. Ecco perché mi chiedo se qualcuno possa essere un Product Owner Scrum. Se guardo indietro nella mia carriera, forse sono stato vicino a diventarlo, ma non sono mai stato pienamente responsabilizzato, come raccomanda la Guida Scrum. La mia domanda è: esiste un Product Owner Scrum nel mondo aziendale?
Quante aziende potete citare in cui il Product Owner ha davvero l'ultima parola su tutte le decisioni relative al prodotto? E se non ha l'ultima parola, è ancora un Product Owner? Eppure, ci sono centinaia di migliaia di persone che rivendicano il titolo di Product Owner, senza possedere alcun prodotto.
- Maarten Dalmijn, Will the real Product Owner please stand up?
Oltre agli anti-pattern, ho notato che molte persone orientate al prodotto hanno perso interesse per il ruolo di Product Owner. Hanno difficoltà a collegarlo al ruolo di Product Manager. Sebbene le aziende assumano spesso Product Owner, molti professionisti si vergognano,come Marty Cagan, di essere chiamati così a causa della percezione di riferimento che sostiene che il Product Owner non è un lavoro, ma un ruolo, e che il lavoro è molto più di quanto suggerisce Scrum.
Gli sviluppatori
Gli sviluppatori sono coloro che decidono come svolgere il proprio lavoro; sono responsabili dell'implementazione, dello stack tecnologico da utilizzare e così via. È una bella teoria. Ma in pratica non l'ho mai vista. È comune avere un Chief Technology Officer (CTO), un Tech Lead o qualcun altro che non solo prende le decisioni, ma gestisce anche gli sviluppatori.
Scrum rivendica l'autonomia degli sviluppatori, ma è vero che la ottengono? Credo che ciò avvenga raramente. È triste dirlo, ma la maggior parte degli sviluppatori riceve ordini da eseguire; solo raramente gli sviluppatori sono autorizzati a lavorare su problemi senza una scadenza.
Gli sviluppatori Scrum possono essere insieme ai Product Owner Scrum nel mondo della fantasia, ma non nella realtà. Ciò che troviamo facilmente sono sviluppatori chiusi in una fabbrica che costruisce funzionalità.
Scrum Master
Lo Scrum Master è il ruolo più disprezzato in Scrum. È comune trovare team Scrum senza uno Scrum Master perché le aziende sono riluttanti ad assumere qualcuno per questo lavoro. Tuttavia, alcune aziende che assumono Scrum Master spesso li lasciano senza potere.
Inevitabilmente gli Scrum Master falliscono perché non sono in grado di promuovere il cambiamento necessario per consentire a Scrum di prosperare.
Lo Scrum Master non è diverso dagli altri ruoli. È improbabile trovare una persona che possa essere esattamente quella che la Guida di Scrum suggerisce. Gli Scrum Master sono generalmente impotenti nel promuovere i cambiamenti necessari nelle organizzazioni.
Scrum sopravviverà?
Molti professionisti esperti sono stanchi di Scrum, hanno perso la fiducia in esso. Vogliono qualcos'altro e sono alla ricerca di opportunità per sperimentare framework diversi.
La paura del cambiamento da parte dei dirigenti impedisce ai team Scrum di prosperare. Una sequenza di decisioni sbagliate e di convinzioni errate potrebbe portare Scrum alla sua fine. Il top management non può abbandonare il suo stile di comando e controllo inadeguato.
Potrebbe verificarsi un triste esito: SAFe, l'agente Waterfall in incognito, è pronto a salire sul trono.
Mi spaventa SAFe perché è un processo pesante e non sembra affatto un approccio agile. Come si può memorizzare il funzionamento di questa macchina pesante? Mi chiedo perché osino chiamarlo Agile.
Scrum potrebbe aver bisogno di un riavvio per sopravvivere
I ruoli di Scrum non sono più affascinanti come un tempo. La percezione errata di Scrum da parte di molte aziende porta i professionisti a non lavorare con esso. Negli scenari in cui Scrum diventa un processo, le persone non vogliono essere Scrum Master o Product Owner.
Ritengo che Scrum abbia bisogno di un riavvio per rimanere rilevante.
Viviamo in tempi diversi rispetto a 20 anni fa. Nel 2001, Scrum era la novità assoluta. Il mondo è cambiato. Ora Scrum è una mercanzia. Affinché Scrum rimanga in prima linea, i creatori devono avere il coraggio di abbracciare il nucleo del framework e di affrontare gli ostacoli. Alcuni di questi (possibili) tabernacoli possono essere ora delle vacche da mungere. Pensate alle certificazioni (Scrum Master e Product Owner).
- Willem-Jan Ageling, Will Scrum fall victim to its own success?
Indipendentemente da ciò che accade, le aziende che hanno il coraggio di cambiare il proprio cuore possono eccellere con Scrum. Non si tratta mai di definire un processo, ma di avere una cultura incentrata sul fornire valore in tempi brevi. C'è speranza, alcune aziende coraggiose possono abbracciare il cambiamento e i segnali che mostrano sono:
- Il Chief Product Officer diventa parte del team esecutivo.
- L'alta direzione si concentra sul dare indicazioni anziché istruzioni.
- I team Scrum sono autorizzati a sperimentare diverse alternative per raggiungere i risultati chiave.
- Viene istituita la Product Discovery. I dirigenti sanno che è indispensabile investire il giusto tempo per individuare i problemi che vale la pena risolvere.