Buone pratiche

Nel precedente articolo, abbiamo visto una serie di considerazioni che sono tipiche in un processo di trasformazione agile di un’organizzazione: dalle motivazioni ai dubbi, dalle aspettative agli errori da non commettere.

Ci eravamo lasciati con una considerazione: le trasformazioni agili in azienda si fanno attraverso un’attività di coaching che, partendo anche dalla formazione e dalla consulenza, tende però con il passare del tempo a ridurre sempre più il ruolo dell’esperto esterno e a far crescere la consapevolezza e l’assunzione di responsabilità da parte delle componenti interne all’organizzazione, che sono i veri agenti della trasformazione.

Organizzazioni complesse

Uno degli aspetti da tenere in considerazione è che le aziende di una certa dimensione sono organizzazioni complesse in cui tanti sono i livelli di consapevolezza e responsabilità, tante sono le prospettive e la visione sull’intero “organismo”.

Aggiungiamoci che l’Agile Manifesto [1] è universale e uguale per tutti con i suoi valori, ma il modo di metterne in pratica i principi cambia da organizzazione a organizzazione. Il nostro obiettivo è lavorare insieme per trovare l’applicazione giusta al contesto di riferimento. Non esiste la “taglia unica” che vada bene per tutti.

Differenti livelli di visibilità

Consapevoli di questo, negli anni, abbiamo pensato, sperimentato e implementato quella che possiamo definire una best practice, che tiene presente proprio i diversi livelli presenti nelle aziende. Lo schema di figura 1 è basato su una metafora di “visibilità” in base alla distanza: dall’aeroplano si coglie il quadro d’insieme ma non i dettagli, dall’elicottero che vola basso si vede un quadro molto meno ampio, ma si è comunque già più vicini ai dettagli, sul terrreno si ha una visione limitata sul quadro generale, ma si comprendono meglio i meccanismi e i processi di dettaglio.

Quando si affronta una trasformazione, le figure coinvolte nell’intera organizzazione hanno ruoli e obiettivi differenti. Lavoriamo così su tre livelli e con tre diversi interlocutori.

• Nella fascia che chiamiamo Airplane view, interagiamo con il top management dell’azienda, ossia con coloro che prendono decisioni circa la strategia e gli obiettivi aziendali. Con queste figure concordiamo un piano di trasformazione e la roadmap di trasformazione.
• Nella fascia Helicopter view, gli interlocutori sono le persone del middle management: project manager, product owners, product manager. Con questi si parla di aspetti più operativi e, in particolare, di servizi e prodotti da rilasciare.
• Nella fascia Ground view, lavoriamo con i team operativi, a partire da un assessment sulla loro operatività, per capire le necessità e lavorare per supportare la loro autonomia attraverso la formazione e il coaching.

La trasformazione… iterativa e incrementale

Quando lavoriamo al piano di lavoro per implementare la trasformazione, ci piace prendere spunto dagli strumenti di lavoro come per esempio dall’approccio iterativo e incrementale tipico dell’infrastruttura metodologica Scrum. Spesso quindi partiamo nella raccolta di una serie di necessità espresse dai nostri interlocutori: insieme a loro le mettiamo in ordine in base all’urgenza o all’importanza del tipo di cambiamento da portare.

Di fatto, insieme ai nostri interlocutori, si arriva a concordare un elenco di iniziative di agilizzazione, ordinate per priorità: è il backlog della trasformazione.

Tale lista verrà poi implementata insieme ai nostri interlocutori secondo un approccio iterativo e incrementale, in periodi di tempo che chiamiamo sprint di trasformazione; questi sono tipicamente più lunghi di un normale sprint Scrum: in genere proponiamo una durata fra i due e i quattro mesi.

Ogni attività messa in sprint deve avere una Definition of Ready e una Definition of Done (figura 2).

Cosa può bloccare una trasformazione agile?

Negli anni abbiamo identificato alcuni elementi ricorrenti che possono bloccare o, al contrario, facilitare la trasformazione. Vediamo intanto alcuni fattori bloccanti.

Mancanza di leadership

La mancanza di una guida a supporto dei gruppi auto-organizzati è un fattore che rallenta le trasformazioni. Sebbene in Agile si cerchi di sostenere le proposte che emergono dal basso e la formazione di team auto-organizzati, in un processo di trasformazione che impatta nella organizzazione abbiamo spesso trovato utile — se non indispensabile — la creazione di una cabina di regia che raccolga e coordini le proposte che arrivano dal basso cercando di valutare se siano in linea con la  strategia. Non un “centro di comando e controllo”, ma una struttura che tenga il ritmo senza comandarlo, che sostenga le decisioni prese senza imporle.

Top management e/o middle management non coinvolti

Strettamente legata al punto precedente, l’assenza di coinvolgimento del management è un altro fattore bloccante. Il top management spesso in una organizzazione è quello che si prende l’incarico di guidare la trasformazione fornendo supporto, prima di tutto, alla condivisione dello scopo della trasformazione stessa.

Per questo è importante partire con un lavoro volto a definire la vision della trasformazione, gli stakeholder coinvolti e i relativi bisogni: questo lavoro coinvolge tipicamente il top management per la parte di definizione e il middle management per il supporto operativo nella risoluzione dei bisogni.

Bassa qualità e scarso coinvolgimento dei fornitori

Spesso i team coinvolti nello sviluppo con approccio agile sono appaltati a fornitori esterni. La mancanza di competenze — p.e. ruoli e pratiche di Scrum — e di esperienza pregressa possono trasformare lo sviluppo di un prodotto con pratiche ispirate ai principi agili — iterativo & incrementale, feedback dal campo, business e IT che lavorano insieme e così via — in qualcosa di simile al vecchio waterfall mascherato di agile.

Anche il tipo di impegno/contratto dei fornitori è importantissimo per scardinare modelli ispirati al “Dimmi cosa vuoi che faccia e io ti dico cosa costa” che spesso finisce in  un “Non funziona ma non è colpa mia” più un “Mi aspettavo che funzionasse in questo modo, non vorrei pagare per quest’altra cosa che non c’è”. Di fatto la mancanza di un Agile Working Agreement può avere impatti devastanti per tutto il progetto di trasformazione.

Pratiche di Agile Washing

Strettamente legato al punto precedente troviamo quel modo di approcciare la trasformazione basato sull’applicazione di facciata degli strumenti e delle pratiche agili senza averne compreso il significato o senza che queste rappresentino un reale cambio di mentalità. Tante volte abbiamo visto confondere l’uso dello strumento con il reale cambio di cultura:  “Abbiamo Jira”, oppure “Usiamo i Post-it e le board” e quindi “facciamo Agile”. Però il concetto è che non si fa Agile, ma si è agili.

Cosa può aiutare una trasformazione agile?

Ecco quello che secondo noi può invece abilitare la trasformazione.

La cultura della trasparenza

Una cultura della trasparenza è fondamentale per abilitare il lavoro di gruppo, la proattività e il coinvolgimento di tutti gli stakeholder interessati. Creare un contesto trasparente vuol dire per esempio partire dal principio, condividendo obiettivi e risultati attesi della trasformazione. Essere chiari su quello che ci aspettiamo dalle persone, dal cosa vuol dire lavorare in un team spiegando apertamente se questo significa abbandonare il proprio vecchio ruolo/ufficio/mansione o se, per un periodo di tempo, vuol dire invece fare due lavori. Essere chiari su competenze e carriere; per esempio chiarire cosa ci aspettiamo da una persona che farà il PO su un progetto: solo su quel progetto oppure l’azienda vuole investire su quella persona in modo che acquisisca competenze e maturi un’esperienza da usare anche in altri progetti?.
Trasparenza sugli obiettivi organizzativi, su cosa ci aspettiamo che diventi dopo la trasformazione e quali sono gli impatti sulle persone.

Da fornitori a partner

Aiuta molto la trasformazione agile il trovare un accordo di lavoro con i fornitori esterni favorendo un contesto di reale collaborazione e partnership: se le cose vanno bene, vanno bene per tutti, se vanno male, tutti ne hanno un danno.

Creare organizzazioni che apprendono

Stimolare continuamente un contesto in cui formazione, tempo per imparare e sperimentare siano riconosciuti e supportati. Se un esperimento non funziona, non deve essere colpa di chi lo ha proposto/fatto ma deve essere qualcosa in cui energie, impegno e rischio sono condivisi.

Management coinvolto e convinto

Il supporto del management è quindi essenziale non tanto per “comandare” il modo in cui portare avanti la trasformazione, ma piuttosto per la creazione di un contesto in cui si trovi spazio per proporre soluzioni, provarle, sperimentare qualcosa di differente, applicare quello che funziona e ammettere gli errori.

Leadership forte e presente

I principi dell’agilità sono universalmente validi ma il modo con cui si mettono in pratica sono diffrenti ogni volta. Per questo non esiste un libro che dica come farla né un consulente che spieghi come leggere quel libro e come metterlo in pratica. Serve invece creare un ambiente in cui tutti gli stakeholder operativamente coinvolti sul campo si applichino concretamente per provare soluzioni e verificarne l’efficiacia. Il ruolo del capo-condottiero (“Lo so io come si fa”) viene sostituito da quello del leader — o, ancor meglio, da una leadership diffusa —  che abilita la collaborazione e la creatività da parte delle persone.

Avere il tempo per la trasformazione

MI avvio a conclusione di questa miniserie di due articoli con un’ultima riflessione, forse banale, e forse per questo troppo spesso trascurata: per fare una trasformazione serve il tempo.

Serve tempo per lavorare

Per cambiare l’organizzazione serve tempo: dedicato, di qualità, focalizzato, tolto ad altre cose. Non fate una trasformazione agile nei ritagli o in parallelo ad altro: spesso questo porta a credere che, per diventare agili, si debba lavorare di più, cosa che invece è legata al fatto che si fa un doppio lavoro.

Serve tempo per capire agile

I principi del Manifesto Agile sono piuttosto semplici, ma proprio tale semplicità nasconde una profondità non banale. È necessario provare a mettere in pratica, capire quello che si sta facendo, comprenderne il significato e assimilarne il senso, facendoli propri.

Serve tempo per capire se stessi

“Agile non ti porta all’eccellenza, ma mette in luce il tuo livello di inefficienza”. È questa una delle frasi più importanti di tutta la filosofia agile. Le metodologie agili sono specchi che vi faranno vedere la vostra organizzazione con occhi differenti. E non è detto che riuscirete a comprendere immediatamente quello che vedrete.

Serve tempo per farsi capire

Serve tempo per farsi capire da chi vi sta aiutando nella trasformazione agile: i partner, fornitori, un team di agile coach, di consulenti, di formatori. Tutte queste persone hanno bisogno di lavorare con voi per osservare, per capire, per assimilare il vostro modo di lavorare e la vostra cultura. Nuovamente, non esistono soluzioni preconfezionate pronte all’uso. Dovrete scoprirlo insieme e lavorarci insieme per pensarle, provarle, adattarle, farle evolvere.

Un percorso non lineare

Cominciare il percorso non significa automaticamente portarlo a termine. I primi insuccessi o gli errori di valutazione portano a rivedere alcune cose, a volte a un vero e proprio stop. Si parte con tanto entusiasmo, e poi c’è un momento di stanchezza, delusione, la voglia di tornare indietro. Se si supera questo punto minimo, poi si risale. Purtroppo a volte si rimane intrappolati in quella depressione.

Questo processo ondivago (figura 3) è quasi un passaggio obbligato. Serve all’organizzazione per capire cosa è Agile, per capire com’è fatta l’organizzazione stessa e com’è la propria cultura; serve per farlo capire  agli stakeholder esterni, a cominciare dagli Agile Coach esterni, ad esempio.

Esserne consapevoli, sapere che è stato così per molti altri che poi hanno proseguito con successo è sicuramente importante per vedere anche i momenti di “stanca” nella giusta prospettiva.

Conclusione

Il cambiamento avviene mettendo insieme delle esperienze e riflettendo criticamente su di esse. Noi possiamo anche progettare tutto fin dall’inizio, ma abbiamo imparato negli anni che cià che progetti non sarà quasi mai quello che si implementa. Non è sbagliato: è giusto così perché questo ci aiuta a comprendere Agile, a implementarlo nel proprio contesto, a ridurre, se non eliminare, gli errori. In definitiva, a cambiare.

Riferimenti

[1] Manifesto per lo Sviluppo Agile di Software (2001)
https://agilemanifesto.org/iso/it/manifesto.html