Transizione Agile: tre fasi per passare a Scrum

In un precedente articolo introduttivo (Viaggio alla scoperta di Scrum) abbiamo visto una panoramica generale del più popolare e diffuso framework Agile per la gestione di progetti ad alto livello di incertezza, dove per le caratteristiche di contesto è difficile – e a volte impossibile –  determinare in partenza tutti i requisiti e le caratteristiche del prodotto o servizio che devi realizzare, tenendo al contempo sotto controllo in modo strutturato l’elevato volume di change request generato in questi casi.

La presenza di dinamiche di rapido cambiamento e di livelli di incertezza medio-alti è tipica dei progetti IT, in particolare quelli di sviluppo software, per la natura intangibile del prodotto da realizzare e il time-to-market sempre più rapido.

Scrum esplora la fattibilità del risultato attraverso brevi iterazioni di lavoro (sprint), durante le quali il prodotto/servizio viene costruito in modo incrementale, facilitando un tempestivo adattamento a situazioni che evolvono velocemente, sulla base di frequenti feedback dei committenti del progetto e degli utilizzatori del prodotto finale, sia nei momenti di pianificazione prima di ogni sprint (Sprint Planning Meeting) che in quelli di verifica e controllo al termine del mini-ciclo di lavoro (Sprint Review Meeting) e in quelli interni al team per la raccolta delle lesson learned e il miglioramento dei processi (Sprint Retrospect Meeting).

Scrum può dare alla tua IT company un utile schema di riferimento per gestire progetti complessi adattandosi dinamicamente alle situazioni e per realizzare prodotti più vicini alle esigenze degli utilizzatori in modo efficace e creativo. Tuttavia, per cavalcare lo tsunami della trasformazione digitale senza farti travolgere non puoi semplicemente limitarti ad applicare il metodo Scrum nei tuoi progetti: tutta la tua azienda deve pensare e agire in modo agile.

Devi avviare un’evoluzione sistemica per passare dal software agile all’organizzazione agile,  modificando l’approccio sia all’interno che verso l’esterno, con l’obiettivo di una gestione efficace e flessibile del cambiamento.

Ma quali sono gli elementi chiave per avviare una transizione Agile della tua azienda IT?

1) Il primo è una governance centrata più sul valore che sulla predicibilità. Lo sviluppo del software va infatti considerato più come un processo di design che come un normale processo di produzione di un prodotto manifatturiero o di un edificio. I requisiti sono spesso instabili e più che tentare di fissare a priori le caratteristiche del prodotto, determinando di conseguenza tempi e costi di realizzazione (approccio plan-driven), ti focalizzi sul prendere decisioni che diano priorità, e quindi precedenza temporale, alle attività a maggior valore aggiunto e alle azioni di maggiore riduzione del rischio (approccio value-driven), fissando in anticipo budget e tempi e rendendo lo scope di progetto negoziabile.

La struttura iterativa dei cicli di lavoro Agili, come Scrum, favorisce in modo naturale questo approccio. All’inizio di ogni iterazione di lavoro ri-valuterai priorità e rischi e pianificherai per la finestra temporale immediatamente successiva. Il valore (es. funzionalità di un nuovo prodotto software) viene rilasciato ad ogni iterazione e non al termine dell’intero processo realizzativo.

In termini più generali, dovresti passare da un modello “inside out”, dove realizzi e vendi il tuo prodotto sul mercato, ad un modello “outside in”, dove costruisci iterativamente il prodotto/servizio assieme al tuo cliente.

2) Il secondo elemento chiave della transizione Agile è la capacità di organizzarti per essere responsivo più che efficiente rispetto ai costi. Ovviamente un’azienda, non solo IT, deve cercare di soddisfare entrambe le cose, ma la capacità di rispondere rapidamente al cambiamento è una strategia di business che agilità e adattabilità consentono di conseguire, mentre l’efficientamento dei costi è un vincolo da rispettare, necessario per la buona salute dell’azienda ma diverso dall’obiettivo strategico e che non deve essere confuso con esso. Questo significa non focalizzarsi solamente su profitto ed efficienza “qui e adesso”, ma avere una visione su come generare valore a medio-lungo termine attraverso idee, qualità e innovazione.

3) Il terzo elemento chiave della transizione Agile è riuscire a stimolare la motivazione intrinseca delle persone. La produzione del software e i progetti IT sono tra le attività a più alta intensità di lavoro umano, le persone rappresentano quindi il fattore decisivo di successo.

Un contesto dinamico e di incertezza richiede un elevato livello di collaborazione non formalizzata tra i team di lavoro. Ciò richiede persone che agiscano in base a fattori di forte motivazone intrinseca, attraverso un modello organizzativo che promuova l’eccellenza tecnica, l’autonomia e la capacità di auto-organizzarsi.

Dal punto di vista delle procedure interne, questo significa passare da una logica “push”, direttiva, prescrittiva, con processi e procedure rigidi, ad una logica “pull”, incentrata su comunicazione bottom-up, collaborazione e responsabilità condivisa.

Tuttavia, non si diventa autonomi da un giorno all’altro. Devi attrezzarti per trasformare la tua organizzazione da verticale, con ruoli e competenze settoriali e profili verticali (es. analista funzionale, programmatore, web designer, database administrator, etc.) e scarsa flessibilità, ad orizzontale, con team cross-funzionali, competenze trasversali, profili professionali più ampi (es. full stack developer) e maggiore flessibilità di impiego.

In molti casi è necessario riprogettare adesso i percorsi professionali delle persone all’interno dell’azienda, per avviare quella evoluzione delle conoscenze e delle competenze che ti consentirà di cogliere nel giro di 2-3 anni i primi frutti. E non si diventa nemmeno collaborativi da un giorno all’altro.

Da un approccio “closed” con bassa condivisione esterna ma soprattutto interna, devi gradualmente passare a un approccio “open”, basato su un ciclo di learn-share-collaborate-improve, per favorire lo scambio e il trasferimento di conoscenza all’interno della tua azienda secondo modalità non convenzionali. Per esempio stimolando, in aggiunta alla tradizionale formazione affidata ad una Academy interna all’azienda e/o a società esterne, la nascita e la proliferazione di vere e proprie comunità di pratica, cioè gruppi di persone che condividono abilità e/o interessi e si incontrano fisicamente (pausa pranzo, code weekend, etc.) o on-line, aggregando competenze su nuove tematiche di interesse.

Volendo delineare un ipotetico percorso di transizione che parta dall’introduzione di Scrum sui progetti e si diffonda a regime come “transizione Agile a livello enterprise” devi agire in maniera progressiva, garantendoti una serie di pre-condizioni di base.

Molti tentativi di cambiamento a volte falliscono non perché processi e pratiche individuali funzionino male, ma perché l’organizzazione nel suo complesso, la sua struttura di potere, le norme e procedure organizzative e la cultura aziendale resistono al cambiamento, a maggior ragione quando questo ha impatto sistemico e generalizzato.

È importante definire una fase di avviamento (preparing), identificando alcuni progetti “pilota” su cui applicare metodi e tecniche agili e formando le persone che comporranno i relativi team. La formazione tradizionale, anche esterna, andrà integrata con interventi di follow-up e di coaching per verificare e guidare la corretta applicazione dei nuovi metodi sui progetti pilota (learning & training). La terza e decisiva fase è quella della progressiva estensione dell’approccio, con la costituzione di un Agile Project Management Office a livello aziendale, l’incremento dei team e dei progetti agili, l’ingegnerizzazione di processi e pratiche e l’evoluzione di medio-lungo periodo dei profili professionali.

In sintesi, l’azienda agile si adatta rapidamente e deliberatamente al cambiamento di contesto e delle richieste, controllandone i risultati attraverso una gestione e un’organizzazione poco prescrittive, focalizzate su qualità, trasparenza e auto-organizzazione. Non è una questione di dimensione, grandi player come Google, Microsoft o Spotify hanno da tempo introdotto cambiamenti di questo tipo nella loro value chain. E voi, siete pronti a partire?

Vuoi saperne di più sui benefici del framework Scrum?