Un approfondimento sull'Agile Transformation...

Da ZeroUnoWeb

Agile transformation: come cambia il modo di lavorare per affrontare la trasformazione digitale

Nato nel 2001 come metodologia per la gestione dei progetti di sviluppo software, in questi anni l’Agile ha fatto molta strada, cambiando progressivamente di significato e aumentando la propria portata trasformazionale. 

In ambito IT, per diffusione e risultati raggiunti, è oggi il punto di riferimento per quanto riguarda la gestione dei progetti di trasformazione digitale. 

L’Agile sta inoltre modificando le consolidate pratiche di project management in tutti i campi, introducendo nuovi concetti e approcci orientati alla gestione del cambiamento. 

Con il concetto di business agility, l’Agile si sta oggi estendendo fino a toccare l’organizzazione aziendale complessiva e il modo di lavorare di tutte le persone, declinandosi in maniera differente nei vari ambiti.

di Marco Mazzucco, 12 giu 2019

C'è una data precisa per la nascita dell’Agile: 11-13 aprile 2001. 

In realtà le fonti di ispirazione sono di molto precedenti, risalgono agli anni ’50, e molti concetti sono in continuità con quanto già portato avanti con il lean manufacturing (filosofia gestionale nata in Giappone negli anni ’80 nel mondo automotive e volta a minimizzare gli sprechi). 

Ma quel momento è importante perché da lì è partito un movimento che oggi è più attivo e influente che mai.

Indice degli argomenti:

• Alle origini della metodologia agile, i 4 principi del Manifesto
• Perché oggi questa metodologia è così importante
• I 12 principi alla base dello sviluppo agile software
• Così cambiano i progetti di trasformazione digitale
• La metodologia agile SCRUM
• La diffusione dell’Agile a livello internazionale e in Italia
• L’impatto del lavorare in agile sull’azienda
• L’Agile per la gestione progettuale
• Business Agility: l’Agile come nuova forma organizzativa
• Il percorso del cambiamento

Alle origini della metodologia agile, i 4 principi del Manifesto

Fuori nevicava, quando, in un albergo dello Utah, 17 progettisti software e guru dell’informatica si sono riuniti per provare a risolvere un problema comune. In quegli anni l’IT, grazie al fenomeno della new economy, stava prendendo un ruolo centrale nelle strategie competitive di molte aziende, che cominciavano a intravedere nel “nuovo” fenomeno del web una potente arma di differenziazione competitiva. Era però una novità per tutti, e nessuno sapeva come affrontare questa sfida, come realizzare cioè sistemi adatti per sfruttare le potenzialità di internet e del contatto diretto con il cliente finale.

Tutti si erano accorti che, in quel contesto, la modalità tradizionale di gestire i progetti IT stava mostrando enormi limiti. Questa modalità è chiamata waterfall e può funzionare quando sono molto chiare le specifiche e il contesto non varia, ovvero quando il tasso di innovazione è molto contenuto. Nel waterfall infatti le attività sono sequenziali: all’inizio si definiscono le specifiche di dettaglio e sulla base di queste si stimano tempi e costi di progetto, che diventano subito impegnativi. A partire da questo “contratto ” interno fra l’IT e il cliente di business parte il progetto, gestito dall’IT e con un coinvolgimento molto limitato degli utenti e del business, che porterà al rilascio di un software. La bontà di quanto creato è misurata sulla rispondenza ai requisiti espressi all’inizio, non al valore effettivamente creato, e ogni richiesta di modifica viene gestita successivamente. Agendo in questo modo, spesso accade che si realizzino sistemi lontani da quanto realmente serva, si sprechi molto tempo e denaro in funzionalità inutili e si rilascino i sistemi in ritardo. Da qui tempi di risposta al mercato spesso troppo lenti, scarsa flessibilità ai cambiamenti del contesto, una naturale avversione verso l’innovazione (vista come fastidiosa dinamica di cambiamento continuo) e una cesura molto forte fra l’IT e il resto dell’azienda.

Nel 2001 (fonte Chaos report) solo il 28% dei progetti IT finiva entro i limiti di budget e tempo prefissati.

Per risolvere questo problema, dopo giorni di discussione, il gruppo non è riuscito a definire modalità precise, ma è arrivato a concordare su 4 valori, che costituiscono l’Agile manifesto.

Sono elementi semplici e di buon senso, che però nascondono un modo diametralmente diverso di organizzare la realizzazione di sistemi software.

"Gli individui e le interazioni più che i processi e gli strumenti
Il software funzionante più che la documentazione esaustiva
La collaborazione col cliente più che la negoziazione dei contratti
Rispondere al cambiamento più che seguire un piano
Ovvero, fermo restando il valore delle voci a destra, consideriamo più importanti le voci a sinistra."

Agile Manifesto

Questi valori hanno dato vita, nel corso del tempo, a metodologie applicative e a framework per guidare concretamente i progetti di sviluppo di applicazioni software. La crescente diffusione di queste metodologie e la loro comprovata utilità ha reso, come vedremo, l’Agile imprescindibile per chi oggi sviluppa applicazioni.

Gestire un progetto software con la metodologia Agile all’interno di un contesto aziendale che ragiona in maniera tradizionale è però estremamente limitante, e porta a vantaggi molto ridotti e di natura perlopiù locale e tattica. Per superare questo limite l’Agile si è pian piano fatto strada nelle aziende, andando a interessare tutte le attività connesse alla realizzazione di progetti di trasformazione digitale. L’Agile diventa quindi non solo un modo di sviluppare applicazioni, ma un modo di gestire a livello complessivo il percorso di trasformazione digitale di una azienda.

Non finisce qui. Allontanandosi dal digitale, ogni progetto gestito in azienda può avvalersi dei benefici portati da questo nuovo modo di pensare. Da qui nasce una rivisitazione delle tradizionali modalità di gestione progettuale (Agile Project Management), che oggi vedono nell’Agile un forte stimolo per ripensare pratiche e strumenti non più al passo con i tempi attuali.

L’ultimo passo in questa direzione vede l’Agile incontrarsi con riflessioni di natura organizzativa che riguardano l’azienda nella sua interezza e che si sono sviluppate ormai da molti anni e che hanno trovato diversi nomi e modalità risolutive.

Sotto il concetto di Business Agility si rappresenta oggi la convergenza fra quanto portato avanti, anche se in contesti diversi, dal movimento Agile, e le numerose riflessioni organizzative che stanno facendo evolvere i paradigmi tradizionali. Pur con applicazioni pratiche molto differenti da caso a caso, i principi alla base sono gli stessi e sono quelli che oggi stanno riplasmando sempre più organizzazioni nel mondo (figura 1).

Figura 1 – Agile: dallo sviluppo software alla trasformazione del business – Fonte: immagine dell’autore

Perché oggi questa metodologia è così importante

Lo ha detto bene Steve Denning, in un articolo su Forbes del gennaio 2018: Agile is eating the world.

Ovvero, le aziende che adottano, anche senza chiamarli in questo modo, i principi dell’Agile sono quelle che vincono la sfida competitiva del mercato e che stanno avendo sempre più successo. È l’innovazione manageriale, più che specifici prodotti o servizi, ad aver reso grandi e vincenti sempre più organizzazioni in diversi settori.

La rivoluzione nasce certamente dal settore digitale, ed è qui che si trovano più esempi e meno casi isolati. Questo perché essendo la produzione di applicazioni l’elemento chiave di queste aziende, l’Agile è diventato il modo più naturale e proficuo di operare. Oggi infatti tutte le principali imprese del digitale che hanno successo hanno adottato, in tutte le sue sfumature, peculiarità e diversità, l’Agile.

Ma la trasformazione digitale non si ferma a questo settore, sta molto velocemente andando a cambiare le regole e i differenziali competitivi di tutti i mercati. Prendiamo come metafora il Digital Vortex (pubblicato nel 2015 e aggiornato nel 2017 dal Global Center for Digital Business Transformation): il digitale è un vortice che attrae verso il proprio centro tutti i settori per trasformarli definitivamente (figura 2). Alcuni settori sono più lontani, altri più vicini all’occhio del ciclone, ma nessuno è immune. Questo per tutta una serie di fenomeni trasversali:

la crescita della componente di servizio nei prodotti, anche in quelli tradizionali, che può essere digitalizzata per essere più efficiente e personalizzata;

lo sviluppo delle modalità di interazione con i clienti, che avvengono sempre più sui media digitali;

il cambiamento delle modalità di lavoro all’interno delle aziende, che possono beneficiare delle nuove tecnologie sia per rendere più efficace il lavoro dei knowledge worker (ovvero di tutti gli impiegati, manager, venditori, …) sia per migliorare i processi produttivi (pensiamo ad esempio all’impatto dell’industry 4.0).

Figura 2 – Il Digital Vortex che attrae verso il proprio centro tutti i settori per trasformarli definitivamente –
Fonte: Global Center for Digital Business Transformation

Questi fenomeni evidenziano che il mondo del digitale, in costante evoluzione e accelerazione, sta diventando il centro nevralgico delle sfide competitive delle aziende in tutti i settori.

Ma come fanno le aziende a tenere il passo con questa accelerazione?

Quello che accade è ben rappresentato dalla cosiddetta “legge di Martec”(di Scott Brinner): mentre la tecnologia evolve a un tasso esponenziale, le organizzazioni evolvono a un tasso logaritmico, ovvero fanno sempre più fatica a cambiare. Più le organizzazioni sono strutturate e grandi, più questa fatica aumenta. Cambiare è possibile, ma è molto faticoso, costoso e avviene in tempi molto lenti.

Quello che accade è che il divario fra queste due traiettorie aumenta nel tempo (figura 3) e porta le aziende a dire: come faccio a uscire da questo vincolo e a essere più veloce ad inseguire il mercato?

Figura 3 – La legge di Martec: mentre la tecnologia evolve a un tasso esponenziale, le organizzazioni
evolvono a un tasso logaritmico, ovvero fanno sempre più fatica a cambiare – Fonte: Scott Brinner

Emerge qui il mito delle startup: aziende molto snelle, molto focalizzate, nativamente agili, che riescono a entrare direttamente sulla curva di evoluzione del contesto e a cavalcarla, portando in molti casi delle innovazioni disruptive per interi settori di mercato. In una startup non ci sono procedure, burocrazie, logiche di potere che si frappongono fra l’individuazione di un bisogno e la realizzazione del massimo sforzo possibile per realizzare una risposta vincente. Il punto di riferimento è perciò la velocità e la reattività con cui le startup riescono ad affrontare problemi di mercato e dare risposte rapide.

L’Agile porta questo tipo di promessa: riuscire, anche su scale più grandi, a mantenere quelle stesse caratteristiche per rendere le aziende capaci di trasformare le possibili minacce che arrivano dal contesto esterno in opportunità.

Non solo, la promessa dell’Agile è anche quella di motivare maggiormente le persone, attrarre talenti, ridurre i costi della burocrazia e degli overhead manageriali.

Tutti elementi che, messi insieme, rendono oggi l’Agile un imperativo, una vera e propria necessità per vincere le sfide che le aziende sentono sempre di più sulla propria pelle.

I 12 principi alla base dello sviluppo agile software

Come abbiamo scritto, l’Agile nasce nell’ambito dello sviluppo software e i punti del Manifesto cui ci si riferisce parlando di questa metodologia parlano espressamente di questo. Nel Manifesto i valori vengono declinati in 12 principi, che portano maggiore concretezza:

1. La nostra priorità numero uno è soddisfare il cliente rilasciando continuamente e il prima possibile prodotti software che generino valore.
2. Le modifiche ai requisiti sono benvenute, anche a sviluppo già iniziato. I processi Agile sfruttano i cambiamenti per garantire al cliente un vantaggio competitivo.
3. Rilasciamo frequentemente software funzionante, a intervalli che possono andare da un paio di settimane a un paio di mesi, dando preferenza ai periodi più brevi.
4. Le persone del business e gli sviluppatori devono lavorare insieme ogni giorno per tutta la durata del progetto.
5. I progetti sono portati avanti da persone motivate, cui abbiamo fornito le risorse e l’ambiente necessari per lavorare, fiduciosi che loro porteranno a termine il lavoro.
6. Il modo più efficace ed efficiente di trasmettere le informazioni in un team di sviluppo è la comunicazione faccia a faccia.
7. Il software funzionante è la più importante misura di avanzamento dei lavori.
8. I processi Agile promuovono lo sviluppo sostenibile. Sponsor, sviluppatori e utenti devono essere in grado di mantenere un ritmo di lavoro costante per un periodo di tempo indefinito.
9. L’attenzione costante alla buona progettazione e all’eccellenza tecnica aumenta l’agilità.
10. La semplicità, ovvero l’arte di massimizzare il lavoro che non viene fatto, è essenziale.
11. Le migliori architetture, requisiti e progetti sono realizzate da team che si organizzano da soli.
12. A intervalli regolari il team deve riflettere su come diventare più efficace e modificare di conseguenza il proprio modo di agire.

Astraendo questi principi dallo sviluppo software, è possibile definire delle modalità di funzionamento dell’Agile di portata ben più ampia e applicabili in qualsiasi contesto. I punti chiave sono i seguenti:

• L’elemento organizzativo primario sono i team, che devono essere snelli e focalizzati, con al proprio interno tutte le competenze necessarie per realizzare l’obiettivo minimizzando le interdipendenze esterne;
• I team non hanno manager ma le persone si auto-organizzano seguendo una serie di pratiche comuni;
• Il lavoro è suddiviso temporalmente in iterazioni, all’interno delle quali si svolgono le attività a maggior valore e al termine delle quali si possono ridefinire le priorità;
• Siccome nessuno sa cosa può realmente funzionare o essere di valore, occorre realizzare il maggior numero possibile di esperimenti a basso costo e rapidi;
• Il feedback, dato dal mercato o da diversi stakeholder, è il motore fondamentale dell’apprendimento e permette al team di trovare la strada migliore per raggiungere il suo obiettivo;
• All’interno del team non esistono divisioni, le comunicazioni sono simmetriche e frequenti;
• I team riflettono regolarmente sul proprio modo di funzionare e collaborare e cercano di migliorare continuamente.

Questi principi, per essere adottati, non hanno solo implicazioni di carattere metodologico, ma richiedono un forte cambiamento di mentalità nel modo con cui le persone affrontano e risolvono i problemi, e soprattutto un forte cambiamento negli stili di leadership. Si passa infatti da stili di leadership ” command & control” a concetti di “servant leadership”, dove la leadership non è più prerogativa del manager ma una capacità che va diffusa e coltivata ovunque nell’organizzazione. È solo il rinforzo fra un profondo cambiamento culturale e l’instaurarsi di pratiche operative concrete che permette a una organizzazione di rendere reali ed efficaci questi principi.

Negli ultimi anni sono nati molti framework che definiscono a livello più operativo strumenti e metodologie per calare nella specifica organizzazione queste pratiche e per passare da una dimensione di team a quella dell’intera organizzazione. Fra i più consolidati citiamo SCRUM con le relative modalità di scaling (che poi approfondiremo), Holacracy (di Brian Robertson) e Sociocracy (giunta alla versione 3.0), ma ce ne sono molti altri.

In ogni caso, pur essendo questi framework e queste metodologie utili, ogni azienda segue una propria strada peculiare e diversa da quella di tutte le altre. Se già a livello di team le metodologie ortodosse sono difficilmente applicabili, data la diversità dei contesti reali e delle condizioni al contorno, più si sale a livello complessivo più questo è vero e ogni azienda si trova ad esplorare un proprio percorso peculiare e unico.

Così cambiano i progetti di trasformazione digitale

L’ambito più naturale e proficuo per l’applicazione dell’Agile è la gestione dei progetti di trasformazione digitale, dove esiste una componente importante di sviluppo applicativo e dove è richiesto un elevato livello di flessibilità, velocità di risposta e innovazione.

La metodologia agile SCRUM

In questo ambito la metodologia di gran lunga più diffusa, pur se, come detto, ogni azienda adotta delle varianti specifiche, è SCRUM (figura 4), che nasce addirittura alla fine degli anni ’80 dall’esperienza di Ken Schwaber e Jeff Sutherland (due dei 17 firmatari del Manifesto Agile).

SCRUM prende il nome dalle mischie del rugby, dove tutti gli uomini spingono insieme nella stessa direzione. Questo è il principio alla base di SCRUM: fare in modo che tutti i membri del team lavorino coordinati verso il medesimo obiettivo.

Figura 4 – La metodologia SCRUM

Nella pratica questa metodologia è caratterizzata dai seguenti elementi:

• focus sul lavoro all’interno di team dedicati a specifici obiettivi di sviluppo applicativo, composti da non più di 10 persone;
• i ruoli sono quelli del Product Owner, che definisce obiettivi e priorità, e dello SCRUM Master, che facilita il lavoro dei membri del team, mentre tutti gli altri sono semplici componenti del team;
• lo sviluppo del software è gestito tramite un “product backlog“, ovvero una lista prioritizzata di funzionalità (chiamate storie);
• Il lavoro è organizzato per iterazioni, chiamate sprint, della durata di 2-4 settimane, durante le quali si realizzano le storie a maggiore priorità;
• esistono diversi eventi per permettere al team di lavorare bene insieme: brevi stand up meeting giornalieri per il coordinamento continuo, sprint planning meeting per definire cosa fare in uno sprint, sprint review per condividere i risultati del lavoro realizzato all’interno di uno sprint, e retrospective, per riflettere sulle modalità di lavoro e migliorarle;
• l’analisi di dettaglio è fatta all’ultimo momento possibile per permettere di raccogliere maggiori informazioni e sono introdotte forme collaborative di analisi e progettazione improntate ad ottenere una piena comprensione e condivisione di funzionalità e priorità (come ad esempio lo user story mapping).

Lavorando in questo modo il team è in grado di accogliere a valle di ogni sprint i feedback da parte dei diversi stakeholder e riprogrammare di conseguenza le proprie attività, garantendo quindi massima flessibilità. Le persone sono responsabili delle storie assegnate e si coordinano frequentemente per evitare asimmetrie informative e per migliorare di continuo.

Questo approccio permette di definire inoltre molto chiaramente le priorità di un prodotto, evitando di realizzare funzionalità non utili, e di inserire metriche precise per verificare l’andamento del progetto e dare massimo controllo su quello che viene realizzato.

In quest’ottica, siccome lo scope del progetto può variare sulla base del cambiamento del contesto, è possibile fissare inizialmente tempi e costi: il team ha l’obiettivo di massimizzare il valore prodotto all’interno di questi vincoli, evitando di realizzare funzionalità non utili.

Oltre a essere applicato ai singoli team di sviluppo, SCRUM può essere utilizzato anche da unità più ampie, coordinando il lavoro di diversi team all’interno della stessa organizzazione. Per questo obiettivo esistono diverse metodologie: le più note sono SAFe (Scaled Agile Framework), Less (Large Scale SCRUM), Scrum of Scrum, DaD (Disciplined Agile Delivery) e Nexus.

L’utilizzo di SCRUM si è dimostrato estremamente utile nel corso degli anni e ha prodotto significativi risultati sull’andamento dei progetti. Mentre ancora oggi, secondo il Chaos Report (figura 5), il 21% dei progetti fallisce e il 53% è critico, utilizzando la metodologia Agile solo l’8% fallisce e il 50% è critico, portando dal 26 al 42% i progetti conclusi con successo.

Figura 5 – Waterfall e Agile: successi e fallimenti a confronto – Fonte: Standish Group Chaos Studies 2013 – 2017

La diffusione dell’Agile a livello internazionale e in Italia

Se negli anni passati l’Agile veniva visto come una metodologia applicabile in contesti limitati e a basso rischio, oggi questi vincoli sono stati superati e i CIO concordano che di questo approccio possano beneficiarne tutti i progetti. Si parlava qualche anno fa di IT-bimodale: una direzione IT capace di operare dividendo i progetti in due categorie, quelli che necessitavano velocità e innovazione e quelli che richiedevano sicurezza e continuità. Due tipologie di progetti, con due modalità organizzative, processi e metodi differenti. Questo approccio, alla prova dei fatti, si è rivelato miope e poco applicabile. Oggi questo concetto è del tutto superato e le aziende vedono nell’Agile una modalità per guidare una trasformazione complessiva del proprio modo di operare.

I benefici sono infatti tanti, anche se con peso differente sulle diverse tipologie di progetto, e l’unico freno è dato dal costo legato all’apprendimento di questa nuova modalità. Secondo il Tavolo di lavoro Agile degli Osservatori Digital Innovation del Politecnico di Milano, i principali benefici sono infatti la maggiore flessibilità alle richieste di modifica e la maggiore tempestività di risposta, legati ad aree a forte innovazione dove le richieste non sono chiare fin da subito e dove occorre essere molto rapidi. Come benefici sono anche segnalati l’aumento dell’efficienza operativa, la riduzione dei tempi e l’aumento del controllo, che segnalano come l’Agile permetta in ogni caso di realizzare progetti minimizzando i rischi e con maggiore efficienza. Infine, le aziende segnalano una maggiore soddisfazione degli utenti finali e il miglioramento del rapporto fra Direzione IT e Line of Business, a riprova del maggior valore finale generato da questo approccio.

A fronte di questi benefici, e nonostante il tempo passato dalla nascita del movimento Agile, è solo nell’ultimo periodo che la sua diffusione è fortemente accelerata.

Secondo il 12° State of Agile Report (survey globale sull’adozione dell’Agile) del 2018, oggi nel 52% delle organizzazioni più di metà dei team adotta l’Agile, e solo il 2% non ha team Agile.

In Italia, secondo il Tavolo di lavoro Agile degli Osservatori Digital Innovation, la situazione è diversa ma in forte crescita: se nel 2017 il 20% delle imprese dichiarava di non utilizzare in alcun modo l’Agile, nel 2018 questa percentuale è scesa al 10%, mentre è salito dal 2% al 10% la percentuale di aziende che è completamente Agile (figura 6). Sembra quindi che anche in Italia si siano vinte le iniziali ritrosie e diffidenze e oggi le aziende cerchino di recuperare velocemente terreno.

Figura 6 – Adozione della metodologia Agile in Italia – Fonte: Osservatori Digital Innovation del Politecnico di Milano

L’impatto del lavorare in agile sull’azienda

Il percorso di adozione è quindi tracciato, ma i tempi sono lunghi e le problematiche da affrontare numerose. Ancora oggi in Italia il primo problema è la mancanza di competenze e conoscenze adeguate all’interno delle organizzazioni, seguito dalla forte resistenza al cambiamento che le persone oppongono dato l’elevato impatto di queste nuove modalità.

In effetti l’Agile, se lo si vuole adottare appieno, ha un impatto profondo e molto ampio, che non si limita a toccare la sola Direzione IT. La Direzione IT è però senz’altro la prima a dover ripensare le proprie logiche di funzionamento.

A livello organizzativo la centralità dei team si scontra con i silos organizzativi preesistenti, andando a mettere in discussione l’utilità di tutto il middle management. A livello di competenze occorre integrare e sviluppare i nuovi ruoli; occorre inoltre evitare la tendenza a sviluppare competenze tecniche specialistiche, cosa che ostacola la collaborazione, prediligendo uno spettro di competenze più ampio (secondo il modello “T-shaped“, che vede lo sviluppo di competenze verticali profonde affiancato dallo sviluppo di competenze orizzontali meno approfondite), (figura 7).

Figura 7 – Modello T-Shaped delle competenze – Fonte: immagine dell’autore

Per realizzare software di qualità non ci si può però fermare solo a pratiche organizzative, ma occorre entrare nel lavoro degli sviluppatori. L’Agile mira all’eccellenza tecnica e quindi si accompagna con tecniche di sviluppo avanzate, quali l’Extreme Programming, che fa leva ad esempio su tecniche di pair programming (programmazione in coppia) e sulla test automation. Fondamentale diventa il concetto di continuous integration, per poter avere sempre un software funzionante e completo in tutte le sue parti, garantendo che le parti di codice scritte da diversi membri del team funzionino insieme senza errori, grazie anche alle pratiche di Test Driven Development (TDD), dove i test automatici vengono realizzati prima della scrittura del codice, permettendo di verificare in maniera automatica e frequente il corretto funzionamento del sistema.

L’attenzione posta alla rapidità nel rilasciare software funzionante all’interno dei team Agile si scontra però spesso con il passaggio in esercizio delle applicazioni realizzate, cosa fondamentale se si vogliono fare rilasci frequenti di modo da avere più feedback possibili.

Nelle Direzioni IT i team di Operations, incaricati di gestire con sicurezza il passaggio in produzione delle applicazioni, hanno però spesso cultura e obiettivi molto differenti. Lontani dagli obiettivi di business e dal ritmo dei team di sviluppo, vedono le attività come una sequenza di task principalmente manuali che devono essere realizzati in apposite finestre temporali per minimizzare il rischio di disservizi. In questa situazione, pur applicando la metodologia Agile, un’azienda può essere estremamente lenta, in grado di fare pochi rilasci all’anno dei propri software. Per risolvere questa problematica si è sviluppato negli scorsi anni il concetto di DevOps: una serie di pratiche e metodologie per unire la parte di sviluppo applicativo con quella di messa in esercizio eleminando le barriere fra questi due mondi e permettendo un passaggio fluido e rapido delle applicazioni in esercizio. L’elemento chiave del DevOps è l’automazione dei diversi passaggi, di modo da renderli replicabili e a basso contenuto di attività umane. Grazie a queste modalità è possibile passare a rilasci estremamente frequenti, anche più volte al giorno, in maniera sicura, permettendo di scaricare a terra le potenzialità dell’Agile.

L’altro elemento che spesso è bloccante per l’Agile è il ricorso a fornitori esterni per le attività operative di sviluppo, cosa sempre più frequente oggigiorno e figlia di un processo di delocalizzazione spinto da una lotta per la riduzione dei costi IT. Con le tradizionali modalità contrattuali e i tradizionali processi di acquisto, un’azienda si trova vincolata e difficilmente potrà essere sufficientemente flessibile. Solitamente infatti i processi di acquisto sono lunghi e burocratici, con logiche di contrattazione orientate al minor costo e basate su contratti a corpo, che hanno scope definito fin dall’inizio ed elevata rigidità per spostare il rischio sui fornitori. In questa situazione ci vuole molto tempo per partire con le attività di sviluppo, i fornitori sono vincolati e non possono assecondare, se non per eccezione, i cambiamenti di specifica.

Anche qui occorre intervenire in maniera decisa: è innanzitutto un problema culturale: le persone del procurement devono uscire da un approccio rigido e burocratico e abbracciare gli obiettivi finali di business connessi ad ogni progetto. Nascono allora obiettivi diversi per le persone del procurement, nuove forme contrattuali che privilegiano il time & material o forme analoghe, processi che consentono di partire velocemente garantendo però la possibilità di interrompere le collaborazioni con facilità nel caso ci siano problemi. Il punto chiave è instaurare con i fornitori relazioni di partnership, le uniche che permettano di investire congiuntamente per sviluppare nuove modalità di lavoro e di uscire da un approccio negoziale che porta le due parti, inevitabilmente, a tirare in direzioni opposte.

Risolto anche questo problema, l’Agile permette di sviluppare meglio il software, in maniera più efficiente e flessibile, ma rischia di essere solo una ottimizzazione locale se rimane confinato nella Direzione IT. Purtroppo, questo accade oggi molto spesso: la Direzione IT preferisce seguire una via esclusivamente interna, senz’altro più comoda. Non affronta la sfida più importante e difficile: il cambiamento delle relazioni e del ruolo delle Line of Business.

È qui che l’Agile smette di essere solo un sistema di software development e diventa un sistema per la gestione dei progetti di trasformazione digitale. Coinvolgere il business vuol dire:

• avere dei team, senza divisioni e barriere interne, composti sia da risorse IT che da risorse di business, che sappiano anteporre gli obiettivi e le priorità del progetto a quelli della propria funzione;
• dare al business piena responsabilità sulle priorità e sui risultati dei progetti, che non sono più visti come “progetti IT” ma innanzitutto come progetti di trasformazione del business;
• avere un budget di progetto comune, che non sia dominio dell’IT o delle Line of Business.

Queste considerazioni implicano una trasformazione, sia di competenze che organizzativa, anche nelle Line of Business. Queste devono esprimere dei product owner con la delega necessaria per poter decidere sui progetti e nel contempo lavorare a stretto contatto con il team. Questo implica un forte processo di delega e un lavoro costante di confronto con le strategie dei diversi stakeholder, cosa che richiede ad alti livelli la presenza di una forte vision e di un sistema di obiettivi coerente e armonico. Anche i processi di pianificazione e di budgeting, che spesso sono i più rigidi e difficili da modificare, devono evolversi per consentire un approccio realmente agile. È a questi livelli che, spesso, si incontrano le maggiori difficoltà e si fa più fatica ad intervenire.

Come mettere a disposizione gli strumenti di cui ogni dipendente ha bisogno, da qualsiasi dispositivo stia lavorando? Clicca qui e scoprilo in questo Case Study

L’Agile per la gestione progettuale

Tutti i concetti fin qui visti possono essere applicati non solo per la gestione dei progetti di trasformazione digitale, ma anche su tutti i progetti che una azienda deve affrontare. Più le specifiche iniziali sono difficili da individuare e congelare, e più è elevato il tasso di innovazione richiesto, più l’Agile è una soluzione.

Le tradizionali metodologie di project management sono figlie di un mondo e di una visione della realtà improntate alla stabilità e di conseguenza alla prevedibilità e alla ricerca dell’ottimizzazione. Da questa visione nascono gli approcci e gli strumenti che i project manager imparano ad utilizzare, salvo poi scontrarsi con frustrazione con l’imprevedibilità che ogni progetto comporta. Il cambiamento è oggi la regola, non l’eccezione, e quindi occorre imparare a gestirlo, non a nasconderlo.

Confrontando le tradizionali modalità di project management con l’Agile project management, queste sono le principali differenze:

• l’Agile tende a mettere la soddisfazione del cliente al centro, non tanto la rispondenza a specifiche predefinite;
• si passa da un controllo correttivo, volto a eliminare il cambiamento, a una gestione adattiva del piano di progetto;
• la pianificazione non è più predefinita e dettagliata, ma diventa dinamica e maggiormente strategica;
• le attività non sono più pensate in logica sequenziale, ma il progetto è suddiviso in iterazioni in grado di produrre deliverable concreti e testabili;
• scompare la figura del project manager intesa come capo gerarchico del team di lavoro, in quanto i team sono autogestiti;
• si riducono i processi burocratici di controllo del progetto, sostituiti da metriche generate ed utilizzate all’interno del team.

Questo nuovo approccio permette di migliorare il controllo dei progetti riducendo in tal modo il rischio di sforare in maniera considerevole tempi e costi. È inoltre indicato quando, grazie all’approccio iterativo e incrementale, si vogliono ottenere il prima possibile benefici concreti o si pensa di dover gestire cambiamenti di scenario frequenti.

Rispetto alle logiche classiche di project management, orientate alla pianificazione e al rispetto dei piani predisposti, la differenza è notevole. Non in tutti i progetti è però possibile, o sensato, applicare questi concetti appieno. Occorre capire, progetto per progetto, cosa è realmente applicabile e quali sono i benefici concreti che un approccio di questo tipo può dare.

Questo cambiamento nelle metodologie di gestione progettuale è talmente importante che vede oggi come promotori tutte le principali associazioni di project management, che stanno sviluppando nuovi approcci e nuove certificazioni. Ricordiamo in particolare la certificazione Agile PM di APMGInternational, il PMI Agile Certified Practitioner del Project Management Institute, la Prince2 Agile Project management certification e il Certified Agile Project Manager di IAPM (International Association of Project Managers).

Business Agility: l’Agile come nuova forma organizzativa

L’idea che l’Agile non si limiti solo alla gestione progettuale è intrinseca alla metodologia stessa, che infatti cerca di superare il concetto di “progetto” e si focalizza sul concetto di “prodotto”. Mentre i progetti possono infatti essere molto numerosi, ad elevata interdipendenza gli uni con gli altri, e hanno inizio e fine, l’Agile propone un modello dove si identificano pochi “prodotti” e ad essi si associano team stabili in grado di farli evolvere nel tempo. Questa continuità contribuisce a rafforzare le relazioni e la capacità di collaborazione all’interno dei team e consente di mantenere il know how e la capacità di far evolvere dei sistemi digitali che, al giorno d’oggi, non possono essere mai considerati finiti ma che si devono sempre evolvere.

Estendendo questo concetto, l’Agile non trova quindi collocazione solo in una dimensione progettuale, ma può essere utilizzato per gestire lo svolgimento di attività continuative. Questo soprattutto nei casi in cui si vogliano ottenere decisivi incrementi di performance e si voglia valorizzare al massimo le risorse presenti, rendendo i processi più reattivi e meno burocratici.

Intendiamo con il termine Business Agility l’applicazione dei principi dell’Agile a questo tipo di contesti, nei quali si vogliono ottenere chiari benefici di business.

Il limite delle organizzazioni tradizionali ad adattarsi ai cambiamenti di contesto è un tema chiaro e già studiato da molti anni. Il modo con cui abbiamo imparato ad organizzare le nostre aziende è nato all’inizio del secolo scorso (del 1911 è “L’organizzazione scientifica del lavoro” di Frederick Taylor) per rispondere a problemi di replicabilità, standardizzazione e gestione di lavoro prettamente manuale e poco esperto. Il sistema che è nato, basato sulla gerarchia fra le persone, sulle procedure prescrittive e sulla distinzione fra chi lavora e chi decide, è pensato per essere stabile nel tempo e non modificarsi mai, di modo da garantire continuità e replicabilità a prescindere dalle singole persone. Per quanto nel tempo si sia affinato e sofisticato, questo approccio già da molti anni appare sempre meno adeguato di fronte alla volatilità del mondo moderno, e sempre più esperti di organizzazione aziendale si sono adoperati per trovare delle soluzioni.

Oggi all’interno del concetto di Business Agility si fanno rientrare tutti i concetti e le teorie che stanno ripensando dalle radici il modo di organizzare le aziende, passando ad una fase completamente diversa dalla precedente. C’è chi le chiama Organizzazioni Teal (Frederic Laloux in Reinventare le organizzazioni), chi Sense&Respond (Jeff Gothelf e Josh Seiden): sono le esperienze concrete di molte aziende che hanno sviluppato modelli manageriali e organizzativi innovativi basati sui principi dell’Agile. A volte queste esperienze sono diventate dei framework da esportare verso altre aziende (pensiamo ad esempio al Semco Style Institute, basato sull’esperienza della Semco, o a Google con re:Work) a volte anche contro i consigli dell’azienda stessa (emblematico per ricaduta mediatica il caso di Spotify, che viene troppo spesso “clonato” in aziende completamente differenti).

Applicare il concetto di Business Agility all’interno di una organizzazione complessiva richiede innanzitutto la creazione di team cross-funzionali dedicati a obiettivi specifici, come ad esempio lo sviluppo e la gestione di una linea di prodotti, piuttosto che l’attuazione di azioni di marketing. In tutti i contesti dove è richiesta innovazione, velocità di risposta, l’Agile, pur declinato operativamente in maniera molto diversa da caso a caso, può essere una valida risposta. Allargando l’Agile all’organizzazione complessiva si toccano però tutta una serie di punti che, lavorando all’interno dei singoli team, è possibile ignorare.

Innanzitutto, la modalità di definire il perimetro di ogni team, cercando di minimizzare le interdipendenze con altri team ma nel contempo mantenendo obiettivi focalizzati e poche persone. Questo richiede una revisione organizzativa pervasiva che, pezzo per pezzo, può arrivare a smontare la tradizionale piramide gerarchica eliminando molte delle figure di middle management. Occorre poi pensare bene alle forme di coordinamento e di relazione fra questi team, creando “team di team” e puntando sulla chiarezza e univocità decisionale.

Nasce a questo punto la necessità di disporre di forme di coordinamento orientate al lungo periodo e alla crescita delle persone nell’organizzazione, piuttosto che allo scambio di know-how. Si sviluppano quindi famiglie professionali, comunità di pratica e altre forme leggere di coordinamento (figura 8).

Cambiano poi molti dei processi HR, soprattutto il performance management, che si orienta allo sviluppo della persona sganciandosi da logiche meramente retributive, che puntano cioè solo all’assegnazione di una quota variabile di compenso. Obiettivo è portare la persona a sviluppare le proprie performance tramite un ciclo di obiettivi e feedback su intervalli temporali più brevi del classico anno solare, di modo da poter dare obiettivi maggiormente concreti e sfidanti, definiti principalmente su responsabilità della persona stessa (in quest’ambito è di grande attualità il modello degli OKR – Objectives & Key Result).

Applicando l’Agile in maniera così ampia cambia la cultura aziendale perché cambiano gli stili di leadership e il significato del ruolo di ogni persona, e cambia la struttura aziendale, perché cambiano le unità organizzative e i processi a supporto.

Il percorso del cambiamento

Come si è visto, in qualsiasi accezione lo si prenda, l’Agile può avere un impatto molto profondo e come tale richiede una gestione attenta del percorso di cambiamento connesso con la sua introduzione.

Dall’esperienza concreta di molte aziende emerge un elemento chiave: il percorso verso l’Agile deve essere svolto anch’esso in modalità Agile. Questo vuol dire che non ha senso all’inizio perdere tempo per definire la configurazione organizzativa finale e per creare un percorso pluriennale per arrivarci. È l’esperienza che si crea durante il percorso che permette di capire quello che funziona e quello che non funziona date le peculiarità di ogni azienda, il suo mercato, il suo settore, i suoi problemi, la predisposizione delle sue persone, la sua cultura.

Per questo non bisogna cedere alla tentazione di prendere facili scorciatoie, copiando esperienze fatte da altri e sperando che replicarle nel proprio contesto sia vincente. Le singole metodologie sono importanti, in quanto già collaudate e ottimizzate, ma occorre sempre considerarle con un occhio critico, capendone i punti salienti e adattandole al proprio contesto per renderle applicabili senza snaturarle.

Il percorso verso l’Agile richiede di fare piccoli passi, partendo nel piccolo, da uno o più team, per fare esperienza e verificare l’impatto reale. Per supportare il team, più che formazione e certificazioni, sono importanti delle attività di accompagnamento e di coaching, che aiutino le persone a trasformare in pratica delle modalità di lavoro che sembrano semplici e di buon senso ma che, in realtà, richiedono un approccio e comportamenti spesso diametralmente opposti a quelli precedentemente agiti.

A partire da qui è poi possibile estendere l’Agile gradualmente, facendo leva sulle esperienze positive e sul potere di contaminazione delle prime persone che sono state coinvolte. Occorre dare il giusto tempo al cambiamento, che può richiedere anni per poter diventare pervasivo in una grande organizzazione.

Per arrivarci, fattore chiave è la sponsorship, che deve essere reale e visibile, perché gli scogli da superare sono molti; e deve esserci la capacità di comunicare in maniera continua e comprensibile cosa si sta facendo.

Nelle fasi di transizione, che sono molto lunghe, l’elemento critico è l’interazione fra i team Agili e il resto dell’organizzazione, che deve quindi comprendere e fare parte di questo progetto di evoluzione comune.

Il tutto tenendo a mente che non esiste un punto di arrivo, ma solo un percorso di esplorazione e di evoluzione che non può fermarsi, perché è il mondo là fuori, dove competiamo, che non si ferma mai.

Marco Mazzucco

Chief Innovation Officer di WebScience, società specializzata nel supportare le aziende nel loro percorso di Digital Transformation; 

ricercatore senior per gli Osservatori Digital Innovation del Politecnico di Milano