C’è un grafico che sintetizza bene la cultura dell’Agile all’interno delle aziende: alla domanda se l’Agile venga adottato all’interno dell’organizzazione, il 97% degli executive risponde senza esitazione “Certamente!”. Ma se la stessa domanda viene rivolta a chi l’Agile dovrebbe usarlo nei fatti, ovvero ai team di delivery e di progetto, la risposta è di tutt’altro tenore. Solo il 2% risponde: “sì, lo usiamo”.
E quindi? Dove sta la verità? Questo “mitico” Agile si traduce in azioni concrete o è solo uno slogan di cui si riempiono la bocca i manager per apparire innovativi? Il paradosso dell’Agile si manifesta proprio in questa discrepanza tra la percezione del management e la realtà operativa dei team. Gli executive vedono l’Agile come una panacea, una metodologia che promette di rendere l’azienda più dinamica e competitiva. Ma non si tratta di applicare un framework di lavoro come Scrum, Less o Safe. Il cambiamento è ben più profondo: si tratta di modificare il mindset, di fare una trasformazione culturale e di leadership.
“L’adozione dell’Agile in azienda non può essere considerata semplicemente come l’implementazione di una nuova metodologia di project management, vanno invece prese in considerazione implicazioni più profonde riguardanti l’evoluzione degli stili di leadership e della cultura aziendale” spiega bene Stefano Mainetti, Executive Chairman di Adesso.it.
Molti progetti falliscono nel diventare veramente agili perché si limitano a superficiali adozioni di pratiche, senza comprendere appieno i principi fondamentali che rendono l’Agile efficace. Per fare in modo che l’Agile funzioni davvero, è necessario un forte coinvolgimento da parte di tutti i livelli dell’organizzazione, un cambiamento culturale che favorisca la collaborazione, la trasparenza e l’adattabilità.
C’è ancora tanto lavoro da fare ed è per questo che abbiamo deciso di inaugurare su ZeroUno una rubrica “Agile4Executive” che aiuti i manager in questo straordinario percorso verso l’Agile. Sarà un vero e proprio “Centro Risorse” che nel corso delle prossime settimane sarà arricchito con contenuti molto pratici e concreti.
L’idea nasce dal workshop “Quello che avreste voluto sapere sull’Agile, ma non avete mai osato chiedere”, che adesso.it ha realizzato con CIOnet (immagine sotto). L’obiettivo era sfatare 10 falsi miti che frenano molte aziende, affrontando i paradossi della cultura manageriale tradizionale e proponendo soluzioni pratiche. Partiamo da qui, quindi, con la pubblicazione di questo primo articolo.
I 4 valori fondanti del Manifesto Agile
L’Agile nasce all’inizio degli anni 2000 come risposta alla necessità di adattamento rapido nel mondo dello sviluppo software.
Il Manifesto Agile, redatto nel 2001 da 17 esperti del settore, ha sancito i quattro valori fondamentali e i dodici principi che guidano questa metodologia. I valori principali includono:
- Individui e interazioni più che processi e strumenti. L’accento è posto sulle persone e sulla comunicazione tra gli individui del team, piuttosto che sui processi formali e sugli strumenti utilizzati.
- Software funzionante più che documentazione esaustiva. La priorità è data al funzionamento del software piuttosto che alla creazione di documentazione dettagliata e completa.
- Collaborazione con il cliente più che negoziazione dei contratti: si privilegia una stretta collaborazione con il cliente durante tutto il processo di sviluppo, piuttosto che focalizzarsi su contratti rigidi e definiti.
- Rispondere al cambiamento più che seguire un piano. L’agilità consiste nel rispondere efficacemente al cambiamento, piuttosto che aderire rigidamente a un piano prestabilito
I limiti del Manifesto Agile
Il Manifesto Agile presenta anche alcuni limiti. Uno dei principali è la difficoltà di implementazione in organizzazioni di grandi dimensioni, dove i processi rigidi e le strutture gerarchiche sono profondamente radicati. Inoltre, l’insistenza sulla flessibilità e sulla riduzione della documentazione, se interpretata in modo radicale, può portare a problemi di coerenza e di comunicazione, specialmente in team distribuiti geograficamente.
Entrano poi in gioco questioni molto più “pratiche” e operative. “Di fronte a scenari di mercato sempre più complessi, alla pressione del CEO e degli stakeholder sui risultati, cosa può fare il CIO? Ribatte che la soluzione è collaborare con il cliente più che negoziare il contratto?”, commenta provocatoriamente Mainetti.
Ci sono poi dei misunderstanding di fondo: l’Agile è un nuovo modo di fare project management? Come si concilia il lavoro per iterazioni con la gestione del budget? Quindi si sta dicendo che si ragiona a tempo e budget infiniti?
“La questione di fondo – spiega Mainetti – è che si parlano lingue diverse. La lingua dell’Agile non è la lingua del business”. Siamo convinti di suonare con lo stesso spartito, ma non è così (vi ricordate della diversa percezione dell’uso dell’Agile in azienda?). Bisogna ancora lavorare affinché l’orchestra impari a suonare (bene) la sinfonia dell’Agile.
Ma l’Agile serve veramente?
Domanda provocatoria per i CIO. “Quante volte, seguendo un piano prefissato a priori, il prodotto/servizio è risultato già obsoleto al momento della release?” In molti casi, i progetti risultano già “vecchi” quando vanno in produzione. Perché? Perché le esigenze cambiano in corso d’opera, perché le priorità diventano altre, perché gli stakeholder non sono più gli stessi.
E qui l’Agile può dire tanto. L’approccio iterativo dell’Agile permette di far fronte al cambiamento e di rivedere e modificare il prodotto in base al feedback continuo, garantendo così che il risultato finale sia in linea con le esigenze attuali del committente (questo richiede una mentalità aperta e una disponibilità a cambiare rotta quando necessario, qualità che non tutte le organizzazioni possiedono in egual misura).
Secondo punto: le migliori aziende al mondo oggi sono agili. Da Apple a Microsoft, da Alphabet a Nvidia, da Toyota a Sony giusto per citarne alcune. Non tutte utilizzano in modo esplicito la parola “Agile”, ma tutte sono caratterizzate in modo rilevante da principi e pratiche di fatto agili. Secondo varie analisi (Benefits of Scaling Agility, Scaled Agile) le aziende agili sono più produttive (+20-50% di progetti rilasciati in tempo e in budget), hanno un migliore engagement (+10%), sviluppano prodotti di miglior qualità (-30-50% di prodotti difettosi), sono più reattive (+20-50% di riduzione nella delivery dei prodotti).
Terzo punto: anche in Italia l’Agile inizia a essere considerato presso le grandi organizzazioni. In base ai dati dell’Osservatorio Cloud Transformation del Politecnico di Milano, solo il 31% delle grandi aziende italiane non ha ancora adottato l’Agile nei progetti IT. “In realtà – commenta Mainetti – nelle discussioni e interviste, emerge che l’adozione procede a macchia di leopardo e ci si trova ad affrontare molte difficoltà per renderla un cambiamento sistematico”.
Insomma, i principi un po’ astratti del Manifesto Agile trovano in realtà una loro concretizzazione.
Tuttavia, nonostante l’efficacia dimostrata, non si può negare che l’Agile rappresenti una sfida per alcune organizzazioni. La resistenza al cambiamento è un ostacolo comune; molte aziende sono riluttanti a rinunciare a metodi consolidati e a strutture gerarchiche rigide. “Adottare l’Agile con successo richiede il coraggio di abbandonare lo status quo e di affrontare con determinazione le difficoltà e le resistenze che possono sorgere lungo il cammino – commenta Mainetti – . Si tratta di un percorso di cambiamento che rappresenta una delle esperienze più gratificanti per i manager: questa trasformazione rappresenta la grande soddisfazione di abbandonare la prigionia e la solitudine del ricorso all’autorità come leva di comando, in favore della meravigliosa conquista dell’autorevolezza, guadagnando la fiducia e la stima autentica dei collaboratori”.
Quello che avreste voluto sapere sull’Agile ma che non avete mai osato chiedere
Come fare quindi? Nei prossimi articoli di questa rubrica andremo a porre 10 domande “scomode” (ma forniremo anche 10 risposte) per aiutarvi in questo straordinario viaggio verso l’Agile. In particolare affronteremo i seguenti quesiti:
- Avendo io la responsabilità diretta del progetto, come posso fidarmi di team che si auto-organizzano?
- Come posso avere visibilità su cosa sta facendo il team, se non ci sono documentazione di progetto e rendicontazioni dettagliate?
- Come posso considerare un progetto di successo se non sono rispettati i vincoli di tempi e costi?
- Come posso verificare la qualità del prodotto senza un processo di controllo qualità rigoroso e centralizzato?
- È vero che l’Agile è miope ed ha eccessiva enfasi sul breve periodo e non permette di cogliere gli obiettivi di lungo periodo?
- Come è possibile definire una pianificazione di progetto, senza una analisi dettagliata e completa a priori?
- Come posso costruire un budget IT se i miei fornitori lavorano con l’approccio agile con orizzonte temporale di 2/3 iterazioni?
- Come gestire cambiamenti frequenti nel piano senza destabilizzare gli stakeholder di progetto?
- Se tutti sono responsabili, chi è responsabile quando qualcosa va storto?
- Perché il mio capo vuole l’agile, ma lo osteggia nei fatti?
Stay tuned!
