Di cosa parleremo

In questo e nel prossimo articolo racconterò una serie di riflessioni, teoriche e pratiche, sul tema trasformazione delle organizzazioni, attingendo alla mia esperienza come agile coach [1]. Non vuole essere uno spot pubblicitario né una dichiarazione universale (“la trasformazione si fa così e basta”), piuttosto una condivisione di esperienze, modalità, approccio che abbiamo messo a punto nel corso di anni e di esperienze sul campo con i clienti: sono certo che tanti nostri amici, colleghi, concorrenti hanno approcci differenti altrettanto validi

Quel che mi sembra importante, invece, è capire quali siano le complessità per l’organizzazione legate alla trasformazione.

Ci sono interrogativi che aiutano ad analizzare il perché, gli obiettivi e il dove si vuole andare quando si intende estendere il mindset e le pratiche agili ai diversi reparti dell’organizzazione. Il confronto e la condivisione di esperienze e punti di vista ci aiutano reciprocamente ad approfondire ulteriormente pensieri sul tema e ad arricchirci di spunti e strumenti nuovi.

Perché si affronta una trasformazione agile aziendale?

Le risposte che riceviamo quando facciamo questa domanda ai clienti sono piuttosto tipiche… e condivisibili.

Molti decidono che è giunto il momento di cambiare la struttura dell’organizzazione e la sua modalità operativa perché cambia il mondo che ci circonda e, quindi, cambiano le esigenze dell’organizzazione stessa. Aumenta la complessità e nasce la necessità di trovare modi più semplici di fare le cose, magari introducendo, per quanto possibile, la cultura sperimentale.

Alcuni, pragmaticamente ci dicono che si deve cambiare perché non funzionano più i modelli precedenti di relazione oppure sarcasticamente perché “va di moda”.

Con i miei colleghi, condividiamo tutti questi punti, con un focus particolare sul tema della complessità, ma ci sentiamo di aggiungerne altri più “naif”.

Spesso una trasformazione Agile si fa:

• per creare un’organizzazione che in modo più rapido sappia reagire ai cambi di scenario e sappia rispondere alle necessità di business capendole insieme e costruendo soluzioni insieme;
• perché affermare che si sta affrontando una trasformazione agile rende attrattivi sul mercato, attirando nuovi clienti e nuovi talenti; l’organizzazione dimostra di essere all’avanguardia;
• perché spesso non si conosce il Manifesto Agile [2] con i suoi valori e principi. Sono ignote le basi da cui far partire una riflessione vera e profonda sul significato della “mentalità” agile e della sua possibile applicazione nel proprio contesto organizzativo ma, come spiegato nel punto precedente, affermare che si sta mettendo in atto una trasformazione è comunque attrattivo nei confronti del mercato.

Le pratiche agili sono nate per soddisfare necessità. Quali?

Quando chiediamo ai clienti perché vogliono fare propri i principi agili — domanda che già da sola apre a una galassia di possibili conversazioni — e quali benefici si aspettano, otteniamo un elenco piuttosto tipico di risposte:

• facilitano la visione di “abbracciare il cambiamento”;
• rendono snella l’organizzazione;
• danno ritmo all’azienda, per sfruttare meglio il tempo, per stare al passo con i tempi;
• accorciano i tempi di realizzazione del prodotto (time-to-market);
• rinnovano ciò che è vecchio;
• migliorano la comunicazione fra i dipartimenti dell’organizzazione;
• consentono di avere una pipeline bilanciata tra demand (il business) e la fabbrica del prodotto (p.e. team di sviluppo).

A noi piace sinteticamente dire che le metodologie agili aiutano a ridurre il rischio di:

• fare le cose sbagliate;
• fare le cose male;
• fare le cose troppo tardi.

Un’organizzazione che apprende

Le pratiche agili aiutano a fare le cose nel modo corretto, con qualità ed evitando sprechi causati da attività non necessarie.

Per ridurre il time-to-market e gli sprechi è necessario avere come valore il focus sull’utente che deve stare al centro dei propri sforzi (customer centricity) e puntare alla qualità lavorando con tecnologie e persone giuste.

Le iterazioni brevi, il feedback continuo e i team verticali capaci di seguire il processo end-to-end del prodotto, diminuiscono il rischio di fare le cose male.

Agile non è “fare il doppio in metà tempo”, ma è essere capaci di capire prima quali sono le cose sbagliate, in modo da non farle. C’è un famoso libro, infatti, il cui titolo recita proprio che Agile è fare il doppio delle cose nella metà del tempo, affermazione che purtroppo è stata travisata: questo concetto (Agile = riuscire anche a fare più cose) è formalmente corretto, ma attenzione che essere agili non vuol dire lavorare più velocemente o essere più performanti. Vuol dire, invece, focalizzare le energie su ciò che veramente serve all’organizzazione cosa che sul lungo periodo porta a produrre più cose di valore.

Per questo, in ultima analisi, trasformare un’organizzazione significa creare un’organizzazione che apprende e che si adatta al contesto che cambia, implementando meccanismi che permettono di rispondere alle nuove esigenze e/o problematiche. Vuol dire, per esempio, installare nuove regole di collaborazione cliente-fornitore.

Passi concreti

Su cosa potremmo agire concretamente per trasformare l’organizzazione? Tante immagini vengono alla mente quando ci facciamo questa domanda. Di seguito riportiamo alcune delle affermazioni che abbiamo trovato particolarmente interessanti.

• Introdurre una logica forte sull’end-to-end significa monitorare tutta la filiera di creazione del prodotto dall’ideazione fino al rilascio, tenendo sotto controllo il valore rilasciato ad ogni iterazione.
• Agire sul design organizzativo, favorendo modelli di organizzazione aziendale che permettano la collaborazione tra i team; facilitare la nascita di team funzionali, in grado cioè di rilasciare prodotti — o parti significative di essi — funzionanti in modo autonomo lungo tutta la filiera.
• Accorciare i cicli di lavorazione, rilasciare in modo incrementale: aumentare la frequenza dei rilasci in produzione dando all’utente qualcosa di utilizzabile con successo e soddisfazione, spezzare un progetto molto lungo in parti più piccole in maniera iterativa e incrementale.
• Trasformare una sola area, anche come input per poi trasformare tutta l’organizzazione.

In che modo misuriamo il successo della trasformazione?

Ogni trasformazione organizzativa dovrebbe portare a un’analisi dei benefici di business concreti e quella Agile non deve fare eccezione.

Per esempio, creare un clima di lavoro sereno e far sì che i dipendenti “stiano bene in azienda” sono obiettivi nobili che in ultima istanza devono permettere di lavorare meglio in modo continuo e costante.

Per questo pensiamo che, prima di tutto, la trasformazione dovrebbe incidere sui tempi e costi di lavorazione tenendo la qualità come obiettivo (non come metrica).

Quindi ogni cambiamento che porterete — e suggeriamo di portarne tanti piccoli in modo costante e inarrestabile — dovrebbe essere misurato considerando questi indicatori:

• costi;
• time-to-market;
• soddisfazione dei clienti e delle diverse figure coinvolte nel processo (es. le UX Metrics).

Metriche indirette

A volte può essere utile usare metriche indirette che sono più semplici da applicare e offrono interessanti suggerimenti per agire. Per esempio potremmo valutare “pseudometriche” riportate di seguito.

• misurare l’autonomia delle persone nel portare avanti il lavoro;
• monitorare il cambiamento del modello di comando: misurare il tempo di decisione e il tempo necessario per l’implementazione di tali decisioni; lo scopo è prendere decisioni più velocemente, con meno burocrazia e maggiore autonomia dei team;
• controllare il numero di persone necessarie per fare una data attività per rilasciare valore in produzione.

Come si fa una trasformazione?

Rispondere a questa domanda non è semplice. Ne parleremo più diffusamente nel prossimo numero. Ma occorre cominciare già qui, introducendo un concetto semplice ma spesso non chiarissimo. Per operare una trasformazione in senso Agile di un’oganizzazione, non si parte da qualche documento o regolamento da imporre a tutti. Si tratta al contrario di far emergere, pazientemente, la presa di consapevolezza delle proprie specifiche esigenze e la scelta delle azioni da intraprendere per mettere in pratica principi e pratiche Agile nel proprio contesto.

E questo si fa con un’operazione di coaching che, propriamente, non è consulenza e non è formazione, anche se ci sono vari punti di contatto. A tal proposito, consigliamo la lettura dell’articolo “Babbo, ma te che lavoro fai?” del 2016 che resta sempre valido e che ripubblichiamo nello stesso numero del presente per una più facile consultazione.

Come facciamo coaching

Quello che descriviamo qui di seguito è l’approccio al coaching — e quindi alla trasformazione — che seguiamo nella mia azienda. È valido, provato sul campo e fornisce risultati. Ma, come ho già scritto sopra, non ha la pretesa di essere l’unico applicabile né il migliore possibile.

All’inizio dell’ingaggio, la presenza degli agile coach è importante. Affianchiamo il cliente nell’individuare le attività da fare e nello stabilire la strategia: il nostro supporto attraverso la formazione e il coaching consente di partire dalle basi.

Nel corso dell’apprendimento del mindset e delle pratiche agili, i diversi gruppi di lavoro e le altre figure coinvolte cominciano a sperimentare e agiscono in prima persona.

Gradualmente, le persone interne all’organizzazione iniziano ad avere un ruolo attivo e i nostri coach passano a essere osservatori e facilitatori.

A tendere, l’agile coach può uscire di scena e il cliente inizia usare gli strumenti e le capacità per affrontare in autonomia le sfide e le problematiche del mercato.

Conclusioni

Nel prossimo articolo, concluderemo il discorso sulle trasformazioni agili continuando a presentare considerazioni ed esempi provenienti da reali esempi di evoluzione, cambiamento e metamorfosi dell’organizzazione aziendale in senso Agile.

Riferimenti

[1] Giovanni Puliti su AgileReloaded
https://agilereloaded.it/chi-siamo/giovanni-puliti/

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