AgileFall: chi ne soffre e quali sono i sintomi?
Due rimedi della nonna per ritornare sulla strada giusta
AgileFall è un termine ironico che identifica i progetti in cui cerchi di essere Agile, ma continui a utilizzare tecniche di sviluppo Waterfall. Il risultato è buono come un mix tra cera per pavimenti e glassa per dolci.
Così ne parla Steve Blank su Hardward Business Review, e questa definizione mi ha fatto prima sorridere e poi riflettere.
Quante aziende che si imbarcano in un processo di digital transformation adottano — incosapevolmente — l’AgileFall e ne restano vittime?
Forse ti starai chiedendo se anche la tua azienda soffre di AgileFall, io so di averlo fatto la prima volta che ne ho sentito parlare. Per rispondere a questo domanda dobbiamo chiederci:
1. Non è cambiato nulla a parte la terminologia?
Il Project Manager adesso si chiama Product Owner e la riunione trimestrale adesso si chiama “Retrospettiva obiettivi aziendali Q3”. L’organizzazione del lavoro e la struttura del progetto sono invariate, la produttività non è migliorata e il team lavora seguendo la solita routine instaurata nel corso degli ultimi 3 anni.
Abbiamo mescolato cera per pavimenti e glassa di zucchero proprio come dice Blank, appiccicando l’etichetta “Agile” ai cari, vecchi e consolidati processi Waterfall.
2. Il primo “sprint” è dedicato alla scrittura di requisiti di progetto immutabili?
Se durante la prima riunione di progetto il Project Manager sta già definendo i dettagli di ogni step della roadmap significa che state facendo AgileFall.
Dal momento che gli utilizzatori finale del prodotto dovrebbero aiutarti a impostarne visione e requisiti, l’idea che tu possa dedurlo con il top management il primo giorno è contraria al 100% alla filosofia Agile.
3. Tutti pensano che Q&A e testing siano reclusi agli ultimi due step del progetto?
Se testare il prodotto o servizio che state introducendo in azienda è previsto solo alla fine del progetto non state applicando le metodologie Agili. Si, per qualcuno può essere considerato un passo avanti aver introdotto la fase di test — sopratutto in quelle organizzazioni in cui la decisioni vengono prese in cima alla piramide e propagate al resto dell’azienda senza possibilità di confronto — ma in Agile il testing e il Q&A sono processi continui, che viaggiano di pari passo con lo sviluppo.
Se hai riscontrato questi sintomi nella tua realtà lavorativa, mi dispiace, soffrite di AgileFall. Ma non è questo il momento di disperare, a tutto c’è rimedio!
Il primo consiglio che ti darebbe chiunque è “rivolgiti ad un professionista per una consulenza”. Ma se quel professionista sei tu e — come nel mio caso — sei alle prese con la trasformazione digitale di un’azienda medio-grande, puoi mettere in pratica queste due tecniche per avviare il processo di cambiamento in azienda. Ricordati che il cambiamento fa paura, e la cosa più difficile e lenta da modificare è proprio la cultura di organizzazione e delle persone che ne fanno farte.
Identifica i punti deboli e gli ostacoli del progetto
Prenditi del tempo con il tuo team per tracciare visivamente le dipendenze, gli obiettivi, le scadenze e i principali ostacoli del tuo progetto. Il feedback degli utenti è fondamentale per adottare una soluzione digitale veramente migliorativa per la tua organizzazione: dai a tutti l’opportunità di esprimere il proprio punto di vista e ascolta tutte le esigenze che emergono, senza pregiudizi.
Spesso sono gli stakeholder ad aspettarsi progressi ad intervalli regolari e definiti: cerca di coinvolgere le parti interessate durante il processo di analisi e assicurati che assistano allo scambio di feedback durante le iterazioni.
I collaboratori che adotteranno i nuovi processi e software aziendali sono i tuoi clienti e, se non sono soddisfatti, è improbabile che il progetto di digital transformation abbia successo. Gli aggiustamenti in corso d’opera dovrebbero essere visti come una decisione migliorativa per tutta l’azienda.
Organizza retrospettive di progetto ad intervalli regolari
Anche se i processi aziendali non sono, di fatto, agili, puoi adottare comunque la pratica della retrospettiva di team con cadenza regolare.
Chiedetevi sempre “Come possiamo fare di meglio?”, senza cercare un capro espiatorio per gli errori che emergeranno dalla retrospettiva, ma concentrandovi su ciò che potete fare per non ripetere gli stessi sbagli e migliorare il processo a cui state lavorando.
Ci sono diverse tecniche di retrospettiva, qui ne voglio illustrare molto velocemente 3 che mi sono rimaste impresse per semplicità ed efficacia:
1. La scatola
Questa tecnica me l’ha fatta conoscere Simone D’Amico, e m’è piaciuta moltissimo perché prevede l’utilizzo di una vera scatola. Io adoro utilizzare strumenti tangibili per processi che di fatto non lo sono, quindi rinnovo il mio grazie a Simone.
Per questa restrospettiva appunto serve una scatola, ma possiamo anche disegnarla su una lavagna, dividendo lo spazio in 3 aree come illustrato sotto:
Come si intuisce dal canvas, a sinistra andranno inserite nella scatola quelle idee che vogliamo in pratica nella prossima iterazione/sprint/ciclo di produzione; a destra vanno indicate quelle pratiche da interrompere — quindi togliere dalla scatola — e infine sotto vengono indicate riti e strumenti che hanno funzionato e il team vuole continuare a mantenere nel progetto (e nella scatola).
2. La barca a vela
In questo modello di retrospettiva dobbiamo immaginare il progetto a cui stiamo lavorando come una barca a vela che sta navigando in mare. Oltre alla barca-progetto ci sono altri elementi dello scenario che vogliamo esplorare, e sono:
- il sole, ciò che rende felice il team (non previsto nel canvas originale);
- l’ancora, ovvero tutto quello che rallenta il team, gli ostacoli che intralciano il progesso del progetto;
- il vento, ciò che consente alla barca vela ad andare avanti, quindi tutto quello che è d’aiuto al team e permette di avvicinarsi all’obiettivo;
- gli scogli, cioè i rischi che potrebbero far fermare il progetto e/o distruggerlo. Possiamo distinguere tra rischi visibili (gli scogli) e rischi percepiti ma non chiari (le rocce del fondale).
3. La stella marina
La retrospettiva a stella marina ha un canvas molto semplice e si presta benissimo per le retrospettive da remoto. Dobbiamo dividere lo spazio di lavoro in 5 aree:
- Keep Doing: qualcosa che stiamo facendo e funziona, e che vogliamo continuare a fare perché aggiunge valore al progetto.
- Less Of: qualcosa che è stato fatto e ha funzionato, ma che preferiamo ridurre perché non è più utile quanto prima.
- More Of: qualcosa che stiamo facendo e vogliamo incrementare, perché pensiamo possa essere ancora più utile al raggiungimento dei nostri obiettivi.
- Stop Doing: qualcosa che non aggiunge valore al progetto o addirittura è un ostacolo.
- Start Doing: una nuova idea o qualcosa che abbiamo sperimentato in altri progetti e vogliamo introdurre qui perché pensiamo possa esserci d’aiuto.
Se stiamo affrontando una retrospettiva da remoto possiamo utilizzare uno strumento collaborativo e dividere lo spazio di lavoro in 5 colonne, dove ogni partecipante potrà inserire i suoi “post-it” digitali. Trello si presta molto bene a questo scopo, è molto intuitivo e facile da utilizzare anche per i neofiti. Ha anche un plug-in per votare le card inserite (utile per clusterizzare i risultati o fare dot-voting). Per chi vuole simulare una vera lavagna virtuale ed è avvezzo alle retrospettive da remoto suggerisco Miro.
Al termine della retrospettiva, qualsiasi sia il formato scelto, è fondamentale decidere quali azioni intraprendere per migliorare il flusso di lavoro, non solo a parole.
Puoi chiedere al team di raggruppare le idee e proposte simili, organizzando un dot voting tra i partecipanti per far emergere le argomentazioni più importanti per il gruppo, così da decidere quali attività intraprendere al fine di migliorare il flusso di lavoro, la produttività e la felicità del team.
I processi sono difficili da migliorare, devi essere disposto a porre domande difficili e apportare dei cambiamenti… è questo è il cuore della filosofia Agile!
Per approfondire l’argomento AgileFall ti consiglio questo bell’articolo di Rameez Kakodker: 5 reasons why Agile is dead in your organization.
