Come Business Analyst, magari inseriti in un’azienda che fornisce soluzioni software, nella quale sono state implementate metodologie di lavoro agile, ci troveremo prima o poi a dover gestire una complessità non banale: conciliare la nostra organizzazione agile, faticosamente implementata per garantire qualità, efficienza e capacità di adattamento, con l’esigenza di interfacciarci con clienti che operano secondo modelli tradizionali, secondo processi rigidi e approcci waterfall consolidati. In pratica, fare la gestione agile di commesse waterfall.

Questo articolo prosegue in qualche modo la riflessione su come l’agilità vada ad inserirsi in contesti o tra persone che non sempre hanno un mindset già allenato. Vedi ad esempio l’altro mio articolo sui manager e l’agile.

Il dilemma quotidiano

La fantasia di proporre al cliente una trasformazione verso l’agilità può sfiorarci, ma è ovviamente ingenua. Le organizzazioni hanno i loro tempi di evoluzione, e con ogni probabilità non abbiamo i mezzi per suggerire un cambiamento culturale e organizzativo. Allo stesso tempo, adattarsi completamente al modello tradizionale del cliente significherebbe rinunciare ai vantaggi dell’approccio agile, compromettendo la nostra capacità di consegnare valore in modo efficace.

Perché non possiamo semplicemente essere tradizionali

Mentre ci stiamo chiedendo chi ce l’ha fatto fare di adottare un’organizzazione agile interna, ci tornano in mente i limiti dell’approccio tradizionale.

Quando si aspetta la fine del progetto per mostrare il risultato al cliente, il feedback arriva troppo tardi, quando apportare modifiche diventa costoso e complesso. Inoltre, il mercato e le esigenze di business evolvono rapidamente: un piano definito all’inizio del progetto potrebbe non essere più valido dopo alcuni mesi.

La mancanza di verifiche continue può anche compromettere la qualità del prodotto finale, poiché eventuali incomprensioni o interpretazioni errate dei requisiti emergono solo nelle fasi finali del progetto.

Senza dimenticare che, paradossalmente, un approccio rigido rende più difficile fornire al cliente una visione chiara dell’effettivo stato di avanzamento del progetto, limitandosi spesso a percentuali di completamento che dicono poco sul valore effettivamente prodotto.

La necessità di un approccio equilibrato

La sfida reale non è scegliere tra agile e tradizionale, ma trovare un modo per far comunicare i due approcci, massimizzando i benefici per il cliente. Parlando di gestione agile di commesse waterfall, questo richiede:

1. Pragmatismo: accettare che non tutto potrà essere perfettamente agile
2. Flessibilità: adattare le pratiche agili al contesto specifico
3. Gradualità: introdurre elementi di agilità in modo naturale e non invasivo
4. Trasparenza: mantenere chiari i processi per il cliente
5. Focus sul valore: concentrarsi sui benefici tangibili più che sulle metodologie

L’opportunità nascosta

Questa apparente dicotomia tra agile e approcci tradizionali può trasformarsi in una reale opportunità per entrambi. Operare in modalità agile in casa, mentre si mantiene un’interfaccia tradizionale verso il cliente, apre a diversi vantaggi strategici e operativi.

Per il cliente

Per il cliente, questo approccio fornisce un accesso controllato e progressivo ai cambiamenti, senza la necessità di stravolgere le proprie strutture o complicare le dinamiche interne. La nostra metodologia agile ci consente di assorbire e gestire rapidamente le complessità e le richieste che nascono, senza scaricarle direttamente sul cliente. Così facendo, il cliente percepisce i benefici tangibili del cambiamento — sotto forma di soluzioni pronte e ben implementate — senza doversi necessariamente confrontare con le sfide della metodologia.

Per il fornitore

Dal punto di vista del fornitore, questa modalità di lavoro permette di mettere in luce i vantaggi concreti dell’agile, come la velocità di esecuzione e la capacità di adattamento alle esigenze in evoluzione. Grazie a cicli di rilascio più frequenti e risultati prevedibili, il team può dimostrare il valore del proprio operato in modo continuativo, consolidando la reputazione di partner affidabile e reattivo. Consegne cadenzate e trasparenti rafforzano la fiducia, alimentando una relazione positiva che si basa su risultati costanti e sull’assenza di sorprese inattese.

Inoltre, questa collaborazione favorisce una graduale familiarizzazione del cliente con pratiche più agili, che possono venire adottate in modo naturale nel tempo. Il cliente inizia così a percepire il valore dell’agilità nei risultati ottenuti, il che può portare a una maggiore apertura verso questo approccio e, in alcuni casi, a un’evoluzione graduale del proprio modo di lavorare.

In definitiva, anche se l’integrazione di due metodologie così diverse può essere una sfida, affrontarla nel modo giusto crea una collaborazione più efficace e solida, che porta benefici significativi a tutti gli stakeholder coinvolti.

Abbiamo delineato i temi di questa convivenza a dir poco sfidante. Nelle sezioni successive esploreremo alcune tecniche ed accorgimenti pratici per implementare con un adeguato grado di successo questo modello ibrido.

Dal principio alla pratica: come essere agili senza chiederlo agli altri

Come possiamo applicare concretamente i principi agili mantenendo un’interfaccia tradizionale con il cliente? La chiave sta nel concentrarsi sugli aspetti che portano valore immediato, adattando le pratiche agili al contesto specifico. Vediamo come farlo in modo efficace.

La preparazione è tutto

Il primo passo di una gestione agile di commesse waterfall, è una attenta analisi della documentazione di specifiche fornita dal cliente. Invece di leggerlo semplicemente in modo sequenziale, dobbiamo “tradurlo” in strumenti che ci permettano di lavorare in modo agile. Questo significa:

• Raggruppare i requisiti per aree funzionali e valore di business
• Trasformare i requisiti esposti linearmente in user stories e criteri di accettazione
• Identificare gli user journey principali, anche se non esplicitati nel documento
• Creare una story map che ci aiuti a visualizzare il prodotto nel suo insieme
• Evidenziare le aree di ambiguità che richiederanno maggiore collaborazione e approfondimento

Questo lavoro preliminare, invisibile al cliente, ci permette di organizzare lo sviluppo in modo agile pur mantenendo la tracciabilità con i requisiti originali.

L’idea base è che una serie di requisiti può essere ad esempio rimappata in una o più user stories con uno o più criteri di accettazione. La trasformazione dei requisiti in user stories è a mio avviso imprescindibile perchè solo in questo modo definiamo dei blocchi di lavoro maneggiabili da un team agile, in grado di descrivere effetttivi incrementi di valore, che potranno essere sviluppati e rilasciati all’utente, E nello stesso tempo, creiamo i presupposti per far comunicare tra loro due modi diversi di descrivere il lavoro.

Spendiamo aolora un pò di tempo ed entriamo nel merito, con un esempio concreto.

Un esempio: dati anamnestici del paziente per un software ospedaliero.

Vediamo in che modo è possibile trasformare un classico paragrafo di di un lungo documento, fornito dal cliente, con i requisiti del software da sviluppare, in user stories. Il business analyst ha inserito nel testo dei numeri per mappare i requisiti.

L’esempio, calato in un contesto di gestione agile di commesse waterfall, rende peraltro evidente che l’esigenza di redigere le user stories avrà portato alla necessità di approfondire con l’utente le finalità dei vari aspetti della funzione richiesta, oltre che ad esplicitare e chiarire funzionalità “nascoste”, come la modifica dei dati, appena accennata nel testo waterfall ricevuto dal cliente.

Negli acceptance criteria entreranno anche i requisiti non funzionali, che spesso nella documentazione tradizionale scarseggiano: quanti utenti contemporaneamente devono poter accedere? Che tempi di risposta sono previsti? Quanto crescono in fretta i dati?…

Lasciamoci così…

Abbiamo inquadrato per grandi linee il problema e immaginato in che modo, al livello più elementare, dei requisiti, mettere le basi per creare l’interfaccia tra i due mondi e consentire la gestione agile di commesse waterfall. Ma per far parlare tra loro culture così diverse occorrono altri elementi importanti. Nella seconda parte proveremo a visualizzarne qualcuno.