Il metodo waterfall si sta infiltrando nel tuo Agile? Scopri i 7 segnali!

Agile ha conquistato il mondo del business, ed è facile capirne il perché. Con il suo focus sulla centralità del cliente, la rapidità di rilascio sul mercato e la promozione di un ambiente innovativo, sempre più organizzazioni stanno adottando con entusiasmo il paradigma Agile. Tuttavia, a volte, nonostante l'adozione di framework come Scrum, i risultati ottenuti non sono quelli attesi e il vero spirito Agile sembra mancare all'interno dei team.

Per essere chiari: non c'è nulla di intrinsecamente sbagliato nel metodo waterfall. È un approccio perfettamente adatto a certi tipi di progetti (come la costruzione di un edificio, per esempio). Ma quando si punta a un'adozione Agile e ci si ritrova invece con il metodo waterfall, allora è un problema. Come possiamo diagnosticare questa "sindrome del waterfall nascosto" e, soprattutto, qual è la cura? Ecco cosa esploreremo in questo articolo.

#1 Sintomo: Struttura funzionale del team

Cos'è?

In una struttura funzionale, invece di collaborare su un prodotto o un incremento di prodotto, ogni team si concentra su un passaggio specifico del processo di sviluppo, come design, coding, testing e così via. Anche se ogni team potrebbe seguire diligentemente un framework Agile, alla fine deve passare il lavoro agli altri team e coordinarsi costantemente per completare il prodotto.

Perché è un problema?

Questo approccio introduce diversi ostacoli. Il coordinamento diventa un'impresa titanica, portando spesso alla creazione di Gantt chart e piani di progetto - un classico del metodo waterfall. Inoltre, ogni team si occupa solo della propria parte, e nessuno si assume davvero la responsabilità dell'esperienza complessiva del cliente. La consegna end-to-end di ogni nuova funzionalità o prodotto potrebbe richiedere mesi, poiché deve passare attraverso più team e superare continue deprioritizzazioni.

Cosa fare?

La soluzione è creare team cross-funzionali che includano tutte le competenze necessarie per realizzare il prodotto. Se il prodotto è troppo grande per un solo team, considera la creazione di team focalizzati su una specifica funzionalità o area di servizio, evitando di dividerli per funzioni. In questo modo, potrai preservare l'agilità e la collaborazione che sono alla base del metodo Agile.

#2 Sintomo: Suddivisione orizzontale del lavoro

Cos'è?

Immagina il tuo prodotto finale come una torta, con diversi strati che rappresentano design, funzionalità e test. Anche se non puoi servire subito l'intera torta ai tuoi clienti, vorresti offrire loro una fetta ben bilanciata (con tutti gli strati e la glassa), in modo che possano assaggiarla e fornire un feedback. Questa "fetta" rappresenta una funzionalità, una suddivisione verticale attraverso tutti gli strati che offre un valore percepibile al cliente. Purtroppo, i team spesso cercano di risparmiare suddividendo il lavoro orizzontalmente: prima si progettano tutte le funzionalità, poi si implementano e, infine, si testano.

Perché è un problema?

Anche se può sembrare una strategia che fa risparmiare tempo, in realtà è una trappola. Immagina di trascorrere settimane a creare quella che ritieni sia la torta al cioccolato perfetta, solo per scoprire che i tuoi clienti odiano il cioccolato. Invece di preparare l'intera torta per poi scoprire che non piace, Agile propone di realizzarla una fetta alla volta. Questo approccio potrebbe sembrare più costoso in termini di risorse, ma permette di testare rapidamente le ipotesi e di essere flessibili, principi fondamentali di Agile.

Cosa fare?

Le user story offrono una soluzione semplice. Sebbene non siano l'unico modo per strutturare il lavoro, sono estremamente efficaci nel guidare i team verso una suddivisione verticale del lavoro. Inoltre, assicurati sempre di articolare chiaramente il valore per il cliente per ogni elemento di lavoro. Ad esempio, "disegnare un pulsante" non ha un valore evidente, mentre "introdurre una funzione di disiscrizione" offre un valore chiaro al cliente.

#3 Sintomo: Roadmap e piani rigidi

Cos'è?

Immagina di avere una visione chiara delle funzionalità da lanciare in questo trimestre, e persino dell'ordine preciso in cui saranno rilasciate. L'ambito del lavoro è determinato fin dall'inizio e rimane immutabile. Anche se puoi pianificare gli sprint e dare priorità al backlog, l'aspettativa è che il tuo team consegni un insieme specifico di funzionalità.

Perché è un problema?

Uno dei vantaggi principali di Agile è la capacità di adattarsi alle circostanze mutevoli, imparare continuamente dai clienti, migliorare e cambiare direzione quando necessario. Un ambito fisso ostacola questa flessibilità e limita il potenziale per sperimentare e rispondere a un ambiente in evoluzione.

Cosa fare?

Mentre la pianificazione su larga scala (annuale, trimestrale) è cruciale, dovrebbe fungere da guida, non da decreto immutabile. Ogni team dovrebbe avere la flessibilità di adattare i propri piani e gestire le dipendenze esterne in tempo reale. In questo contesto, gli OKR (Objectives and Key Results) si rivelano una soluzione eccellente. Spostano l'attenzione dagli output (le funzionalità specifiche che vogliamo consegnare) agli outcome (il valore che vogliamo generare per il business e i clienti), allineandosi maggiormente ai principi Agile.

#4 Sintomo: Rilasci e milestone di grandi dimensioni

Cos'è?

Potresti avere flessibilità sulle funzionalità, ma hai fissato milestone e date di rilascio. In questo caso, è molto probabile che tu stia inconsapevolmente introducendo elementi waterfall nel tuo approccio Agile. Spesso, i manager introducono scadenze artificiali con l'intento di "mantenere i team concentrati" e "motivarli a lanciare più velocemente". Ironia della sorte, questo approccio spesso ottiene l'effetto opposto.

Perché è un problema?

Puntare a rispettare una scadenza mette il team nella morsa del triangolo della gestione di progetto: ambito, budget e tempistiche. Un programma serrato incide inevitabilmente sull'ambito (o sul budget, anche se quest'ultimo è di rado facile da modificare), spostando il focus del team dal massimizzare il valore per il cliente al rispettare i vincoli temporali. Lo stress delle scadenze influisce negativamente sulla salute del team e sulla motivazione individuale. Inoltre, idee innovative vengono spesso respinte poiché percepite come distrazioni dall'obiettivo immediato di rispettare la scadenza.

Cosa fare?

Anche se può sembrare controintuitivo, considera l'idea di eliminare le scadenze e lascia che ogni team stabilisca il proprio ritmo. Anche in questo caso, gli OKR si dimostrano utili. Concentrandosi sul raggiungimento di risultati specifici, i team sono responsabili delle loro performance, pur mantenendo la libertà di decidere su cosa lavorare e in quale ordine. Questo approccio favorisce un ambiente più produttivo e meno stressante.

#5 Sintomo: Metriche e risultati della ricerca che non influenzano i piani

Cos'è?

Potresti seguire un framework Agile e mantenere flessibilità nell'ambito, ma ti adatti rapidamente a ciò che apprendi? Spesso, i team conducono ricerche sui clienti e raccolgono risultati di test, ma l'inerzia li porta a seguire la traiettoria iniziale, ignorando queste scoperte. Un chiaro segnale di pensiero waterfall latente è l'incapacità di rispondere a un ambiente in continua evoluzione.

Perché è un problema?

Ignorando nuove informazioni, rischi di perdere opportunità significative e di sprecare tempo su iniziative che nessuno desidera. Rimanere rigidamente fedeli a un piano iniziale, nonostante nuove evidenze suggeriscano una direzione diversa, soffoca innovazione e soddisfazione del cliente.

Cosa fare?

Ogni nuova informazione dovrebbe influenzare il processo di pianificazione, sia che si tratti di cogliere opportunità inaspettate sia di abbandonare funzionalità che i clienti non apprezzano. Più velocemente riesci ad apportare queste modifiche, meglio è. Inizia le riunioni di pianificazione rivedendo gli ultimi risultati delle analisi e assicurati che le priorità del prodotto siano allineate con il cliente e il mercato. In altre parole, lascia che i dati guidino il tuo approccio Agile.

#6 Sintomo: Valorizzare l’output più dell’outcome

Cos'è?

Se un team si concentra maggiormente sul "portare a termine i compiti" piuttosto che sul "generare risultati", non si sta preparando al successo. In Giappone, dove vivo, questo è un problema significativo. Puoi ideare una soluzione innovativa che faccia risparmiare molto tempo e denaro all'organizzazione, ma la promozione potrebbe andare al tuo collega che passa più ore in ufficio ogni giorno (spesso senza essere particolarmente efficiente) perché è percepito come "più impegnato". Ma in Agile, vogliamo lavorare in modo più intelligente, non più duro!

Perché è un problema?

Dare priorità all'output rispetto all’outcome porta a incentivi mal riposti e a una preferenza per la quantità rispetto alla qualità. Il focus sull'output ostacola approcci creativi: perché pensare a modi innovativi per offrire valore al cliente se possiamo semplicemente inondarli di funzionalità inconsistenti?

Cosa fare?

Anche in questo caso, gli OKR si dimostrano lo strumento più efficace per spostare l'attenzione verso gli outcome. Quando i membri del team fissano obiettivi individuali, questi dovrebbero allinearsi agli obiettivi del team e sottolineare il loro contributo agli outcome, non solo agli output. In altre parole, non conta quanto fai, ma l'impatto di ciò che fai.

#7 Sintomo: Mancanza di sicurezza psicologica

Cos'è?

In ambienti privi di sicurezza psicologica, i membri del team non si sentono liberi di condividere le proprie idee, mettere in discussione i piani o fornire feedback reciproci. Il team ha paura di sperimentare a causa del rischio di fallire. Il fallimento è visto come qualcosa di negativo, da evitare a tutti i costi.

Perché è un problema?

La mancanza di sicurezza psicologica significa perdere molte opportunità. Idee potenzialmente brillanti non vengono mai condivise e nessuno interviene quando vengono prese decisioni sbagliate. L'apprendimento è limitato poiché la sperimentazione è soffocata e il feedback - uno strumento cruciale per la crescita personale - non viene scambiato. Inoltre, un ambiente del genere non favorisce un lavoro confortevole e produttivo.

Cosa fare?

Lo sviluppo della sicurezza psicologica dovrebbe partire dalla leadership: dai l'esempio, mostra vulnerabilità e trasmetti il messaggio che sbagliare va bene. Premia l'atto di sperimentare, non solo il successo o il fallimento. Crea un ambiente in cui i fallimenti siano discussi apertamente e trattati come opportunità di apprendimento, non come qualcosa da temere.

Ribadisco che non c'è nulla di intrinsecamente sbagliato nel metodo waterfall se scelto consapevolmente e nel giusto contesto. Tuttavia, quando si insinua nel tuo percorso Agile senza invito, può diventare un ostacolo. Spero che questo articolo abbia fatto luce sui modi in cui il waterfall nascosto può impattare negativamente il tuo team e che ora ti senta equipaggiato con gli strumenti per contrastarlo.

Ricorda, Agile non è la destinazione, ma il viaggio. È semplicemente un modo di lavorare che ti aiuta a raggiungere i tuoi obiettivi e a generare più valore. Quindi, invece di ossessionarti nel diventare "100% Agile", usa il buon senso e chiediti sempre se stai massimizzando l'efficienza per te stesso e per il tuo team in ogni momento. Buon proseguimento nel tuo viaggio Agile!