Cynefin Lego Game, essere Agile tornando un po’ bambini – Parte 1

Ad inizio Marzo, durante l’evento Agile for Innovation 2015, ho preso parte al workshop Cynefin Lego Game, dove, grazie all’utilizzo dei famosi mattoncini per costruzioni, Roberto Bettazzoni ha guidato i partecipanti alla comprensione dei 5 domini del framework Cynefin. Un’esperienza tutta da scoprire, in due post!

Ho avuto modo di descrivere a larghe linee il framework Cynefin in un precedente post, dando alcune indicazioni generali. Per chi è a digiuno ne suggerisco la lettura prima di procedere in questo post.

Devo dire che non avendo ancora avuto occasione di mettere in pratica il framework, il workshop proposto da Agile42 all’Agile for Innovation 2015 mi ha dato l’opportuna di sperimentarne l’applicazione.

Costruire per imparare

L’avvio è subito interessante e informale. Il nostro “capo cantiere” Roberto Bettazzoni ci accoglie chiedendoci di prendere posto in uno dei sei tavoli disponibili (numerati da 1 a 6), ognuno con sei posti a sedere. Già la prima prova di auto-organizzazione nella definizione dei team! I partecipanti, prima di prendere posto, si scrutano a vicenda per un attimo chiedendosi con chi sarebbe più interessante affrontare questa nuova esperienza.

Scelgo il tavolo 1, più che altro perché più vicino, e attendo i miei compagni di “costruzione”. Man mano che si siedono iniziamo a scambiarci i primi saluti di presentazione e ci chiediamo, per rompere il ghiaccio, cosa dovremo mai fare con i mattoncini di Lego presenti al centro del tavolo.

Roberto, dopo aver atteso qualche minuto, ci richiama all’ordine e inizia a spiegarci come funziona il workshop. L’obiettivo finale è quello di creare la Cynefin Lego City, passando per 4 diversi esercizi ognuno dei quali ricadrà all’intero di uno dei domini del framework Cynefin. Il tutto seguendo le sue istruzioni. Ci affidiamo ad un pomodoro digitale per il conteggio dei minuti di ogni esercizio (time boxing, si), a una lavagna cartacea per le indicazioni (leggi anche regole) del gioco, e altri strumenti prettamente analogici come penne e post-it.

L’esercizio dei colori e il dominio del Semplice

Il primo esercizio ci porta a capire cosa si intende quando un problema si trova nel dominio del Semplice (“Obviuos” nella nuova versione originale, anche se, in accordo con il creatore del framework David Snowden, abbiamo ottenuto di mantenere in italiano la traduzione della sua prima versione “Simple”, poiché, nella nostra lingua, “ovvio” ha una connotazione negativa, diversamente dall’inglese).

Roberto ci indica le regole da seguire: “Per ogni tavolo, dividete i Lego di fronte a voi per colore assegnandone almeno uno ad ogni partecipante e trattando i pezzi speciali come se fossero un colore a se stante. Avete 5 minuti per portare a termine il compito.”

Ci buttiamo, praticamente senza parlare, sui mattoncini e iniziamo a suddividerli, ognuno selezionando un colore. Alla prima doppia assegnazione (sia io che un mio collega avevamo scelto i verdi) parliamo per assegnare univocamente i colori. Inizialmente la suddivisione era fatta prendendo dal mucchio solo i propri pezzi, poi, pian piano, ci rendiamo conto che nessuno è obbligato a toccare solo i pezzi del proprio colore: cominciano così a smistare anche i pezzi del colore diverso da quello scelto a chi, invece, è il detentore corretto. In poco meno di due minuti abbiamo finito. E siamo molto soddisfatti! Si, ci basta poco, in effetti.

Roberto invita tutti i partecipanti a riflettere su cosa è successo. Data una regola ben definita, con pochissima comunicazione tra i membri del team, siamo riusciti a portare a termine il compito. E se dovessimo ripeterlo probabilmente faremmo le stesse cose impiegando più o meno lo stesso tempo.

Lesson Learned

Identifichiamo un problema come appartenente al dominio del Semplice quando eseguendo le stesse azioni arriviamo sempre alla medesima soluzione.
Causa e effetto sono strettamente legate tra loro. E siamo a conoscenza della soluzione.

La comunicazione tra i membri del team è quasi assente poiché non necessaria, le regole definite sono semplici e chiare.

La prima costruzione e il dominio del Complicato

Il passo successivo introduce regole più complesse. Roberto ci comunica che l’obiettivo è costruire una torre alta almeno 20 mattoncini dove ogni pezzo superiore NON può essere più grande di quello inferiore (insomma crescendo in altezza non può aumentare in larghezza). Inoltre, la torre deve avere un pattern di colori riconoscibile e ogni persona del team può toccare solo i mattoncini del colore assegnatogli nell’esercizio precedente. In questo caso abbiamo 10 minuti di tempo per completare il compito.

Come nel primo esercizio iniziamo subito a costruire. Nel mio tavolo 3 compagni si lanciano in una serie di ipotesi del tipo “costruiamo una grande base per poi farci stare il resto della piramide!”, altri due provano a confutare le loro ipotesi. Io mi tengo un attimo da parte, incuriosito da come le interazioni nel gruppo cambiano con il passare dei secondi. Ad un certo punto la soluzione iniziale proposta si rivela troppo complessa per raggiungere l’obiettivo ed è necessario provare un’altra strada. Questa volta prendo parte anche io e addiveniamo ad una soluzione molto semplice, che rispetta in pieno le regole, costruiamo una torre esattamente di 20 mattoncini, uno sopra l’altro alternando un mattoncino verde ad uno blu e prestando attenzione che ogni mattoncino che aggiungiamo in altezza sia uguale o più piccolo del precedente, ma mai più grande.

Lesson Learned

Con questo esercizio abbiamo imparato che nel dominio del Complicato ricadono quei problemi la soluzione non è immediatamente nota, ma è comunque possibile trovarla applicando un minimo di analisi del problema.
Quindi il rapporto tra ed effetto è indiretto.
E la comunicazione tra i membri del team è attiva.