Business Agility: navigare in acque perigliose

Prima di iniziare…

Ogni volta che affrontiamo un cambiamento non possiamo non tenere in considerazione il concetto di rischio. Dopotutto ogni attività della nostra vita ha un rischio di insuccesso, che può provocare un danno sia a chi compie l’azione, sia a chi ne è affetto. E lo stesso vale ovviamente per le aziende che vogliono trasformarsi in organizzazioni agili.

Di seguito un’immagine che riporta le risposte date dai presenti ad una domanda posta da Fabio:

Come potete vedere, quando si parla di Business Agility, il rischio c’è. È interessante notare come parole quali “persone al centro”, “rilasci frequenti”, “coinvolgimento del cliente” siano tutti richiami ai principi e valori del Manifesto Agile. Ed è giusto che sia così, a 20 anni di distanza dalla nascita del movimento.

Dal 2001 ad oggi, dal Manifesto Agile alla Business Agility

Tutto iniziò nel 2001, quando un gruppo di persone si riunì per parlare e trovare una soluzione per soddisfare un’esigenza comune: scrivere software migliore, in una maniera diversa. Più leggera.
Come potete capire, il beneficio fu per un contesto piccolo, ristretto e definito, quindi ben diverso da quello attuale di molte aziende. Le aziende, allora come oggi, si muovono in contesti più ampi, formati e vissuti da tante persone, ognuna con diversi ruoli e responsabilità, che lavorano in progetti sempre più grandi e complessi.

Ecco che, intorno al 2008, nacque il concetto di Scaling, ovvero poter applicare lo stesso schema/concetto a più gruppi, per progetti più grandi e complessi. Lo scaling nacque quindi da un’esigenza diversa.

La storia prosegue e si arriva al 2014, quando venne coniato il concetto di Business Agility: estendere i principi e le pratiche Agili a tutti i reparti di un’organizzazione: business, marketing, HR, ecc.

È evidente, da questo excursus, un collegamento tra il Movimento Agile nato nel 2001 e la Business Agility.

Ciò che è sicuramente cambiato è il contesto.

Il contesto attuale

V.U.C.A.

Come accennato all’inizio dell’articolo, viviamo in un mondo in continua evoluzione. Il World Wide Web, tutte le applicazioni e la tecnologia in generale, portano disruption, o cambiamento (si pensi alla rapidissima ascesa di TikTok). Dobbiamo farci trovare pronti e soprattutto saper reagire velocemente.
Pensando al nostro settore, sempre più ambiti vedranno applicazioni di intelligenza artificiale, e i progetti saranno sempre più grandi e complessi.
Per farla breve, avremo a che fare con un ambiente sempre più complicato e incontrollabile, a complessità crescente, sintetizzabile con un acronimo: V.U.C.A.

Questo acronimo sintetizza quattro concetti:

• Volatility (Volatilità): la velocità, il ritmo del cambiamento e le sue dinamiche in un dato contesto, (come ad esempio il mercato economico). Maggiore è la volatilità, più i cambiamenti sono veloci.
• Uncertainty (Incertezza): indica la misura con cui è possibile prevedere con sicurezza il futuro. Più il mondo è incerto, più è difficile da prevedere.
• Complexity (Complessità): l’apporto del cambiamento. Un contesto è tanto più complesso quanto più i fattori da considerare sono numerosi, diversi tra loro e diverse sono le relazioni tra gli elementi. Più il mondo è complesso, più difficile sarà da analizzare.
• Ambiguity (Ambiguità): una situazione è ambigua quando l’informazione è incompleta, contraddittoria o inaccurata, per giungere a delle conclusioni.

Il cono dell’incertezza

C’è un’altra considerazione da fare, e riguarda il cosiddetto “cono dell’incertezza”: alcuni studi universitari dimostrano che all’inizio di un progetto le stime fatte hanno un fattore di incertezza che va da 4 a 0.25.

Dalla pagina Wikipedia

“Questo significa che il lavoro (o il costo) effettivo di un progetto è statisticamente compreso in un intervallo che va da 4 volte a 1/4 della stima iniziale.”

Incertezza è un termine che ci richiama a pensieri su cosa sappiamo e cosa no. Se sapessimo, tutto sarebbe più semplice.

Riprendendo il modello Cynefin, possiamo classificare i progetti in uno dei seguenti quattro quadranti:

• Ovvio – Tutto è noto, ogni problema è chiaro e se ne conosce la soluzione.
• Complicato – Potrebbero esserci più soluzioni al problema, la relazione causa-effetto non è chiara e necessita di analisi. Si ha bisogno della consulenza di esperti di dominio per colmare le lacune.
• Complesso – Analizzare il problema non è sufficiente, entrano in gioco altre variabili e fattori. Nei problemi complessi abbiamo tanti elementi che si condizionano l’un l’altro in modo non noto a priori.
• Caotico – In questa categoria rientrano i problemi in situazioni di totale emergenza, si pensi come scenario a quanto purtroppo accaduto al World Trade Center nel 2001…scenario di confusione ed emergenza assoluti, non c’è ordine, non c’è tempo di fare analisi prima di agire.

La risposta “tradizionale”

A questi problemi d’incertezza abbiamo una risposta tradizionale, tipica del modello a cascata o Waterfall, ma senza avere certezza:

1. Decidere quando l’incertezza è massima: facciamo le stime e allochiamo persone e tempo. Prendiamo decisioni e azioni nell’incertezza.
2. Costruiamo un sistema che ci permetta di gestire il rischio.
3. Frammentiamo le varie fasi del lavoro su gruppi di persone. Creiamo quindi un organigramma, suddividendo in silos l’organizzazione.
4. I diversi livelli aziendali portano inevitabilmente a scrivere tanta documentazione a svantaggio della conversazione.
5. Si avrà il prodotto solo alla fine, spesso accorgendoci che ciò che abbiamo realizzato non è ciò che si desidera o meglio “non è più ciò che si desidera”, perché nel frattempo il mondo è cambiato. Il cambiamento non è gestito.

Adottando un approccio Agile si lavorerebbe in maniera completamente diversa e non più a compartimenti stagni come avviene nel modello Waterfall.

Prima di proseguire con il suo racconto sulla Business Agility, Fabio riporta una citazione molto interessante di Marco Calzolari:

“Agile è una tra le migliori opzioni a nostra disposizione per ridurre il rischio di fare le cose sbagliate, male e fuori tempo.”

Un’affermazione che ovviamente ognuno è libero di smentire o confermare.

Che cosa è importante nella Business Agility?

Sette principi

Per Fabio sono sette i principi intorno ai quali un’azienda dovrebbe lavorare:

1. Fare esperimenti.
2. Feedback: averlo frequentemente.
3. Apprendimento, tramite condivisione della conoscenza all’interno del team e verso le altre unit aziendali.
4. Cross-funzionalità e auto-organizzazione: il team prende le decisioni in base alle competenze che risiedono al suo interno.
5. Leadership: promuovere i principi di collaborazione e partecipazione, non dare direttive. In tal senso vi invito a leggere il mio articolo sulla Host Leadership, scritto a seguito di un workshop interno gestito da Alessandro Giardina.
6. Approccio iterativo e incrementale: rilasciare poco alla volta e verificare ciclicamente ciò che viene fatto.
7. Il cliente è al centro, coinvolgerlo il più possibile. Dopotutto il terzo valore del Manifesto Agile recita “La collaborazione col cliente più che la negoziazione dei contratti“.

E se estendessimo questi principi a tutta l’azienda?

È proprio questa la sfida che ci pone la Business Agility. Un cammino suddiviso in due grosse tappe:

• Ridurre il rischio.
• Accelerare, ovvero non fare le cose necessariamente più velocemente bensì fare le cose di maggior valore il prima possibile, così da soddisfare prima i bisogni più impellenti.

Per ridurre il rischio sono tre gli ambiti, o fattori, da considerare:

• Tempo: Come lo gestiamo? Riprendendo il decimo principio Agile “La semplicità – l’arte di massimizzare la quantità di lavoro non svolto – è essenziale”. Bisogna rendere le cose semplici perciò è necessario avere processi aziendali snelli e quindi più efficaci perché fanno perdere meno tempo.
• Valore: attraverso una strategia “cliente-centrica” ovvero che abbia il cliente al centro. È importante coinvolgere il cliente sin dalle prime fasi del progetto e tenerlo aggiornato sui rilasci del prodotto, così da collezionare feedback e, in caso, correggere il tiro.
• Qualità: lavorando non solo sull’aspetto tecnologico (scrivere codice di qualità attraverso TDD, Pair Programming, ecc.) ma anche umano (crescita delle persone, delle loro skill, ecc.).

Una volta che si è trovata una quadra su questi tre ambiti, allora si può pensare di accelerare.

Le sei direttrici

Fabio, dalla sua esperienza di Agile Coach, individua sei direttrici fondamentali nella Business Agility:

• Governance: orientarsi al prodotto e non al progetto. Porre molta attenzione al flusso di lavoro e alla pianificazione delle attività.
• Design dell’organizzazione: progettare l’organigramma e i processi aziendali orientati all’aggregazione delle competenze attorno al valore.
• Leadership: deve essere decentralizzata, il leader va inteso come una persona che è al servizio delle decisioni. Il leader si mette a disposizione dell’azienda affinché le decisioni vengano prese nel posto giusto. Bisogna entrare nell’ottica che i leader e i manager fungano da “moltiplicatori del potenziale”.
• Innovazione: vivere e lavorare in un’azienda in continua evoluzione. Un’unica domanda alla base di tutto: “Come creo un’azienda innovativa?”.
• Gestione della conoscenza: bisogna costruire un sistema di conoscenza e investire su di esso. La conoscenza è l’antidoto che permette di contrastare il rischio, di ridurlo. E non dimentichiamolo, la conoscenza va sì creata, ma anche condivisa.
• Persone e cultura: passare da una struttura gerarchica a silos, a una struttura con i ruoli orientati al valore. Un luogo dove le persone possano crescere e quindi contribuire alla vita dell’azienda. Persone che possano essere protagoniste. Dopotutto il primo valore del Manifesto Agile recita “Gli individui e le interazioni più che i processi e gli strumenti“.

Conclusioni

Grazie a questo intervento di Fabio ho (e spero anche voi lettori) appreso molto sulla Business Agility. Un racconto fluido e piacevole anche grazie alle grafiche realizzate a mano con una tecnica di comunicazione molto particolare basata sulla comunicazione visiva bikablo.

Ho trovato infine molto interessante la considerazione che Fabio ci ha lasciato al termine del webinar, e cioè che

“Non esistono modelli precostituiti per implementare la Business Agility nelle aziende, esiste l’approccio empirico basato su principi ed evidenze.”

Che, ritengo personalmente, sia applicabile a tutte le azioni che svolgiamo nella nostra vita.