Questo articolo è stato pubblicato originariamente su GoRetro e 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 coraggio di abbracciare l'ignoto è obbligatorio per l'agilità
Sono stanco di discutere su quale framework Agile sia più promettente. Mi sono ritrovato più volte in interminabili dibattiti su Scrum, Kanban, LeSS, ShapeUp e SAFe (agente waterfall in incognito). Mi ci è voluto un po' per capire che queste discussioni sono inutili. La domanda non è quale sia il miglior framework Agile, ma perché si vuole utilizzare un qualsiasi framework?
Sapete perché le aziende vogliono essere Agili? Che cosa vogliono ottenere i leader? Ogni volta che pongo questa domanda, rimango sorpreso dal numero di false aspettative che si nutrono nei confronti dei framework Agile. Eccone alcune:
- Aumentare la prevedibilità degli output
- Essere più veloci dei concorrenti
- Consegnare di più in meno tempo
- Chiara visibilità sugli output
Queste risposte mostrano una mancata corrispondenza delle aspettative; non sono correlate a una mentalità orientata al valore. Purtroppo, in queste situazioni, indipendentemente dal framework Agile scelto, i risultati saranno piuttosto simili tra loro:
I team consegnano continuamente funzionalità senza sapere quale problema risolvono e perché è importante. Rimarranno bloccati nella trappola della costruzione.
Se il vostro obiettivo è consegnare le funzionalità più velocemente, non preoccupatevi dei framework Agile.
Se il vostro obiettivo è aumentare la prevedibilità, Agile vi deluderà.
Se volete che i team siano responsabili dei risultati, non provate a essere Agile.
Se siete pronti ad abbracciare l'ignoto e a reinventare continuamente il vostro modo di lavorare, allora Agile fa per voi. Tuttavia, dovete essere pronti ad affrontare un viaggio impegnativo.
Dopo anni di fallimenti con i framework Agile, ho imparato quali ingredienti devono essere presenti per aprire la strada alla creazione di valore anticipato. Permettetemi di condividerli con voi.
1 - Empowerment
Secondo la mia esperienza, l'empowerment è fondamentale per avere successo con qualsiasi framework Agile. Nei metodi tradizionali, il processo decisionale rimane al livello più alto dell'azienda. I top manager definiscono chi fa cosa e quando. I team ricevono soluzioni predefinite; l'unico aspetto che rimane è l'implementazione. Spesso non conoscono il perché di ogni soluzione, ma la leadership lo percepisce come normale, poiché si aspetta che i team portino a termine le cose invece di risolvere i problemi.
Quando si parla di team Agile, l'empowerment significa che la leadership si affida ai team per risolvere problemi significativi e lascia loro decidere quale direzione prendere. Il top management stabilisce dove atterrare e non si preoccupa di come arrivarci; dà ai team la possibilità di scoprire modi per creare valore per l'azienda e gli utenti finali.
L'immagine che segue illustra chiaramente la differenza tra i team che si occupano di funzionalità e quelli che hanno il potere di farlo.
Feature Teams vs. Empowered Teams (https://www.techcoffeetime.com/feature-teams-x-empowered-teams/)
Senza una vera responsabilizzazione, i team non andranno oltre i risultati ordinari.
2 - Responsabilità
Come disse notoriamente lo zio Ben, "Da un grande potere derivano grandi responsabilità". Questo accade con i team dotati di potere; essi dovrebbero essere responsabili dei risultati invece che della produzione, che è una bestia diversa. L'onere di fornire risultati è più pesante della semplice consegna di funzionalità dopo funzionalità.
In genere, i team funzionali faticano a passare dalla produzione al risultato. La responsabilità è fondamentale per realizzare questo passaggio. Quando la leadership ritiene che i team siano responsabili dei risultati, la responsabilizzazione diventa inutile e i team non cambiano il loro modo di lavorare. Prendiamo ad esempio Scrum; si osservano le seguenti mutazioni:
- Backlog di prodotto gonfi con voci non correlate
- Voci del backlog molto dettagliate
- Sprint carichi di caratteristiche e obiettivi poco chiari o irrilevanti
- Concentrazione su stime precise piuttosto che sull'apprendimento
- I Product Owner firmano i compiti degli sviluppatori
Ho osservato grandi risultati quando i team sono diventati responsabili del raggiungimento degli obiettivi. In questo caso, non hanno altra possibilità che adattare il loro modo di lavorare. I team sono costretti a reinventarsi e a capire cosa conta per gli utenti finali e come creare valore. Usano il loro potere per decidere come risolvere i problemi, sperimentare, imparare, ispezionare e adattarsi.
Quando i team capiscono che la produzione è un mezzo per raggiungere un fine, la creazione di valore diventa naturale.
"Il fallimento non è fatale, ma il mancato cambiamento potrebbe esserlo". John Wooden
3 - Coraggio
Agile richiede di sentirsi a proprio agio con le cose scomode. Come esseri umani, vogliamo sentirci sicuri e sapere dove stiamo andando. Non ci piace l'ignoto e possiamo persino sentirci minacciati da esso. Per questo motivo resistiamo al cambiamento e lo evitiamo il più possibile. Tuttavia, i framework Agile richiedono il coraggio di abbracciare l'ignoto. Altrimenti, come potrebbero i team scoprire le opportunità nascoste per creare soluzioni significative?
Molti pensano che Agile significhi velocità, fare di più in meno tempo, massimizzare la produzione o qualcosa di simile. Anche se il nome suggerisce velocità, non si tratta esattamente di produzione, ma di apprendimento. Per me, Agile significa ridurre il tempo di apprendimento abbracciando l'ignoto. Tuttavia, ci troviamo di fronte a troppi anti-pattern, il che rende facile cadere nelle trappole.
Prendiamo ad esempio le stime. Quanti metodi abbiamo? Story Points, T-Shirt Size, #Noestimates, Ideal Working Days e così via. Perché li abbiamo? Perché desideriamo la prevedibilità, vogliamo sapere dove stiamo andando a parare. Non sono contrario alle stime, ma possono trarre in inganno molti team e contribuire a una massiccia perdita di tempo. I team Agile che funzionano si concentrano sulla comprensione del problema in modo da essere pronti a sporcarsi le mani.
ShapeUp ha un approccio unico per affrontare l'ignoto: il diagramma di Hill. Non fanno stime, ma vedono due parti per qualsiasi attività: capire cosa fare e portarlo a termine. Durante la prima parte, il team scopre cosa comporta ogni attività; accetta di non conoscere tutte le risposte in anticipo e si sforza di chiarirle. Dopodiché, sono in cima alla collina e sanno cosa fare per portarla a termine.
ShapeUp — Hill Chart(https://basecamp.com/shapeup/3.4-chapter-13)
Senza coraggio, nessun team Agile può avere successo. Dovete essere coraggiosi e fare ciò che per voi è innaturale ma necessario per scoprire le opportunità di creare valore.
"Lavorare senza un piano può sembrare spaventoso. Ma seguire ciecamente un piano che non ha alcun rapporto con la realtà fa ancora più paura”. - Jason Fried, Rework
4 - Empirismo
Finché i team non saranno pronti a lavorare in modo empirico, falliranno. La domanda è: che cos'è l'empirismo? È la capacità di creare conoscenza dall'esperienza. Sembra semplice e logico, ma metterlo in pratica non è semplice. Va contro la nostra natura di ricercare la prevedibilità e di evitare i rischi. Permettetemi di spiegarmi meglio.
Quando le aziende iniziano un progetto, le domande più comuni sono:
- Qual è la portata del progetto?
- Quanto tempo ci vuole?
- Di quale team abbiamo bisogno?
- Quali sono i rischi?
Queste domande costringono i team a trovare risposte che non conoscono. All'inizio di qualsiasi progetto, non si hanno le conoscenze sufficienti per rispondere a queste domande, eppure la gestione tradizionale dei progetti vi costringerà a trovare una risposta. L'empirismo è diverso: vi incoraggia a creare le giuste esperienze e a imparare da esse. Una serie di domande migliori sarebbe:
- Perché è importante?
- Cosa sappiamo?
- Cosa non sappiamo?
- Come possiamo scoprire le nostre incognite?
L'empirismo costringe i team ad abbracciare l'ignoto, creando le conoscenze necessarie per risolvere i problemi in modo consapevole.
"L'intelligenza è la capacità di adattarsi al cambiamento". Stephen Hawking
Riflessioni finali
Nessuna azienda può passare da un approccio tradizionale a uno Agile in poco tempo. È necessario adattare il proprio modello mentale, il che richiede tempo e umiltà. Tuttavia, le aziende disposte a farlo si distingueranno.
Non perdete tempo a discutere su quale framework Agile utilizzare senza sviluppare una mentalità orientata al valore. Se si insiste nel farlo, sarebbe come mettere i cavalli dietro la carrozza. Il risultato è un disastro. Tuttavia, una volta compresi i comportamenti necessari e una volta disposti ad adattarsi ad essi, si può rimanere sorpresi dai risultati sorprendenti che ci aspettano.
"In ogni momento abbiamo due opzioni: fare un passo avanti verso la crescita o tornare indietro verso la sicurezza". - Abraham Maslow