Non si è agili... con un Waterfall agile

Molte organizzazioni si definiscono agili. Chi non vorrebbe essere agile? Se non si è agili, non si è forse per definizione pesanti, lenti e inerti?

Poche organizzazioni si descriverebbero così; tuttavia, Agile nel mondo dello sviluppo, del miglioramento e della manutenzione del software significa molto di più che poter agire velocemente e con leggerezza. Agile significa che un team o un'organizzazione adotta determinati principi che plasmano i comportamenti e portano a interiorizzare determinati metodi.

Quando non si agisce come si dichiara, il management spesso ostacola i principi e i professionisti ostacolano i metodi. I metodi nelle organizzazioni sono spesso molto radicati e richiedono un notevole sforzo di cambiamento. Alcune organizzazioni affermano di utilizzare un approccio misto, passando da un approccio più classico a una combinazione di Scrum, Kanban e Extreme Programming. Questo viene visto come un approccio sicuro e conservativo che permette all'organizzazione di cambiare organicamente. Il problema, però, è che questa tattica raramente funziona e le organizzazioni si trovano rapidamente in una situazione di stallo. Se non si investe abbastanza tempo e impegno nel change management, si arriva velocemente a framework ibridi che non sono né carne né pesce – e questi sono solo estremamente raramente agili.

Indicatori di organizzazioni bloccate (o potenzialmente bloccate)

Il Waterfall iterativo:

Il classico Waterfall iterativo ha le sue radici nel modello a spirale di Barry W. Boehm. In questa pseudo-versione dello sviluppo iterativo vengono utilizzate brevi iterazioni a tempo limitato per ciascuna delle fasi classiche del Waterfall. A uno Sprint di requisiti segue uno Sprint di design, poi uno Sprint di sviluppo ecc. Sia il modello a spirale classico sia la pseudo-versione di Agile sono comunque molto più adatti del classico modello Waterfall per generare feedback e consegnare valore più rapidamente; tuttavia, le organizzazioni smettono di evolversi ulteriormente verso Agile e raccolgono così solo una parte dei frutti.

Definire i requisiti in anticipo:

In questo approccio ibrido ad Agile, i team o le organizzazioni raccolgono tutti i requisiti (a volte chiamati feature) all'inizio del progetto e li fissano prima che il lavoro effettivo inizi. Agile si basa su certe assunzioni riguardo ai requisiti. Due delle principali assunzioni sono che i requisiti emergono continuamente e che – una volta conosciuti – scompaiono nel tempo. Fissare i Product Backlog in anticipo contraddice entrambe queste assunzioni. Inoltre, riporta i team e le organizzazioni a un'epoca in cui venivano sviluppate soluzioni che alla fine non corrispondevano alle esigenze aziendali attuali. Questo approccio si verifica spesso quando l'introduzione di Agile viene effettuata con un approccio graduale, iniziando con gli sviluppatori e coinvolgendo poi i Business Analyst ecc. Tra i gruppi che hanno interiorizzato Agile e quelli che non lo hanno fatto può spesso crearsi un attrito aggiuntivo, che viene frequentemente attribuito ai metodi agili, rendendo così più difficili ulteriori cambiamenti.

Testare dopo che lo sviluppo è "done":

Una delle forme ibride agili più pericolose è il test dopo lo sviluppo completato. Ho già conosciuto questa forma ibrida con il nome „Sviluppo + 1 Sprint”. In questo scenario, un team sviluppa una soluzione (codice funzionante per un problema software), la dimostra ai clienti, dichiara che è „done” e POI la passa ai tester. I tester trovano SEMPRE qualcosa. Pertanto il software viene restituito, per lavorarci direttamente (il che interrompe lo Sprint corrente) oppure spostare il tutto nel Backlog per occuparsene più tardi. I principi agili supportano il completamento di software consegnabile (o almeno potenzialmente consegnabile) alla fine di ogni singolo Sprint. Consegnabile significa TESTATO. Due varianti un po' meno drammatiche di questo problema sono l'uso degli Hardening Sprint e il test alla fine di un progetto. Almeno in questi casi non si afferma di essere agili.

Conclusione su Agile e Waterfall

Il modo in cui le persone lavorano è l'unico indicatore sicuro per stabilire se un'organizzazione è agile o meno. A volte il modo di lavorare di queste persone riflette un passaggio ad Agile – tuttavia presumo che ci si bloccherà presto se questo passaggio non viene effettuato con grande impegno. Se un team o un'organizzazione vogliono adottare Agile, si sceglie un progetto e si fa lavorare con Agile tutti coloro che sono coinvolti in quel progetto, contemporaneamente e durante l'intero flusso di lavoro. Se ciò significa dover fare coaching a un intero progetto o a un intero team, allora sia così. Questo approccio può essere paragonato a una cipolla che si taglia a fette, raggiungendo ogni singolo strato ad ogni taglio, invece di sbucciare strato dopo strato.

Un'ultima nota: anche se con questi approcci ibridi si arriva a un certo punto ai propri limiti, sono probabilmente comunque migliori dei metodi che si utilizzavano prima. Questo non vuole essere un atto d'accusa contro le persone che hanno difficoltà nel passaggio ad Agile. Vuole piuttosto essere uno stimolo per loro a continuare.

Questo testo proviene dal blog di SPamCAST ed è stato tradotto in italiano.