La narrativa riguardo all’adozione di pratiche agili si sta rapidamente spostando dalla “necessità di fare una trasformazione agile” ad “opportunità di essere una organizzazione agile”: una narrativa che personalmente mi rende felice perchè sposta l’attenzione sull’agilità come aggettivo, qualcosa che si è, e non sull’agilità come qualcosa “da fare”.
Occorre sempre avere un occhio di riguardo a chi non ha iniziato alcuna trasformazione, e sta muovendo i primi passi verso l’agilità, e lo sta facendo in organizzazioni tradizionali, in contesti complessi.
La progressione nel mondo reale non sarà mai quella “da bruco a farfalla” dei case history perfettamente infiocchettati, in cui raccontiamo di quanto siamo fighi perché la trasformazione agile è una cosa vecchia, e di come siamo diventati una organizzazione agile fatta e finita, lasciando alla audience più domande che risposte.
Si fa anche un gran parlare del movimento#noprojects (con tanto di hashtag, perché siamo giovani), che presuppone un passaggio da progetto a prodotto: tutto molto bello e interessante, non fosse che si tratta di un salto quantico (a volte nemmeno così necessario, in alcuni casi forse pure deleterio) per la maggior parte delle aziende.
Le persone, e le organizzazioni di cui fanno parte, non cambiano per salti quantici.
Soprattutto non cambiano per salti quantici immaginari e prescritti come medicina miracolosa, ignorando il contesto.
Prendo quindi un caso reale, quello di un team che adotta Scrum nel contesto di una organizzazione tradizionale, che lavora per progetti, e in cui lo sviluppo di quello che a tutti gli effetti è un prodotto è stato impacchettato come un progetto:
- con scopo fisso ma cliente assente (quindi scopo variabile)
- con budget fisso (che sappiamo già che sforeremo)
- con scadenza fissa (unico punto su cui non possiamo transigere, ci sono le penali)
Questa è tutt’altro che una situazione ottimale, in cui manca la risposta alla domanda “Perché facciamo Scrum?” e anche “Perché vogliamo adottare un approccio agile?”: ma rappresenta la realtà, non sempre l’adozione delle pratiche avviene in maniera pulita, lineare, logica e con un onboarding informato.
Ripropongo qui sotto, in forma semplificata, uno schema abbastanza famoso, che rappresenta una transizione da una organizzazione tradizionale ad una per prodotto, con diversi stadi intermedi.
A volte, le aziende, per fare esperimenti o per pura emergenza, riescono a creare i famosi team cross-funzionali che pare siano l’arma segreta dell’agilità: attenzione che avere persone dedicate ad un progetto, e magari nella stessa stanza, non garantisce automaticamente la performance immediata. Anzi, pare che il 75% dei team cross-funzionali soffrano di qualche tipo di disfunzionalità.
Rispondere alla domanda “Come lavoriamo assieme?” non è mai né facile, né immediato.
I silos, anche se li abbiamo temporaneamente e informalmente abbattuti grazie a qualche forma di approccio agile, restano nella testa e nelle abitudini delle persone, come un arto fantasma.
La maniera più rapida che ho sperimentato per ridurre il periodo di storming, di conflitto di un team è quella di focalizzarsi sulla più piccola e breve attività su cui tutto il team può collaborare.
Ci sono tre modi di farlo, con un livello di difficoltà che aumenta, perché richiede presupposti organizzativi e di competenze sempre più complessi da soddisfare:
- Swarming
- Mobbing
- Pairing
Swarming: forse la modalità operativa più semplice da approcciare: il limite è fissato sulla quantità di attività da fare, che è una sola, su cui collabora tutto il team.
Le persone sono libere di organizzarsi come credono nel gestire le varie sotto-attività, l’importante è che, nello spirito Kanban dello “stop starting, start finishing” non vengano aperte altre sotto-attività relative ad altre attività.
Ognuno può lavorare dal proprio computer, anche in maniera asincrona.
Mobbing: questa modalità può risultare quella più estrema di queste tre: prevede che tutto il team lavori su una singola attività, su un singolo computer, ruotando le persone coinvolte ad intervalli regolari.
Pairing: questa modalità riduce enormemente la quantità di persone coinvolte rispetto al mobbing. In questo caso sono due le persone coinvolte, che lavorano su un singolo computer, su una singola attività, alternando due ruoli, quello di pilota e navigatore.
Questi approcci non implicano che si stia facendo una trasformazione agile, o che si sia una organizzazione agile: di nuovo, in situazioni di emergenza è probabile che questi approcci li abbiate usati anche nel più waterfall dei progetti.
Inoltre i limiti fisici (una tastiera, una singola attività) possono essere facilmente ri-creati in maniera virtuale, rendendo questi approcci applicabili anche nei casi di team che lavorano in maniera remota e distribuita.
Tutti questi approcci, benché faticosi da mettere in pista, hanno queste caratteristiche:
- Focalizzano tutto il team sul “done” di una attività, una storia, una funzionalità
- Incrementano enormemente la condivisione della conoscenza
- Velocizzano la costruzione di un linguaggio comune
- Aumentare la qualità di quello che stiamo producendo
- Riducono necessità e frequenza di aggiornamenti formali
- Diminuiscono l’efficienza nel breve per aumentare l’efficacia nel medio-lungo periodo
La domanda con cui vi lascio è: come fare diventare queste pratiche qualcosa che si fa per abitudine, e non solo quando siamo in emergenza?
Davide Tarasconi 