Prosegue la riflessione sui due mondi che devono dialogare, ragionando sulle strategie per integrare Agile e Waterfall.

Nella prima parte abbiamo cercato di inquadrare gli elementi che sono un pò alla base delle strategie per integrare Agile e Waterfall, fornendo un’esempio di mappatura di requisiti in user stories. Ora andiamo avanti provando ad esaminare alcuni aspetti concreti di questo non infrequente scenario.

Dal documento dei requisiti al backlog

Giunti a questo punto, abbiamo due possibilità. Più una terza.

Opzione 1

La prima è che riusciamo a convincere il cliente che il nostro elenco di user stories equivale e semmai è più completo del documento iniziale di requisiti. Le argomentazioni alla base di quest’opera di convincimento sono due: l’equivalenza informativa dei due strumenti e la possibilità di gestire meglio i cambiamenti successivi. Perchè se una cosa è certa in un progetto è che subirà modifiche in corso d’opera. Se abbiamo mappato correttamente le user stories sui requisiti abbiamo ottime possibilità di riuscirci.

Questo scenario ci dà offrirà tutti gli strumenti per la gestione del cambiamento e d’ora in avanti noi e gli utenti parleremo la lingua delle user stories. Una modifica? Una user story. Un cambio di priorità? Cambiamo l’ordine nel backlog. Un rilascio? Ecco le user stories rilasciate. Voilà.

Opzione 2 (piano B)

La seconda è il piano B. Se non possiamo o non siamo in condizione di rientrare nel primo scenario, per qualsiasi motivo, dobbiamo cercare di suddividere il progetto in tranches di due mesi circa, in modo da negoziare nel dettaglio i contenuti di ciascuna tranche solo all’approssimarsi della successiva partenza. La trasformazione in user stories resterà un fatto pressochè interno al gruppo, ma tenendo corti i tempi di pianificazione e rilascio saranno minime le esigenze di cambiamento nel corso della tranche. Esigenze che, se si presentassero, renderebbero necessaria l’integrazione del backlog ma anche del documento dei requisiti tradizionale.

Terza possibilità

Se nessuna di queste strategie per integrare Agile e Waterfall è attuabile, dovremo predisporci ad affrontare un sovrappiù di lavoro per tenere aggiornati i documenti necessari nella lingua del cliente. Cerchiamo di tenerne conto nelle stime e, da parte nostra, gestiamolo come un requisito di rilascio ulteriore, nella definition of done del team.

In ogni caso, è estremamente utile avere dei riferimenti nell’organizzazione cliente da contattare per riportare al più presto eventuali feedback che venissero dallo sviluppo (problemi, ma anche opportunità) e da cui attendersi eventuali variazioni di priorità o specifiche.

Trasformare i momenti di contatto

Ogni progetto tradizionale ha dei momenti di contatto prestabiliti con il cliente: kickoff, riunioni di avanzamento, validazione dei requisiti. Questi momenti possono essere trasformati in preziose opportunità di collaborazione agile.

La classica riunione di validazione requisiti può diventare una sessione di refinement dove, invece di limitarci a chiedere è corretto?, possiamo esplorare scenari d’uso e casi limite, arricchendo la nostra comprensione delle necessità reali. Lo Stato Avanzamento Lavori mensile può trasformarsi in una mini-review dove, oltre a presentare le percentuali di completamento, mostriamo il prodotto in evoluzione, raccogliendo feedback prezioso e aiutando il cliente a crescere nella sua stessa comprensione delle finalità e dell’utilizzo del prodotto che si sta realizzando.

Se il ciente ha aderito al piano A ed ha imparato la lingua delle user stories, questi incontri non saranno troppo diversi dalle cerimonie a cui siamo abituati. Magari seguiremo la ritualità del cliente, ma i contenuti e gli effetti non si scosteranno troppo dalle prassi a cui siamo abituati.

Se siamo dovuti passare al piano B, probabilmente questi incontri avverranno verso la fine di ogni tranche. Idealmente lasciando un pochino di spazio per apportare delle modifiche a seguito dei feedback ricevuti.

In ogni caso, facciamo quanto possibile per raccogliere feedback il più precocemente possibile, anche grazie ai nostri contatti nell’organizzazione cliente: E gestiamo i cambiamenti con la negoziazione e la capacità di individuare soluzioni win-win. State pensando che per questo vi servirebbe un buon Business Analyst? Sì, vi serve.

I benefici tangibili per il cliente

Questo approccio, nel cercare strategie per integrare Agile e Waterfall, porta vantaggi concreti che il cliente può apprezzare senza necessariamente padroneggiare la metodologia sottostante:

1. Visibilità continua: Invece di aspettare la fine del progetto per vedere il prodotto, il cliente può osservarne l’evoluzione, verificando che stia andando nella direzione desiderata.
2. Flessibilità controllata: Quando emergono nuove esigenze o cambiamenti di priorità, possiamo gestirli in modo strutturato, valutando insieme l’impatto e trovando il momento migliore per incorporarli.
3. Riduzione del rischio: La verifica continua riduce drasticamente il rischio di sviluppare funzionalità non allineate con le aspettative o che, nel frattempo, sono diventate meno prioritarie.
4. Time to market ottimizzato: Le funzionalità più importanti possono essere completate e utilizzate prima, generando valore mentre il resto del prodotto viene finalizzato.

La gestione di stime e budget

Uno degli aspetti più delicatiè la gestione di stime e budget in modo agile mantenendo la prevedibilità richiesta dai progetti tradizionali. L’approccio che proponiamo, tra le strategie per integrare Agile e Waterfall, ogni volta in cui sia praticabile, è:

• Fornire stime di alto livello per l’intero progetto, basate sulle storie individuate.
• Attribuire una “size” alle varie storie individuate per avere un riferimento alla complessità/quantità di lavoro necessaria a portarla a termine e negoziare in seguito eventuali cambi di priorità del cliente.
• Suddividere il progetto in tranches di durata prevedibile non superiore a due mesi e dettagliare le stime solo per le funzionalità in sviluppo nella specifica tranche
• Mantenere la disponibilità a differire user stories che si rivelano non prioritarie, anticipandone altre della stessa size nella tranche corrente.
• Comunicare regolarmente lo stato di consumo del budget in relazione al valore prodotto oltre che al lavoro svolto.

Questo ci permette di mantenere il controllo sui costi pur conservando la flessibilità necessaria per massimizzare il valore del prodotto finale.

La chiave sta nel mantenere sempre il focus sui benefici concreti per il cliente piuttosto che sulla metodologia utilizzata, negoziando il minimo indispensabile che fa lavorare bene noi e porta benefici al cliente.

Registrare e comunicare i progressi

Abbiamo detto che svilupperemo user stories e che prevediamo di offrire al cliente degli avanzamenti che si basino sul prodotto reale, al di là delle percentuali di completamento. Di conseguenza, è necessario dimostrare in modo chiaro e strutturato come le user stories sviluppate soddisfino i requisiti iniziali stabiliti con il cliente, offrendo un quadro preciso di quanto è stato completato e di cosa rimane ancora in sospeso. E rendendo più semplice l’UAT.

Nell’esempio del software ospedaliero abbiamo mappato le user stories sui requisiti tradizionali del cliente. La mappatura permette di mantenere allineati i team di sviluppo e i clienti, e rende immediatamente chiaro quali requisiti iniziali sono stati completati. Un documento che evidenzi le corrispondenze tra user stories e requisiti, magari organizzato in una tabella sinottica, può essere uno strumento potente per porre le basi dei passi successivi.

Se non abbiamo avuto la possibilità di portare il cliente direttamente sul terreno delle user stories (piano A) nè di suddividere il lavoro in tranches digeribili (piano B), dovremmo mantenere allineato il cliente facendo riferimento in ogni caso ai requisiti iniziali e gestendo eventuali cambiamenti come cambio di requisiti, da una parte, e riscrittura di una o più user stories dall’altra. L’unica altra strategia possibile per integrare Agile e Waterfall.

LA SINTESI CHE ACCOMPAGNA GLI UAT

Prima di presentare il rilascio, sarà in tal caso utile preparare una breve sintesi, che illustri al cliente le funzionalità completate rispetto ai requisiti iniziali. Il documento, presenta cosa sarà effettivamente oggetto di rilascio, negli stessi termini in cui sono stati descritti inizialmente dal cliente.

La sintesi accompagnerà i test di User Acceptance (UAT), fase che fornisce la conferma che le funzionalità soddisfino le aspettative del cliente. Si tratta di un passaggio formale, ma anche sostanziale, che da un punto di vista strettamente agile andrebbe inquadrato in una review e nel lavoro del Product Owner. Dal nostro punto di vista, condurremo l’UAT come un’opportunità di raccogliere preziosi feedback sulle funzonalità rilasciate e sul progetto nel suo insieme.

In ogni caso, è molto importante che, nel corso dello sviluppo, laddove emergano necessità (od opportunità!) di apportare variazioni rispetto a quanto concordato, si possa avere un canale di comunicazione aperto per discuterne, prima di arrivare al rilascio.

Documentazione del Feedback e Azioni per le Iterazioni Future

Una volta concluso l’UAT è indispensable raccogliere e documentare i feedback del cliente, che poi impatteranno sulle iterazioni successive. Un registro che includa i commenti del cliente e le richieste di modifica, può essere utile, ma la cosa essenziale è tenere aggiornato il documento dei requisiti condiviso con il cliente e, conseguentemente, il nostro backlog. In questo modo, i feedback ricevuti diventano parte integrante dello sviluppo successivo, assicurandoci di soddisfare le esigenze degli utenti e prevenendo rischi di futuri malintesi.

Le sfide del mindset agile in contesti tradizionali

Mantenere un autentico approccio agile in un contesto tradizionale è una sfida quotidiana che richiede consapevolezza, preparazione e costanza. Non si tratta solo di adattare pratiche e cerimonie, ma di preservare un modo di pensare che può sembrare in contrasto con l’ambiente circostante.

Le tensioni quotidiane

Il business analyst si trova spesso a dover gestire situazioni che mettono alla prova il suo mindset agile.

•  La richiesta di pianificazioni dettagliate a lungo termine si scontra con il principio di adattabilità: il cliente chiede di sapere esattamente cosa verrà consegnato nei prossimi mesi, con tempi e costi definiti, mentre l’approccio agile suggerirebbe di mantenere flessibilità per adattarsi alle nuove informazioni e ai cambiamenti di priorità che emergono durante lo sviluppo
• La resistenza del cliente a fornire feedback frequente contrasta con l’approccio iterativo: mentre vorremmo mostrare spesso il prodotto in evoluzione per raccogliere indicazioni e correggere la rotta, spesso il cliente preferisce revisioni formali a scadenze fisse, perdendo preziose opportunità di indirizzare lo sviluppo nella giusta direzione
• La tendenza a formalizzare ogni decisione rallenta il processo di sviluppo: la necessità di documentare e far approvare formalmente ogni minima decisione, spesso attraverso lunghe catene gerarchiche, rende difficile mantenere il ritmo di sviluppo agile e rispondere rapidamente ai cambiamenti
• La paura del cambiamento porta a rigidità nell’interpretazione dei requisiti: il timore di assumersi responsabilità per le modifiche porta spesso a un’interpretazione letterale e rigida delle specifiche iniziali, anche quando emergono soluzioni migliori o quando il contesto di business evolve
• La falsa aspettativa delle organizzazioni, specialmente quelle più grandi, che possa esservi un processo lineare di sviluppo (io ti dico, tu fai, io ti pago) è un’illusione che porta a declinare le responsabilità e rifuta tendenzialmente qualunque coinvolgimento fino a fine lavori (se lo dovevo fare io perchè devo pagare un fornitore esterno?).
• La tendenza dell’organizzazione a reagire agli imprevisti cercando responsabilità individuali, invece di affrontarli come opportunità di apprendimento collettivo, ostacola la trasparenza e la collaborazione

Queste tensioni non possono essere ignorate né sorvolate immaginando che la propria organizzazione agile faccia premio sul resto. Come abbiamo visto, richiedono invece un approccio consapevole e strategico.

Strategie di sopravvivenza agile

Gestire la documentazione senza perdere agilità

Il contesto tradizionale richiede spesso documentazione estesa. La vera sfida sta nel mantenerla viva e utile al progetto, evitando che diventi un peso morto. La documentazione deve diventare uno strumento di collaborazione, non un sostituto del dialogo. È fondamentale mantenerla aggiornata in modo incrementale, facendola evolvere insieme al prodotto. Il focus deve sempre rimanere sul valore che questa porta al cliente, più che sulla sua completezza formale.

Bilanciare controllo e flessibilità

Trovare il giusto equilibrio tra le esigenze di controllo del cliente e la necessità di mantenere flessibilità è un’arte delicata. Possiamo proporre milestone verificabili che però non diventino vincoli rigidi. È importante utilizzare metriche che mostrino il valore effettivamente consegnato, non solo l’avanzamento formale. La fiducia si costruisce attraverso piccole consegne frequenti che dimostrano progresso concreto.

Gestire le resistenze al cambiamento

Le resistenze al cambiamento sono naturali e vanno gestite con pazienza e strategia. È importante identificare e coltivare alleati all’interno dell’organizzazione cliente che possano supportare un approccio più flessibile. I benefici vanno dimostrati attraverso risultati concreti, non attraverso presentazioni teoriche. A volte è necessario accettare compromessi tattici, mantenendo però sempre chiara la visione strategica di lungo termine.

Gli errori da evitare

1. Nascondere troppo. Non dobbiamo mascherare il nostro approccio agile, mentre ci impegniamo a parlare il linguaggio del cliente: la trasparenza costruisce fiducia, anche quando rivela alcune complessità.
2. Perdere il focus sul valore. Il rischio di conformarsi troppo alle richieste formali del cliente può farci perdere di vista l’obiettivo principale: consegnare valore.
3. Isolare il team. La tentazione di proteggere il team dalle complessità dell’interazione con il cliente può portare a un pericoloso distacco dalla realtà e dalle esignze del business.

Costruire resilienza nel lungo termine

In alcuni casi, abbiamo l’opportunità di collaborare per un periodo più lungo con un partner cliente. In tal caso, alcuni percorsi possono aiutarci a costruire nel più lungo termine una più solida base di collaborazione.

1. Formazione continua del team. La formazione del team deve essere un processo continuo che va oltre i semplici aspetti tecnici. È fondamentale condividere apertamente le sfide incontrate e le soluzioni trovate, creando momenti di riflessione collettiva. I principi agili vanno rafforzati attraverso la pratica quotidiana, evidenziando come questi ci aiutino a superare le difficoltà concrete. Anche i piccoli successi vanno celebrati, perché contribuiscono a costruire una cultura resiliente.
2. Sviluppo di competenze negoziali. Le competenze negoziali sono cruciali quanto quelle tecniche. Dobbiamo imparare a negoziare mantenendo saldi i nostri principi, costruendo ponti tra culture organizzative diverse. La capacità di comunicare efficacemente con stakeholder che hanno prospettive e priorità diverse diventa una competenza fondamentale per il successo.
3. Creazione di una comunità di pratica. La creazione di una comunità di pratica forte è fondamentale per il successo a lungo termine. Lo scambio di esperienze con altri team che affrontano sfide simili permette di sviluppare e raffinare strategie comuni. Il supporto reciproco nelle sfide quotidiane crea un ambiente di apprendimento continuo e di crescita professionale.

Conclusione: l’agilità come scelta consapevole

Mantenere un mindset agile in un contesto tradizionale, immaginando strategie per integrare Agile e Waterfall, è una sfida continua che richiede consapevolezza, strategia e resilienza. Non si tratta di una battaglia tra paradigmi, ma di un esercizio quotidiano di adattamento e crescita.

Il business analyst gioca un ruolo cruciale in questo processo, agendo come ponte tra culture diverse e dimostrando attraverso l’esempio che è possibile essere veramente agili anche in contesti apparentemente ostili. Il successo non sta nella purezza metodologica, ma nella capacità di generare valore reale mantenendo fede ai principi fondamentali dell’agilità.