Non si è “agile” quando... Modelli ibridi

Le conversazioni che ho avuto con colleghi, lettori del mio blog e un professore della Pennsylvania State University su tali ostacoli hanno suscitato discussioni appassionate sul valore relativo e sull’utilità dei modelli ibridi.

Waterfall

I metodi classici per lo sviluppo software sono come una cascata che inizia con la definizione dei requisiti e finisce con l’implementazione. Il lavoro viene eseguito in singoli passaggi lungo le fasi di questa cascata – in modo simile al lavoro in catena di montaggio nella produzione automobilistica. Il prodotto è funzionante solo quando esce dalla linea alla fine. In questo modello, determinati lavori vengono sempre eseguiti dagli stessi specialisti. Henry Ford ha rivoluzionato il mercato automobilistico con questo metodo.

Questo tipo di sviluppo software può però anche favorire ogni sorta di comportamenti negativi. La ragione è generalmente l’incompatibilità tra il lavoro in catena di montaggio (ad es. nella produzione) e lavori più dinamici, più orientati alla ricerca e allo sviluppo. Un esempio di tale comportamento negativo è l’uso improprio dei cosiddetti “Stage Gate” (milestone tra le singole fasi). Spesso i team continuano semplicemente a lavorare, anche se il metodo prevede di attendere una decisione per uno Stage Gate. Il problema è che non sarebbero mai pronti in tempo se aspettassero una decisione. I manager sanno SEMPRE cosa sta succedendo, ma preferiscono non fare domande. La ragione di ciò non è normalmente che qualcuno nel processo lavori male, ma piuttosto che il processo stesso è difettoso.

Agile è diverso

Agile interrompe questa cascata e suddivide il lavoro in parti più piccole. Queste parti più piccole vengono poi progettate, sviluppate, testate e consegnate con l’aiuto di brevi Sprint per ottenere feedback diretto. Grazie al “nuovo” processo non c’è più motivo di ignorare i cartelli di stop degli Stage Gate.

I modelli ibridi dovrebbero utilizzare il meglio dei framework classici e agili e adattarsi così in modo ottimale alla cultura e alla struttura attuale dell’organizzazione. Voler adattare i metodi agili a un’organizzazione che in realtà è progettata per metodi classici è il punto in cui spesso si insinuano i problemi. I compromessi necessari sono spesso in contrasto con i presupposti dei valori e dei principi agili.

Esempi di tali presupposti in Agile sono team stabili, responsabilità propria e la consegna di software funzionante alla fine di ogni Sprint. È più facile allontanarsi da questi valori e principi che cambiare la cultura e la struttura dell’organizzazione. Uno dei compromessi più comuni (e dannosi) può essere osservato nelle organizzazioni che continuano a lavorare con team a composizione dinamica (spesso chiamate organizzazioni a matrice). I team stabili richiedono spesso la riprogettazione dei confini organizzativi e una verifica più accurata delle competenze.

Questi sono i problemi tipici che – se non vengono affrontati – possono indurre un’organizzazione a utilizzare forme miste di metodi classici e agili:

Silos: quando singoli gruppi sono separati gli uni dagli altri, serve più pianificazione e coordinamento per garantire che le persone giuste siano disponibili al momento giusto – anche in caso di ritardi. Le grandi organizzazioni di sviluppo hanno inserito il ruolo di uno Scheduler (pianificatore del lavoro) o di un Expediter (supervisore delle scadenze) nel loro organigramma per gestire questo tipo di problemi.

Troppo snelli: molte organizzazioni di sviluppo soffrono di anni di misure di risparmio e hanno molte meno persone disponibili di quante ne servano per completare il lavoro a cui si sono impegnate. I collaboratori lavorano attivamente su più progetti diversi per dare l’impressione di fare progressi in tutta una serie di ambiti. Passare da un compito all’altro è altamente inefficiente e riduce il valore consegnato, il che spesso porta a una pressione ancora maggiore per ridurre i costi.

Mancanza di focus: i dirigenti nelle organizzazioni di sviluppo hanno spesso il bisogno di accettare e portare avanti tutti i progetti che vengono presentati. Questo viene anche chiamato “sindrome del sì”. Si verifica per lo più nelle organizzazioni che non dispongono di una forte gestione del portfolio. In definitiva, ciò significa che team e collaboratori sono costretti al multitasking, il che a sua volta porta a inefficienza.

Troppo poca automazione: non ho mai conosciuto un metodo di sviluppo che non si potesse eseguire in piccolo con carta e penna. Una scala più grande diventa però possibile attraverso l’automazione. Immaginate ad esempio di dover scrivere a mano alcune migliaia di test di regressione. Per eseguire i test servirebbero o molto tempo o molte persone. Molte persone significano normalmente anche più team, più confini tra team, più gerarchia e più sforzo – il che può eventualmente portare a meno test eseguiti perché ci si deve attenere a una scadenza o a un certo budget.

I valori e principi su cui si basa Agile sono davvero importanti. Influenzano i comportamenti in modo che ci si concentri maggiormente sulla consegna più rapida di valore. I quattro valori del Manifesto Agile sono presentati come coppie. Ad esempio, il primo dei quattro valori dice: “Gli individui e le interazioni più che i processi e gli strumenti”. Le cose a sinistra hanno un valore più alto di quelle a destra (anche se queste naturalmente hanno ancora un valore). Con i modelli ibridi vengono spesso creati compromessi che spostano l’enfasi dai punti a sinistra più verso il centro o addirittura di nuovo verso i punti a destra.

I modelli ibridi non sono fondamentalmente cattivi o sbagliati

Quando però ci si allontana dai valori e principi agili fondamentali invece di affrontare questioni difficili nell’organizzazione, spesso si tratta solo di manovre diversive. Che siate d’accordo o meno con tutto ciò, i vostri pensieri su questo tema sono importanti e guidano la conversazione su cosa sia Agile e cosa no.

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