Verso l‘Agile

I parte: L'importanza dell'apprendimentodi

Presentiamo in questa miniserie una serie di concetti basilari, derivanti dalla realtà con cui ci misuriamo quotidianamente, che possono fungere da strumenti abilitanti verso i fondamenti dell'Agile. Nel caso specifico, tali principi sono stati usati come preparazione in un paio di transizioni agili, tramite l'adozione di tecniche di Accelerated Learning.

Di che cosa parliamo

In questi articoli vogliamo riportare esperienze e riflessioni che riguardano in particolare una serie di concetti "collaterali" all'adozione delle metodologie agili, ma che possono rivelarsi cruciali specie verso certe "resistenze" e difficoltà che si incontrano con i gruppi di persone nel processo di transizione agile verso l'adozione, per esempio, di Scrum. L'adozione di una nuova metodologia in genere prevede una parte di formazione e una di affiancamento.

Per la parte di affiancamento in genere si adottano le tecniche tipiche del coaching, mentre la parte formativa può essere messa in atto tramite diverse tecniche alternative. Una cosa che ha catturato la mia attenzione e che sto portando nei gruppi in maniera sistematica, sono le tecniche di accelerated learning.

Un cambiamento di paradigma

Queste tecniche puntano a stravolgere il classico approccio docente-classe puntando più su un apprendimento collaborativo al posto della classica lezione frontale in aula, in cui il docente legge una serie di slides.

Per chi fosse interessato ad approfondire questi concetti consiglio due letture: una è "Accelerated Learning" [AL], l'altra è il "Training from the Back of the Room" [TBR]).

Accelerated Learning

Uno dei passaggi fondamentali di questo approccio è quello di mettere allo stesso pari docente (che di fatto non gioca più il ruolo del  docente, ma dell'"iniettore" di concetti) e la classe; l'apprendimento risulta essere molto più efficace, a parità di tempo e concetti espressi, se la discussione avviene fra le persone del gruppo piuttosto che semplicemente da una visione di slides raccontate al gruppo.

Connecting

Uno degli elementi fondanti che troviamo nell'Accelerated Learning è l'utilizzo del connecting: molto semplicemente, si tratta di trovare il modo di collegare un concetto nuovo che ci viene presentato con qualcosa che già conosciamo o con una visione diversa offerta da qualcuno che già ne sa qualcosa. Prendiamo per esempio il caso di un corso di pittura: al momento in cui ci vengono spiegate le tecniche base per inchiostrare i pennelli, probabilmente ci risulterà più facile ricordare e comprendere come comporre i colori e come diluirli con acqua, se troviamo il modo di collegare questa cosa con quanto facevamo a casa per esempio quando abbiamo reimbiancato le pareti di casa o abbiamo preparato i colori per dipingere un oggetto. Non è la stessa cosa, ma esiste, appunto, una connessione.

Connecting si può fare fra i concetti nuovi che ci vengono proposti e quanto già sapevamo, oppure fra quanto sappiamo noi e quanto sanno i nostri colleghi di corso: per questo spesso si agevola la discussione a gruppi; connecting è anche creare un legame visivo fra quanto ci viene raccontato o stiamo apprendendo e immagini o grafici che ci  circondando: per questo è molto utile per esempio riempire la stanza di informazioni che poi verranno richiamate durante tutto il corso.

Il connecting è una infrastruttura (framework) potentissima: uso la parola "infrastruttura" perche' si può implementare in vari modi; tutti noi la mettiamo in atto in maniera involontaria tutte le volte che ci troviamo di fronte a un concetto nuovo. Il docente che non tiene conto di questo processo mentale, o non lo sfrutta per migliorare il processo di apprendimento, probabilmente non otterrà il massimo dalla propria aula.

Strategie per il connecting

Una delle tecniche con le quali si può realizzare il connecting è di lavorare sul pre-corso: per esempio si possono fornire ai partecipanti prima del corso una serie di concetti propedeutici all'argomento in modo che le persone arrivino con già delle informazioni sui concetti base del corso. Durante il corso poi si possono realizzare dei manifesti appesi alle pareti dell'aula: i partecipanti divisi in gruppetti potranno trovarsi sotto tali manifesti per procedere alla discussione dei punti salienti. Un modo per sfruttare questo processo potrebbe essere quello poi di creare dei piccoli focus group su temi specifici e fare i modo che siano i discenti a raccontare agli altri i concetti appena appresi.

Ci sono varie tecniche per facilitare la discussione, per favorire la "trasmigrazione" dei concetti all'interno dell'aula. Nel libro "Training from the Back of the Room!: 65 Ways to Step Aside and Let Them Learn" queste tecniche sono spiegate molto bene, per cui consiglio la lettura del libro da usare come "cassetta degli attrezzi" da usare in funzione del bisogno.

Un'esperienza personale

Di recente, durante la fase di formazione propedeutica alla transizione agile verso Scrum, i partecipanti al corso hanno ricevuto nell'arco di una decina di giorni i concetti in modo da arrivare già un po' "infarinati" al corso. Durante la fase d'aula, poi, si sono innescate delle discussioni che hanno portato alla formulazione dei dieci punti ritenuti più importanti dell'Agile ("What is Agile for me") nell'ambito dell'azienda in cui si andava a lavorare.

Condivido con il lettore questi concetti, in modo che possano risultare utili anche ad altri: questo poi non significa che le cose che diremo in questa miniserie siano le più importanti in assoluto. Ma c'è una considerazione importante da fare: in questo modo, con una adeguata preparazione della fase del "pre-corso", avevo individuato già alcuni punti come i più sensibili in quell'azienda, perche' erano emersi durante una serie di discussioni precedenti al corso.

Se vi interessa approfondire questo approccio, consiglio di partire dalle letture che ho suggerito. L'uso o meno dei concetti che seguiranno nella miniserie è lasciato alla libera scelta.

Lo Shu Ha Ri nell'Agile

Qualche tempo fa passai un anno del mio tempo dilettandomi con il paracadutismo. Feci un corso in inverno per apprendere le tecniche di base e, non appena il tempo fu clemente, andammo in un piccolo aeroporto per prendere il brevetto di "lancio vincolato".

In genere in televisione si vedono paracadutisti che che si buttano da 5000 metri e "galleggiano" nell'aria: in realtà non galleggiano affatto ma viaggiano a circa 180 km/h, prima di aprire autonomamente il paracadute; questo modo di fare paracadutismo si chiama caduta libera o Accelerated Free Fall (AFF).

Con il lancio vincolato, invece, il paracadutista esce dall'aereo e si allontana dal velivolo in caduta non libera appunto perche' c'è la fune di vincolo; la fune di vincolo connessa all'aereo provvede ad aprire il paracadute. Di fatto in questo caso il paracadutista sta nel vuoto in caduta solo pochi secondi (che la prima volta sembrano minuti) e poi subito dopo il paracadute si apre, "tirato" dalla fune di vincolo. Questo è il tipo di lancio che fanno anche i militari quando vengono paracadutati in massa dietro le linee nemiche, dato che in quel caso non è presente la componente sportiva o ludica: anzi, meno tempo si rimane sospesi in aria, meno probabilità si ha di essere scoperti o colpiti. Per questo in tempo di guerra i paracadutisti si lanciano da quote molto basse, cosa che di per se è già molto pericolosa.

Dopo aver esaurito soldi e coraggio mi fermai al primo brevetto, quello con la fune di vincolo.

La metafora del paracadutismo: la chiave è nell'addestramento

Che c'entra tutto questo con l'Agile? Mi è venuto in mente perche' durante quell'inverno passato in palestra, il nostro istruttore ci preparò molto duramente tanto che, quando andammo a fare l'esame, ci fecero i complimenti per il livello di preparazione teorica ma soprattutto pratica. Cosa avevamo fatto di speciale? Nulla di fantascientifico se non leggere attentamente un libretto su alcuni principi base di meteorologia, aerodinamica e ovviamente paracadutismo; il tutto accompagnato da una lunghissima ed estenuante preparazione pratica e probabilmente fu questo che fece la differenza.

In cosa consisteva tale preparazione? Nel simulare alcuni movimenti di uscita dall'aereo e di gestione dell'emergenza in modo che diventassero per noi automatici, quasi istintivi. Per la manovra di uscita dall'aereo avevamo passato ore e ore a lanciarci da una piccola struttura in metallo su un materasso, passando dalla  posizione a sedere (si immagini di star seduti sul portellone dell'aereo con le gambe penzoloni nel vuoto) a una posizione a volo d'angelo, in pratica una specie di X fatta con braccia e gambe aperte in maniera adeguata.

La posizione doveva essere quanto più simmetrica per mantenere l'assetto stabile ed evitare così di iniziare a roteare nel vuoto mentre il paracadute si apre: non è bello fare un fagotto proprio mentre 100 mq di tela si aprono e 100 m di cordino si srotolano intorno a te. Nelle fotografie di figura 1 è illustrata la posizione a "volo d'angelo", e si vede la fune di vincolo attaccata al velivolo, che aprirà il paracadute.

 

 

Figura 1 - Immagini di lanci con il paracadute. Si noti la posizione a "X" che garantisce la stabilità, e la fune di vincolo che apre il paracadute.

 

L'altra cosa che ci fecero provare per ore è la manovra di sgancio del paracadute principale, manovra che deve essere effettuata tutte le volte che il paracadute principale non si apre bene (o si rompe qualcosa). In tal caso il paracadutista tira una leva di emergenza che si trova da un lato dell'imbracatura e che provoca lo sgancio del paracadute. In quel momento riprende la caduta libera e, dopo qualche secondo, in modo che il paracadute sganciato si sia allontanato nel vuoto, si tira la seconda leva che porta all'apertura del secondo paracadute di emergenza. È superfluo ricordare cosa possa succedere se si sbaglia la sequenza (p.e.: prima apro il secondario, poi sgancio il principale…).

Questi movimenti devono diventare meccanici e istintivi perche' poi, quando si è in quota e c'è un problema, la mente non ragiona e si perde completamente il senso dell'orientamento. Nel mio caso non ho mai avuto problemi di questo tipo, anche se mi dissero che al primo lancio non avrei capito nulla e che a malapena avrei visto l'aereo che si allontanava. Confermo, non mi ricordo nulla.

La lezione applicata alla transizione Agile

Questo piccolo racconto non ha lo scopo di farvi pensare che per diventare agili bisogna prima aver fatto sport adrenalinici, o peggio, che essere "agilisti" significhi buttarsi nel vuoto, o camminare sui carboni ardenti, pur di portare a compimento il progetto. Tutt'altro.

Riprendendo gli studi sulla complessità e il modello Cynefin [MAN] possiamo ricordare come il processo di sviluppo di un software sia una attività classificabile nel  dominio del complesso: ricordo che "complesso" è più articolato e imprevedibile del dominio "complicato". Nel Cynefin, il complesso è a un passo dal caotico, dove nulla è prevedibile e dove se ne esce solo con atti di coraggio o fortuna, o più spesso si fallisce (project abort).

Per questo una degli insegnamenti base dell'Agile è quello di percorrere un cammino che parta dall'acquisizione delle pratiche in modo meccanico, per certi versi un po' scolastico, per arrivare successivamente alla completa comprensione del significato dei vari gesti.

Solo quando si possiede la completa padronanza delle tecniche e della loro applicazione infatti, si può iniziare un processo di approfondimento dei principi teorici che stanno dietro quello che fino a quel momento si era appreso in modo piuttosto meccanicistico. Questa fase è quella che dà piena consapevolezza dei principi e del senso di quello che si sta facendo.

A questo punto si approda alla parte più profonda e importante, quella in cui si prova a vedere cosa succede se si aggiunge un pezzetto al metodo, se si prova a personalizzare la pratica. Questa fase può avvenire solo al termine di un percorso in cui si deve prima di tutto comprendere l'importanza della tecnica sviluppata e ottimizzata da altri prima di noi.

Shu Ha Ri

Questo percorso di crescita, diviso in tre fasi, si chiama Shu Ha Ri e deriva dalle arti marziali giapponesi, in particolare dall'Aikido; il concetto di Shu Ha Ri è stato portato nel mondo agile grazie al celebre Alistair Cockburn. Martin Fowler, altro nome noto ai più, in un suo blog ce la racconta in questo modo (nostra traduzione):

  • Shu: In questa fase iniziale, lo studente segue scrupolosamente gli insegnamenti di un maestro. Si concentra sul modo in cui compiere l'azione, senza preoccuparsi troppo dei principi teorici che stanno alla base. Se esistono diverse varianti sul modo in cui compiere l'azione, si concentra solo sul modo che gli viene insegnato dal suo maestro.
  • Ha: A questo punto lo studente comincia ad ampliare i suoi orizzonti. Una volta che la pratica base funziona, comincia a imparare i principi e la teoria che ne rappresentano alla base. Inoltre, comincia ad apprendere anche da maestri diversi e a integrare tali insegnamenti nella sua pratica
  • Ri: A questo punto, lo studente non impara tanto da altre persone, quanto dalla sua stessa pratica. Crea il suo personale modo di affrontare le situazioni e adatta ciò che ha appreso alle particolari circostanze in cui si trova.

Una descrizione più approfondita del processo Shu Ha Ri si trova nel libro "Agile Software Development" [ASD].

Ma l'Agile è flessibile o rigido?

La storia del corso di paracadutismo mi piace perche‘ mi permette di riagganciami anche a un altro concetto: una delle cose che si criticano di Scrum spesso è quello che viene considerato un atteggiamento troppo rigido su regole, "cerimonie", abitudini. Perche‘ dobbiamo fare tutte le mattine il daily stand-up meeting? Perche' sempre in piedi? Perche' la demo si fa sempre il venerdi? Perche' la retrospettiva il venerdì pomeriggio?

Queste sono pratiche in un qualche modo "fissate" proprio perche' il framework pone  la massima attenzione alla loro importanza. Non è obbligatorio fare il daily stand-up meeting sempre tutte le mattine, alla stessa ora, nello stesso posto. No, non lo è… Ma perche' non farlo?

Perche' non proviamo a imporci di farlo in modo che diventi una pratica naturale della nostra giornata lavorativa, come andare a prendere il caffè e fare due risate con i colleghi? Perche' non vediamo di trarne beneficio? Perche', prima di porci in opposizione con tale esercizio, non ci chiediamo come mai è ritenuto da molti così importante? Come mai una pratica tutto sommato molto semplice è in grado di dare risultati in maniera così immediata ed efficace? Forse c'è un legame nell'imparare un movimento in modo meccanico e ripetitivo sempre nello stesso modo ed eseguire una riunione sempre alla stessa ora nello stesso posto?

Conclusione

Per il momento ci fermiamo qua, ma la trattazione sui "fatti agili" che ho raccolto continua comunque nei prossimi mesi. Nella prossima puntata parleremo di Cargo Cult, di Inspect and Adapt e dell'importanza di lavorare in gruppo come un vero team, e non come un variopinto insieme di persone che condividono un ufficio.

In ogni caso, di tematiche analoghe parleremo nel frattempo sul nostro blog MokaBit [BIT] che vi invitiamo a visitare.

 

Riferimenti

[AL] Accelerated learning

http://www.acceleratedlearning.com

 

[ALBook] Dave Meier, "The Accelerated Learning Handbook", McGraw-Hill, 2000

http://goo.gl/N0V3GT

 

[TBR] Sharon L. Bowman, "Training from the Back of the Room!: 65 Ways to Step Aside and Let Them Learn", Pfeiffer, 2008

http://goo.gl/S8q2wb

 

[MAN] Giovanni Puliti, "Management dal semplice al complesso - II parte: Classificare i sistemi con Cynefin framework", MokaByte 184, maggio 2013

http://www2.mokabyte.it/cms/article.run?articleId=Y9O-LBZ-XBG-OCZ_7f000001_26089272_a0f7ef9c

 

[ASD] Alistair Cockburn, "Agile Software Development", Addison-Wesley Professional, 2001

http://amzn.to/1bu0H9k

 

[BIT] MokaBit. Il light blog di MokaByte

http://mokabit.wordpress.com

Condividi

Pubblicato nel numero
188 ottobre 2013
Giovanni Puliti lavora come consulente nel settore dell’IT da oltre 20 anni. Nel 1996, insieme ad altri collaboratori crea MokaByte, la prima rivista italiana web dedicata a Java. Da allora ha svolto attività di formazione e consulenza su tecnologie JavaEE. Autore di numerosi articoli pubblicate sia su MokaByte.it che su…
Articoli nella stessa serie
Ti potrebbe interessare anche