Agile or not Agile? Perché a volte vogliamo essere “agili” e non riusciamo
La Metodologia Agile è un utilissimo approccio per lavorare in modo più veloce, allineato, aumentando Team Collaboration e trasparenza con gli stakeholders.
Ormai è riconosciuto il potenziali di questo approccio e sempre più aziende ricercano tool e consulenze per “mettere il turbo” ai processi e al proprio business. Ma perché qualche volta non si ottengono i risultati sperati?
Fare Agile, anzi “essere” agile non è così facile come sembra. Capire quando non ci sono i presupposti è essenziale per correggere impostazioni sbagliate e per valutare se l’approccio è quello giusto per la nostra azienda e per il nostro lavoro.
Il nostro Lead Agile Consultant Roberto ha provato ad analizzare perché non sempre l’Agile si rivela la soluzione sperata e soprattutto come applicarlo in maniera corretta. Non come una facile “magia”.
La versione integrale dell’articolo si trova a questo link: Sviluppo agile: più veloci, più economici e risultati migliori, ma… a volte non funziona. perché?
Al giorno d’oggi siamo tutti “agili” e questa potrebbe essere una buona notizia; se non che la maggior parte delle persone si definiscono “agili” senza sapere realmente cosa questo comporti.
E questa è una brutta notizia.
Ma perché tutti desiderano o tentano di definirsi tali? Evidentemente perché essere “agile” significa essere più veloci, più economici e soprattutto fornire risultati migliori. Ma è così davvero?
DA DOVE ARRIVA l’AGILE?
Il contenuto del Manifesto Agile è noto.
Pochi punti all’apparenza semplici (e qui se vogliamo c’è la fregatura!) che in realtà trovano ispirazione in concetti di poco anteriori e di cui spesso si trascura l’importanza e l’incidenza nella formulazione del manifesto stesso: la “produzione snella” (lean manufactoring o production).
In effetti moltissime pratiche adottate dello sviluppo agile, sono influenzate fortemente dalla “produzione snella” ed entrambe, pur approcciando mondi diversi, cercano di enfatizzare la riduzione degli sprechi.
I due approcci in realtà differiscono soprattutto nell’esecuzione perché la “lean” si rivolge alla produzione di beni fisici, mentre agile tipicamente allo sviluppo software.
Tipicamente riducendo gli sprechi, nella “lean” si producono beni di qualità superiore ad un costo inferiore.
Alla domanda: “Lo sviluppo software è più veloce, più economico e con risultati migliori diventando agili?”
La risposta è: Si! Succede, ma…
sfortunatamente è molto facile definirsi agili… ma senza ridurre gli sprechi o meglio, senza essere snelli, di fatto non si è agili per nulla!
Spesso capita che nella “ingannevole” semplicità del manifesto agile, ci sia poca formazione e soprattutto esperienza all’interno dei team, nella figura dello scrummaster, del product owner, nei comportamenti dei membri del team e quindi essere sopraffatti dal “fai-da-te” pensando che un incontro al mattino di 15 minuti, risolva tutti i problemi.
Peggio ancora quando i committenti, chiamiamoli però “stakeholders” che è più significativo, non comprendono realmente le implicazioni dello sviluppo agile e quindi tanto meno lo perseguono, pensando che sia un compito, un esercizio di pratiche che solo i team possono e devono effettuare.
Questo produce solo confusione, incomprensione, fatica e soprattutto risultati scadenti. Tanto vale restare aggrappati a metodi più tradizionali, perché tentare di applicare agile senza essere agili, non serve proprio a nulla.
Se prendiamo la base della “produzione snella”, dobbiamo cercare di eliminare gli sprechi, cosa che nella produzione di beni materiali potrebbe essere semplice identificare, ma nello sviluppo software?
Vediamo se qualcosa si può identificare e migliorare.
FATTO! QUASI FATTO… ECCO CI SIAMO FORSE! WIP!
Per gli amanti, si chiama “work-in-progress” e di fatto è uno degli sprechi maggiori!
Finché non è finito, è WIP e tutto ciò che è in corso perennemente (o quasi) peggiora la possibilità di essere veloci, aumenta i tempi di attesa e soprattutto rallenta il “rework” in caso di necessità.
E’ purtroppo una sorta di “comfort zone“ in cui spesso si entra, ci si accomoda… e ci si sta.
Si cerca di migliorare continuando ad aggiungere “pezzetti” senza mai rilasciare un vero e proprio valore, mantenendo sempre un sacco di cose aperte (vogliamo parlare della documentazione) che spesso non si chiudono perché non siamo in grado di garantire il significato di “fatto”, finito!
Non per nulla forse la prima definizione da condividere, su cui il team deve trovare un vocabolario comune è proprio quella di “DONE”, “FATTO” e non può prescindere dai concetti di valore verso chi ha richiesto lo sviluppo e dei benefici percepiti realmente.
Non è in concetto assoluto, tutt’altro, è in continuo movimento e cambia di significato man mano che il team cresce ed evolve nelle tecniche agili.
SOVRACCARICO DI PROCESSI
Quando le realtà aziendali sono organizzate in “gruppi o divisioni funzionali” si rischia il sovraccarico dei – e nei – processi.
Gli analisti del business vengono valutati per la quantità di documentazione che producono, chi fa pianificazione per il dettaglio della programmazione, ecc. ecc…
Se consideriamo tutta la cascata, risulta evidente che benché possiamo avere a disposizione i team più agile del mondo, guardando alla gestione di processo non abbiamo risolto proprio nulla.
Essere agili, significa trasformare una azienda in una azienda agile. Il vocabolario, il metodo, le modalità devono essere comuni dalla strategia allo sviluppo, la filosofia deve essere condivisa ed appartenere ad uno sviluppatore tanto quanto ad un program manager.
TASK SWITCH (CHIAMATO ANCHE TEAM MULTIPROGETTO)
Da quando mi occupo di agile trasformation, mi accade sempre e dico sempre, di sentirmi dire che il tal o tal altro sviluppatore deve essere assegnato sia a questo progetto ma anche all’altro progetto… perché… lo sa solo lui… lui lo fa meglio… e via cantando.
Sviluppare software è un po’ come suonare uno strumento, necessità di una certa dose di creatività e il cambio di contesto, di ambito rallenta in modo sensibile il tempo di “ripresa” di un determinato sviluppo.
Uno dei presupposti base dell’agile è essere reattivi al cambiamento e questo richiede della flessibilità.
Cercare di “riempire” (per non dire affogare) un team tutte le ore della giornata non fa altro che creare l’effetto contrario aumentando ritardi e di conseguenza pianificazioni non corrette, nonché “incazzature” e malumori nei membri del team.
Quando un team pianifica le proprie attività deve essere tranquillo e sicuro delle competenze che possiede e di cui si prende la responsabilità di rilascio.
Modificare gli assetti significa sbilanciare le possibili pianificazioni.
ATTESE E RITARDI
Uno degli errori che maggiormente vedo ricorrere è il totale distacco tra il product owner e il team di lavoro. Per poter essere agile, un team ha necessità di rapporti continui con il proprio PO, in modo da poter sempre chiarire le user story e convalidare il lavoro rilasciato.
Rallentare le attività di feedback da parte del PO significa di fatto ridurre o non raggiungere i miglioramenti pianificati causando spesso difetti persistenti e ri-lavorazioni sul codice.
VALUTARE CORRETTAMENTE I PROPRI STAKEHOLDER
La comunicazione è una delle parti fondamentali per arrivare al risultato sperato, sia essa all’interno del team o con tutti attori coinvolti con gradi più o meno importanti.
Gli “Stakeholder“, letteralmente “titolare di una posta in gioco” sono le persone che in un modo o nell’altro hanno a che fare con il nostro progetto e quindi più o meno influenti rispetto alle attività di un progetto, ma in che modo?
Quando si inizia una nuova attività ci si dimentica di identificare in modo puntuale chi e perché è coinvolto, che grado di “potere” ha sul progetto, a chi devo rispondere per fornire il risultato corretto.
Tutto questo deve avvenire in modo molto trasparente e chiaro a tutti! Dare soddisfazione alla persona sbagliata, può mettere a rischio l’intero risultato.
DIFETTI DI LAVORAZIONE
Tanto più codice si sviluppa, tanto più tempo sarà necessario per verificare il buon funzionamento del prodotto, tanti più difetti saranno creati nel codice.
La soluzione? Accorciare i tempi di test e verifiche, lavorando su piccole porzioni di codice e correggere immediatamente, se non addirittura in anticipo.
Quelle che in agile vengono definite “cerimonie” come lo stand-up, la revisione dello sprint, la retrospettiva sono le modalità con cui ottenere correttamente i feedback per correggere i difetti velocemente.
Spesso viene sottovalutato il potere di questi incontri, utilizzandoli solo in parte e comunque non nel modo corretto.
CAMBI E SCAMBI (NON E’ UN GIOCO DI RUOLO!)
Spostare le persone da un team all’altro continuamente, cercando di “tappare” tutte le possibili necessità, non produce l’effetto sperato, anzi diventa controproducente.
Prima di tutto perché non si riesce a creare un team ben amalgamato e in secondo luogo perché si rischia di perdere competenza e conoscenza sbilanciando così anche le pianificazioni successive del team.
IL PRODOTTO DEVE AVERE TUTTE LE FUNZIONALITÀ
Accade spesso che i partecipanti alle analisi funzionali e dei requisiti (stakeholders, PO, ecc.) stilino un elenco infinito di funzionalità, cercando poi di pianificare e rilasciare “il prodotto intero” perché tanto, senza questa feature il prodotto non è completo…, per scoprire poi che non serviva oppure serviva ma… non era così che la si voleva.
Il modo migliore è quello di creare le funzionalità minime in modo da poter far comprendere cosa sarà, convalidarne l’ipotesi e continuare con lo sviluppo in modo da completarla a piccoli passi.
Di fatto il meccanismo è abbastanza immediato, sempre mettendola in musica è inutile che ti faccia sentire l’opera intera dopo sei mesi, quando posso farti ascoltare man mano le melodie che la compongono. Magari scopriamo dopo una settimana che la nostra melodia non è quella corretta e possiamo correggere in fretta. Rifare tutta l’opera sarebbe molto complicato oltre che oneroso!
NON BISOGNA ESSERE DEGLI STREGONI…
per essere e fare agile!
Studiare e assimilare le filosofie “lean” e “agile”, effettuare le cerimonie e le metodologie in modo corretto, porta le persone e di conseguenza i team, a migliorare il proprio lavoro e risultato.
Purtroppo non è sempre così facile, perché ci sono impedimenti fuori dal controllo del team e che mettono a rischio la trasformazione agile.
Questi impedimenti spesso derivano da un problema organizzativo, da una comunicazione non coerente tra i diversi livelli aziendali, da modalità di pianificazione non coerenti tra i program manager e i team, ecc.
Come espresso in precedenza, è necessario che la trasformazione agile, sia una scelta azienda e che tutto il sistema organizzativo si muova in modo coerente con il sistema produttivo e viceversa.
