Cinque errori nella scalabilita Agile

Le grandi aziende cercano in particolare modi rapidi e semplici per effettuare la transizione dallo sviluppo tradizionale a quello agile. Più veloce deve avvenire la transizione, più pericolose sono le trappole che vengono trascurate. Lo sviluppo agile punta più sulla sostenibilità che sul fare le cose semplicemente in fretta. Pertanto, il management ha una grande responsabilità per il successo della transizione agile. Dall'esterno, la transizione sembra riuscita, ma dall'interno i benefici della transizione non ci sono.

Ecco cinque errori comuni nel percorso verso un'organizzazione agile:

1. Agilità di base

La transizione ai processi agili è facile. Si deregola un po' e si mandano alcune persone a fare formazione. Dopo di che le persone sanno “fare Scrum” – o scegliere un altro approccio agile. Ma visto nell'insieme, potresti aver raggiunto l'1% – il 99% del percorso è ancora davanti a te. Il viaggio è ancora lungo. Al cuore dell'agilità c'è il processo Inspect+Adapt.

Perché funzioni, serve un mindset speciale. Tutti devono mettere costantemente in discussione ciò che accade – e apportare cambiamenti quando le cose vanno nella direzione sbagliata. Per ancorare Inspect+Adapt in modo significativo nell'organizzazione, servono due cose:

Primo, il modo di lavorare esistente deve essere disintossicato. Gli elementi della cultura aziendale che scoraggiano gli sviluppatori dall'assumersi la responsabilità dei propri processi devono essere rimossi. Per farlo, molti processi Command+Control devono essere eliminati e la gestione degli sviluppatori deve essere ripensata radicalmente. Il cambiamento avverrà solo se è permesso!

Dopo, deve essere creato un modo di lavorare sano. Serve un sistema di gestione che incoraggi gli sviluppatori ad assumersi la responsabilità delle proprie azioni, decisioni, cambiamenti, fallimenti e successi. Questo richiede la creazione di strutture e processi che valorizzino onestamente il contributo individuale di ogni persona – indipendentemente dal fatto che il management sia soddisfatto della direzione intrapresa o meno. Le persone daranno il loro contributo solo se glielo permetti!

Finché le fondamenta dell'agilità non sono poste, non ci sarà agilità. I team senza un'agilità di base non trarranno beneficio né contribuiranno alla scalabilità agile.

2. Strumenti e tecniche

Introdurre le cerimonie di Scrum richiede solo un giorno, inclusa la formazione e la decisione. Questo ti dà la base per il “lavoro agile”. Pianificazione a breve termine, aggiornamenti regolari del piano, feedback sul prodotto e miglioramento incrementale del processo sono essenziali. Nel tempo, gli sviluppatori possono trovare il modo ottimale di lavorare. Bisogna solo prevedere molto tempo per l'ottimizzazione se le pratiche ingegneristiche non sono ancora consolidate. Gli sviluppatori devono conoscere concetti come il controllo di versione, l'integrazione continua, l'automazione dei test, il design emergente, TDD, BDD, pairing, convenzioni di codice – e molto altro che XP ha da offrire. Devono decidere consapevolmente quali di queste pratiche sono utili nel contesto attuale. Finché gli sviluppatori non padroneggiano queste pratiche, possono essere “ritualmente agili”, ma non praticare l'agilità. Un team senza gli strumenti giusti può persino rallentare l'implementazione dello sviluppo scalato.

3. Spirito di squadra

Lo spirito di squadra, spesso deriso come esoterico, è immensamente importante per il miglioramento sistemico nella scalabilità agile. Molti manager pensano che gli obiettivi personali (fino allo stack ranking) siano utili per ottenere collaboratori ad alte prestazioni. La scalabilità agile, tuttavia, serve principalmente a costruire un sistema complesso e adattivo in cui molte persone contribuiscono. La necessità di contribuire al quadro generale è molto più importante del contribuire ai propri obiettivi. In questo caso, “spirito di squadra” significa che gli individui devono sempre subordinare i propri interessi per portare avanti la missione dell'azienda. Lo spirito di squadra non riguarda tanto il “fare cose divertenti con gli altri” (ad es. eventi di team come rafting, go-kart o paintball). Riguarda principalmente il divertirsi facendo cose che aiutano ad andare avanti insieme.

Gli sviluppatori hanno bisogno di due cose per farlo: primo, devono sapere come possono contribuire. Poiché questo dipende molto dal caso specifico, il contributo è principalmente auto-organizzazione e motivazione intrinseca. Secondo, devono sapere che essere d'aiuto conviene. Tutto ciò che crea uno svantaggio personale nell'aiutare gli altri a raggiungere un obiettivo comune deve essere rimosso. Un esempio classico di “spirito di squadra” è il calcio: abbiamo spesso visto che la partita non viene vinta dal miglior giocatore. Vince la squadra migliore. Lo stesso vale nello sviluppo: gli assi che si superano a vicenda non vincono. Si vince combinando le forze, mettendo in comune le idee e andando avanti insieme. Gruppi di sviluppatori senza spirito di squadra sprecano le loro energie in “occupazione”. Un gruppo scalato che non è un team usa solo una frazione del suo potenziale per raggiungere l'obiettivo comune!

4. Trasparenza

Molte organizzazioni falliscono a causa della mancanza di conoscenza del sistema complessivo. Non riescono a ottimizzare a livello globale. Gli ostacoli classici alla trasparenza esistono a tutti i livelli: dallo sviluppatore che non sa come il lavoro di un collega lo influenzi, al manager che non riesce a dire quale sia l'Assoluta Priorità 1. Questa mancanza di trasparenza porta a molti problemi. Inizia con lo sviluppatore che inconsapevolmente sabota il lavoro dei colleghi e si estende a interi team che lavorano sulle cose sbagliate. Niente di tutto ciò è desiderabile e più spesso succede qualcosa del genere, più è critico e importante aumentare la trasparenza.

Alcune organizzazioni sprecano quasi tutta la loro capacità per gestire problemi causati dalla mancanza di trasparenza. In tali situazioni, “faticare” è probabilmente una descrizione più accurata di “scalare”. Ci sono molte leve per aumentare la trasparenza fino al punto in cui la scalabilità ha senso. Alcune di esse sono:

• Implementa un Kanban – che tutti possano vedere!

• Un backlog centrale da cui tutti i team attingono

• Collective Code Ownership come base per la “comunicazione attraverso il codice”

• Andon: Build Monitoring e “Stop the Line” basati su test automatizzati

• Pianificazione congiunta e review congiunte in cui viene mostrato solo il prodotto integrato

La trasparenza è anti-proporzionale all'overhead e ai problemi. In altre parole: con la scalabilità agile, la trasparenza è proporzionale al ROI. I team agili a cui manca la trasparenza non danno un contributo significativo agli obiettivi aziendali.

5. Focus

In molte organizzazioni, uno dei problemi principali è un focus sbagliato sul carico di lavoro: si gestisce il lavoro e si portano i compiti ai collaboratori. L'assunto di base è che si crea valore mantenendo tutti “occupati” al massimo. In un'organizzazione agile, è il contrario: portiamo le persone al lavoro che vale la pena fare. Sappiamo che non c'è una correlazione positiva tra creazione di valore e carico di lavoro. Ci concentriamo sulla consegna di un prodotto utilizzabile – portare le cose a termine. Un problema classico in molte organizzazioni è che cercando di far lavorare le persone al massimo della capacità, molte cose sono “in lavorazione”: questo richiede cambio di attività e coordinamento. Ma anche negli scenari più banali, la conseguente perdita di focus porta a un ROI massicciamente ridotto e a tempi di consegna significativamente aumentati: passiamo troppo tempo a cercare di capire perché nulla viene completato – e troppo poco tempo a cercare di completare qualcosa.

L'idea principale dietro il focus è: costa molto meno fare prima la cosa sbagliata e poi quella giusta – che fare due cose contemporaneamente. Per quanto banale possa sembrare, è difficile da implementare: l'intera organizzazione ha bisogno di una lista chiaramente ordinata di obiettivi, e ogni obiettivo deve essere chiaramente prioritizzato. Esiste esattamente una sola Priorità 1. Successivamente, il “Work in Progress” deve essere strettamente limitato. Il focus richiede ai manager di ripensare radicalmente il loro atteggiamento: accettare che l'“inattività” costa meno del sovraccarico. Né si può ottenere tutto in una volta. I team senza focus possono essere “ben utilizzati” ma sono altamente inefficaci. Meno sono focalizzati, più tempo impiegano per creare valore.

Riepilogo

La “scalabilità agile”, che non si preoccupa delle trappole sopra menzionate, diventerà molto probabilmente un cargo cult. Dall'esterno, la transizione sembra riuscita, ma dall'interno i benefici della transizione mancano. Per transizioni agili di successo, un approccio comune è coinvolgere esperti qualificati che hanno “combattuto in prima linea” e conoscono già le trappole.
Per evitare le trappole in un ambiente scalato, raccomandiamo:

• Supporto del management per la transizione. Per chiudere le trappole, alcune cose nell'organizzazione devono essere capovolte. Questo richiede il pieno supporto del management.

• Costruire un Agile Transition Team (ATT) in cui siano coinvolti sia i manager che gli sviluppatori. L'ATT ha un chiaro backlog di cambiamento su cui tutti lavorano insieme.

• Executive Coaching per le persone chiave nella transizione. Questo include i line manager così come i Product Owner e gli Scrum Master. Il coach esterno deve avere esperienza nella scalabilità agile!

• Technical Coaching aiuta i team a ottenere gli strumenti giusti più velocemente: questo si ripaga molto rapidamente con un prodotto di qualità superiore!

• Assumere un consulente per guidare la transizione. Questa persona deve sapere esattamente cosa sta facendo e deve lavorare senza compromessi. Deve avere il potere di portare avanti anche i cambiamenti impopolari.

• Formazione per tutti sull'agilità. In un ambiente di formazione sicuro, l'impatto della transizione è molto più facile da comunicare.