Author Archives: Felice Pescatore

Continuous Delivery e Continuous Deployment, proviamo a fare chiarezza

Termini come Continuous IntegrationContinuous DeliveryContinuous DeploymentDevOps, ecc, sono orami entrati nel gergo comune del mondo dello sviluppo software, complice il cambio di paradigma che inesorabilmente ha interessato l’Application Lifecycle Management (ALM) negli ultimi anni.

Risalendo alle origini comuni che ritroviamo in Agile, e in Lean prima per certi aspetti, la Continuous Delivery è esplicitamente descritta dal primo principio Agile:

La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in maniera continua

La Continuous Deliverynon è esclusivamente un insieme di strumenti e pratiche, ma enfatizza la capacità delle Personedi instaurare una Relazione Sociale(Cultura) e sfruttare Toole Processi per generare Valore continuo per l’utente finale, in funzione di quattro principi fondamentali:

  • Il software è sempre rilasciabile, il che significa che la priorità è mantenere il software distribuibile piuttosto che aggiungere nuove funzionalità. Per fare ciò, si prediligono modifiche atomiche (piccole), e meno rischiose, rilasciate continuamente piuttosto che

tutte in una volta

  • Le attività di gestione dei requisiti (backlog), la loro formalizzazione ed il loro aggiornamento sono parte integrante del ciclo di valore
  • Un (veloce) feedback loop delle fasi di compilazionetestdeployconsente a tutti gli attori coinvolti di stabilire se è possibile approvare un rilascio immediato in qualsiasi ambiente
  • L‘automazione del processo di buildtestdeployè fondamentale per rendere il processo ripetibile e per supportare una maggiore frequenza del tutto

La Continuous Deliveryimpone letteralmente di mantenere il software sempre in uno stato rilasciabile: nulla può andare in produzione senza aver prima superato i test e le validazioni previste! Tale stato di rilasciabilità consente di spostare con confidenza la build in qualsiasi ambiente in qualsiasi momento. 

Tutto ciò implica l’adozione di pratiche Agili che aumentano la frequenza di build, test e deploy, grazie al supportato di strumenti che ne automatizzano le parti ripetitive.

La Continuous Deploymentsi occupa di automatizzare lo “spostamento” della build su un qualsiasi ambiente, azione supportata da strumenti di configurazione automatica e test di varia natura. Per efficientare il tutto si ragiona intermini di Deployment Pipeline, andando ad automatizzare il più possibile il flusso che porta dalla Continuous Integration(in seguito al check-in del codice) fino al rilascio su diversi ambienti previsti, ognuno con specifici test. 

La Continuous Deployment è quindi un assett tecnico/tecnologico a supporto della Continuous Delivery, rendendo le attività di compilazione/deploy/test, affidabilielastiche, e capaci di adattarsi automaticamentealle modifiche al codice, agli aggiornamenti dei repository dati e alle configurazioni del server. In pratica avremo:

  • Continuous Build, supportato da script e tool per la Build Automation
  • Continuous Deploy, supportata da script e tool per l’Application Release Automation
  • Continuous Testing, supportato da script e tool per Testing Automation e Virtualization

Una delle rappresentazioni classiche che crea confusione è quella della figura seguente:

cd ci old

In cui si minimizza la differenza tra Continuous Delivery e Continuous Deployment nella sola automazione dell’intera catena, rappresentando addirittura la Continuous Deployment come uno step successivo alla Continuous Delivery. Un po’ poco per giustificare l’esistenza di due terminologie che creano tanta confusione e che differiscono “solo” in un passaggio automatizzato in più, senza, tra l’altro, allargare lo scopedella rappresentazione anche alle fasi di planning e coding. Se si ritiene di voler automatizzare anche il deploy in produzione resta una opportunità e una scelta di business, che può variare anche nel tempo, ma la Delivery ha sempre l’aspetto intrinseco di “guardare all’utente”.

Una possibile rappresentazione più significativa, che abbraccia quanto ci siamo detti, nobilitando la Continuous Delivery è la seguente:

 

cd ci

In cui è toccato tutto il ciclo ALM e la Delivery è effettivamente letta in chiave Agile/Lean.

Stay tuned J

La dissonanza dogmatica della distanza

Molte pratiche agili, come lo stesso Manifesto, sono nate un ventennio fa(quasi si rabbrividisce nel dirlo). Inutile sottolineare come il contesto relativo in ambito sviluppo, e il significato stesso di “software”, fosse decisamente differente da quello odierno.

Vero è che molti dei problemi organizzativi/di svilupposono nella sostanza molto simili, tant’è che non finiamo mai di ripetere: Persone e Interazioni più che Processi e Tool [primo Valore del Manifesto] ma questo non deve creare delle barriere ideologiche, soprattutto in alcuni aspetti che ormai trovano difficile riscontro con la realtà.

In particolare, mi riferisco alla co-localizzazione dei membri di un team (o di più team), cosa oggi sempre meno frequente e che pone una serie di riflessioni su come “aggiustare” alcune delle pratiche fondamentali del mondo Agile, prima tra tutte la Retrospettiva/Reflection, un dei pilastri portanti dell’agilità stessa.

Non si può di certo immaginare di obbligare tutti i membri del team (laddove chiaramente non lo siano di base) ad incontrarsi di persona, cosa che potrebbe essere sconveniente sotto diversi punti di vista: tempo utile, costi, concentrazione, ecc.

D’altro canto, dobbiamo assolutamente evitare, con tutte le nostre forze, che ciò si trasformi in una scusa per non farla, visto che da remoto le persone si “addormentano” o non riescono a seguire.

Fortunatamente negli anni sono stati sviluppati una serie di tool molto interessanti che provano a mantenere viva la natura stessa della retrospettiva, pur consentendo di abbattere le “nuove” barriere che si presentano nel mondo odierno dello sviluppo. Tra questi il mio preferito, che vi consiglio di provare, è Retrium (retrium.com)

retrium 1

Retrium

Retrium è espressamente realizzato per organizzare e gestire retrospettive con team misti composti da persone in presenza e remoto (in realtà si può usare anche con persone tutte in presenza, l’importante è non porlo davanti all’obiettivo dell’evento!).

Come si può vedere dall’immagine seguente

retrium 2

Sticky Notes e Team Radars

è possibile sfruttare una serie di “template” (definiti Sticky Notes in Columns) che in pratica pre-settano la retrospettiva con alcune delle attività note sicuramente a tutti gli agilisti. Una volta scelta l’attività, il tool fa un breve recap della stessa e permette di gestire i tempi, i feedbacke altri aspetti tipici di una retrospettiva.

retrium 3

Retrium, Mad/Sad/Glad

Ho trovato molto interessante anche la possibilità di creare i Team Radar ( pensate all’High Performance Treeo al THC di Spotify) che consentono di auto-valutare la maturità dei team e ragionare sui punti di improvement.

retrium 4

Chiaramente Retrium permette di registrare quanto fatto in modo da creare uno storico e avere così una visione temporaledei miglioramenti, dei problemi risolti e di quelli latenti che ancora sono in essere.

 

Chiudo sottolineando che Retrium, come qualunque tool, deve essere di supporto e facilitazione, e non deve mai mettere in discussione il primo Valore, né portare a delle disfunzioni regressive in cui il processo va ad imbrigliare l’agilità stessa dell’organizzazione. Ricordatevi sempre e comunque di fare in modo cadenzato almeno una retro tutti in presenza: ne vale 100 da remoto!

 

Stay tuned J

La rotta comunicativa per l’Isola che non c’è

Come Agilisti siamo sempre presi dalla volontà di ridurre il più possibile le barriere comunicative interne alla nostra organizzazione, favorendo il più possibile una condivisione fluente delle informazioni, in modo che esse diventino conoscenza, ovvero specializzate rispetto al contesto. Spesso ci soffermiamo sulle azioni cross-team, oppure sull’abbattimento dei Silosche sono visti come uno dei fattori primari di insuccesso ed efficacia operativa. 

Il rischio però è quello di sostituire una “segmentazione” con un’altra (ad esempio un team Agile che lavora in modo isolato in una sorta di sand-box è a sua volta un elemento disfunzionale), senza tener conto dei possibili slicingche possono verificarsi.

islands

Ognuno di essi da vita ad una ottimizzazione locale che ingabbia la comunicazione solo nelle aree relative, tenendo fuori tutto il resto e delegano il trasferimento di know-how a modelli e documentazione formale.

Lo scopo di una comunicazione agile è quello di trasformare l’intera organizzazione in un’Isola della Conoscenza, in cui i diversi modelli abilitanti creano un flow continuo sostenibile di informazioni a disposizione di tutti.

knwoledge island

In quest’ottica, un’azienda Agile riconosce l’importanza di diversi aspetti organizzativi ed operativi e mette in campo approcci, strumenti e soprattutto un Mindset che consante di trovare il giusto bilanciamento delle diverse esigenze al fine di ottemperare al primo valore:

“Gli individui e le interazioni più che i processi e gli strumenti “

Bisogna sempre essere attenti a non considerare lo strumento (Kanban, Trello, Jira, Azure DevOps, ecc) come “LA” soluzione per la comunicazione: rischiamo solo di trasformarlo nel depositario del processo e di fare le cose in modo automatico, pretendendo che gli altri estraggano informazioni dallo stato dei suoi elementi.

Se questo accade, è arrivata l’ora di fare un “back-to-basic” perché abbiamo perso la bussola della nostra agilità, allontanandoci sempre più dall’obiettivo principe:

La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in maniera continua.”

 

Abbiamo spostato l’attenzione sulla bravura nel “seguire i processi” … alias… siamo diventati dei burocrati!

 

 

Stray tuned J

La negazione dell’evidenza iniziale

Esiste una sorta di mito, di leggenda, che si annida tra i corridoi degli Agilisti: lo Sprint 0!

Come molti di voi sapranno, lo Sprint 0 (nella Scrum Guide) non esiste, ma è spesso un modo per giustificare la necessità di avere una fase/momento pre-Sprint 1 in cui si valutano gli aspetti cardini di una nuova iniziativa e si dà il benestare definitivo alla stessa.

L’utilizzo di “Sprint 0” è un tentativo di legare a Scrum una serie di attività che SchwaberSutherlandnon hanno codificato direttamente nel loro framework, e la sua istituzione, più o meno formale, è un retaggio delle precedenti wavedell’Agile che tentavano di conformarsi a tutti i costi ad un modello, trovano dei workaround adattativi tutt’altro che chiari e trasparenti, in completa antitesi a quanto proposto dall’agile stessa che parla di trasparenza continuo adattamento.

Generalmente, io preferisco esplicitare lo Sprint 0, anche noto come Lift-off/Kick-off/ecc, identificandolo come Inception della iniziativa, così come suggerito da Disciplined Agile. La cosa fondamentale è che in questa fase (si, ho detto fase J) ci si concentri su tutti quegli aspetti fondamentali e irrinunciabili per “partire con il piede giusto”.

dad inception goals 2019

DAD Inception Goals

Per esperienza diretta, così anche come raccontato da AmblerLines(ma non solo, la letteratura è piena di casi concreti), gli 8 obiettivi riportarti in figura sono fondamentali: bisogna sempre prenderli in considerazione durante l’Inception, anche se, ovviamente, una parte di essi può essere derogata o assorbita perché, di fatto, già risolto. Si pensi ad esempio a “Form Team”: se la nostra organizzazione è basata su team stabili, che magari lavorano insieme da tempo, la questione si può spostare sull’individuare il team più adatto e/o disponibile, piuttosto che sul crearne uno nuovo e preparare il relativo ambiente.

Personalmente, quando affronto una fase di Inception, specialmente se all’inizio dove generalmente è presente solo un’idea di massima dell’iniziativa, utilizzo un mio framework attuativo composta da 4 step(Inception in Action) con cui supporto la room a supporto del progetto focalizzandoci su:

  • Indentificare lo Scope Iniziale, in modo da mettere a fuoco il cuore stesso della nuova iniziativa
  • Sviluppare una Visione Comune, per avere una condivisione dei goal, frutto di un’approfondita discussione e di un confronto trasparente, e produrre un primo draft del Product Backlog
  • Identificare i Rischi, azione troppo spesso sottovalutata in Agile
  • Sviluppo di un Piano iniziale di Release, fondamentale per inquadrare le attività nel contesto del portfolio aziendale

inception in action 1

Inception in Action

Per ognuno degli step è possibile usare una serie di strumenti e tool a supporto, che aiutano la concentrazione dei presenti e supportano la sintesi dei risultati.

inception in action 2

Inception in Action

A questo punto, non vi resta che sperimentare e costruire il vostro framework per una Inception trasparente e di valore.

 

Stay tuned J

La polarizzazione dei feedback paganti

Siamo tutti concordi che uno degli elementi portanti del mondo Agile sia la capacità di ottenere e fornire rapidamente feedbackinerenti le azioni in essere, abilitando così tutti gli attori coinvolti ad un rapido riallineamento basato sulle evidenze.

Ma se i feedback non arrivano, come possiamo “spingere” le persone, i team o l’azienda stessa a condividerli, polarizzandone l’essenza in azioni di miglioramento? Come possiamo, in qualità di Coach o facilitatori, ricomporre il puzzle e ottenere valore dalle singole indicazioni?

Tra i diversi modelli di azione, uno dei più semplici e diretto è il COIN Model, acronimo che sta per:

  • – The Context(What, Where, When, Whom)
  • O– What I Observedwas…
  • I– The Impactof that was…
  • N– How do you want to handle that differently NextTime? (or this is how I want you to handle it Next Time)

coinmodel

L’idea di base è quella di costruire una domanda sinteticache l’osservatore(non per forza il Coach) può porre rapidamente ad una persona per farla riflettere su un fatto o su un episodio specifico.

Facciamo qualche esempio:

  • “Mario, ieri serie arrivato per l’ennesima volta in ritardo al Daily Meeting. L’impatto è stato quello di non consentire un proficuo allineamento del team e generare un successivo ping-pong di domande. Come pensi di gestire questa situazione la prossima volta?”
  • “Andrea, Marina è venuta a dirmi che le hai detto di ritenerla all’altezza del suo compito e che non sa fare il proprio lavoro. L’impatto è stato quello di dover spendere con lei più di un ora per rasserenarla. Come pensi di evitare questa situazione la prossima volta?”

Il cuore dell’approccio è quello di focalizzare sui comportamenti (behaviours) e andare puntualmente nello specifico, evitando di essere superficiali o troppo generalisti nelle domante e nelle riflessioni.

Il feedback è un diritto/dovere: è doveroso far sapere ai colleghi la propria opinione, così come è un diritto conoscere il parere degli altri. Compito di un Coach è quello di rendere questa situazione trasparentealimentarnecostantemente la relativa fiammella, tenendo sempre presenti alcune indicazioni basilari:

  • Chiedere prima il permesso,un semplice “posso darti un piccolo feedback?”preparerà mentalmente il destinatario al messaggio che sta arrivando
  • Essere tempestivo, il feedback deve essere temporalmente vicino all’evento, altrimenti si tratta solo di un “risentimento” che può addirittura avere l’effetto contrario
  • Trovare un luogo privato, per evitare di dare feedback in pubblico e mettere a disagio il destinatario
  • Essere calmi, ma urlare o alzare la voce: se si perde la calma si fallisce in partenza
  • Essere interessati, chi da il feedback deve darlo perché si sente coinvolto e tiene al destinatario. È fondamentale farlo capire
  • Essere tranquilli e silenziosi, aspettando pazientemente, e con attenzione, la risposta al feedback stesso, in modo da poter dare suggerimenti migliorativi adeguati
  • Feedback diretto (faccia a faccia), un feedback va dato sempre il modo diretto, evitando di utilizzare strumenti tecnologici o “ambasciatori” che aumentano la distanza tra le parti

Lo ripetiamo da sempre: i feedback sono fondamentali! Se qualcuno si preoccupa di darveli, con onestà e trasparenza, vuol dire che si sta preoccupando per voi e dovete essergli grato per la sua attenzione.

Stay tuned J

Agile Montessori, ampliare l’ambiente

Abbiamo imparato con il tempo a conoscere, e quasi tollerare, l’eterno dilemma e dibattito della “terza wave” dell’Agilità: Scaling or not Scaling?

Ci sono discussioni aperte in questo ambito che, probabilmente, non avranno mai fine, a partire da quella che deriva dalla più classica delle domande: “Qual è il miglior framework di Scaling?” Domanda che, dopo anni di sperimentazione sul campo, mi permetto di dire essere essenzialmente sbagliatanella formulazione stessa.

agilemontessori scaling

Scaling Frameworks

Non si percorre un percorso di trasformazione Agile affidandosi ad un framework o ad una metodologia in modo dogmatico, imbrigliando così la nostra capacità di reagire alle evidenze ed imparare da esse nel contesto specifico. Giusto per provare a chiarire in modo semplice: un framework dà delle linee guida lasciando ampio spazio di manovra alla contestualizzazione, una metodologia cerca di descrivere passo passo le azioni da compiere per ottenere un risultato. Calato nel mondo Agile possiamo fare due esempi molto esplicativi: Scrum è un frameworkeXtreme Programming è una metodologia (qualcuno potrebbe storcere il naso, ma questo è quanto esplicitamente evidenziato in “Extreme Programming Explained”).

Ora, qual è il concetto base di quando parliamo di Scaling? Al centro c’è sicuramente l’ampiamento dell’ambiente di riferimento, amplificando direttamente i problemi tipici che negli approcci base (come ad esempio Scrum) sono concentrati sul singolo team.

Cosa significa comunicare tra più team? Cosa significa condividere la realizzazione di un prodotto tra più team? Sono solo esempi di domande a cui è necessario rispondere.

Ricollegandoci al Metodo Montessori, la dualità che risulta evidente è l’estensione degli interessi che ogni bambino concretizza nel secondo piano di sviluppo (che va dai 6 ai 12 anni). In tale piano, in cui il bambino si avvia verso l’età adolescenziale, si sviluppano tre necessità essenziali:

  • Ampliamento, ovvero confrontarsi con uno spazio di riferimento più ampio rispetto a quello familiare che, in precedenza, era al centro della propria esistenza
  • Astrazione, grazie alla quale il bambino comincia a fattorizzare le esperienze e a sviluppare “pattern mentali” che consentono di riportare nuove esperienze a quelle già vissute, riducendo il rumore delle “piccole differenze”
  • Etica, si sviluppano i concetti di “giusto” e “sbagliato” in relazione alla cultura e all’ambiento specifico

agilemontessori astrazione ampliamento sensomorale

Ampliamento, Astrazione, Etica

La condizione essenziale per permettere questa crescita è quella della libertà d’azione in un ambiente che però sia predisposto per svolgere la propria attività con intelligenza.

E qui torniamo alla discussione iniziale con cui abbiamo aperto: un framework di Scaling può sicuramente essere utile, astraendo diversi aspetti specifici e suggerendoci un modo di procedere che possa essere adattato al nostro contesto. Lo stesso deve però lasciare ampio spazio alla personalizzazione e alla possibilità di valutare rapidamente i risultati, in modo da essere “il proprio framework” e non “quello di…”.

Scoprire la propria Way of Working, è questo il senso del discorso, perché

tutti i framework di Scaling (o le metodologie) sono utili, ma tendenzialmente sono tutti sbagliati, essendo ogni contesto unico!

Lo Scaling si focalizza sull’Ampliamento dello spazio di riferimento, però questo non vuol dire per forza che le azioni devono complicarsi, potendosi estendere in relazione ai nuovi fattori (è un po’ il concetto di De-Scaling spesso invocato dai fautori di LeSS, ad esempio). Per fare questo, il concetto di Astrazione, così come rappresentato in pieno in Disciplined Agile, aiuta a tenere il punto nei vari ambiti, pur consentendo di scegliere la soluzione contestuale opportuna e rivederla rapidamente se non produce i risultati sperati. Il percorso è accompagnato dallo sviluppo di un’Etica che permette di costruire la propria Agilità, individuando gli strumenti, le azioni e le relazioni che dimostrano concretamente di funzionare. Si pensi ad esempio alla strutturazione multi-team di SAFe con un unico Product Backlog (e specifici Team Backlog), spesso presa a modello anche da altri framework di Scaling anche se con nomi diversi.

Ecco, questo è il punto focale: avere una Vision definita che viene rafforzata da quanto accade concretamente sul campo, dimostrandosi pronti a sperimentare in chiave Validate Learning con Actionable Metrics.

Stay tuned J

Agile Montessori, attività sostenibili

Tutti siamo stati studenti e tutti sappiamo quanto sia frustrante, una volta tornati a casa, non poter godere di quel senso di libertà fugacemente assaporato, perché ci si deve mettere subito sui libri per i fantomatici compiti a casa!

agilemontessori homework

È una situazione classica in cui si prova a tenere impegnata la persona (studente) per tutta la giornata, con la convinzione che il suo scopo naturale sia quello di essere il più produttivo possibile, indipendentemente da tutto.

Le scuole Montessoriadottano un principio diametralmente opposto: “no compiti a casa!”. 

Ai più potrà sembrare una cosa strana, poco comune, ma l’idea di fondo è che sono i bambini stessi, spontaneamente, anche se lontani da scuola, a volersi occupare di ciò che li interessa. In pratica, il processo di apprendimento si estende nel proprio ambiente naturale, dove gli spazi e i materiali sono ancora più personali e plasmati sull’IO del bambino. Questo accade però, solo se il bambino ha voglia di farlo, altrimenti è libero di utilizzare il proprio tempo per altro, per le attività che ritiene meritevoli della sua attenzione.

Di fatto, non viene esercitata alcuna costrizione o alcun aspetto obbligatorio, cosa che contraddistingue lo spirito del piacere di imparare intrinseco nell’approccio Montessoriano, mettendo al centro il bambino invece di renderlo schiavo di un modello di istruzione estremamente prescrittivo e generalista.

Cosa succede se proviamo a “forzare” tutto questo? Se costringiamo gli studenti a fare ore di compiti a casa? L’impegno profuso diminuisce costantemente, fino ad avere un picco di discesa definitivo che rende le attività svolte molto superficiali. Inoltre, lo stesso non riuscirà a “ricaricarsi” e questo si ripercuoterà inevitabilmente il giorno dopo a scuola, creando un circolo vizioso che trascinerà l’apprendimento nella direzione opposta rispetto alle premesse che lo ha generato.

Se ci catapultiamo nel mondo Agile, il riferimento che immediatamente salta all’occhio è l’ottavo Principio:

I processi agili promuovono uno sviluppo sostenibile.
Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere indefinitamente un ritmo costante.

In pratica, dobbiamo essere in grado di identificare il nostro ritmo per poterci esprimere al massimo nelle attività che affrontiamo. Se, al contrario, proviamo a “spremere” continuamente tutte le nostre energie, ci ritroveremo ben presto ad osservare un inesorabile calo di produttività che avrà un effetto devastante su noi stessi, prim’ancora che sul nostro lavoro.

agilemontessori overtime productivity

Productivity and Overtime

Come ripetiamo sempre, il cuore dell’Agilità è nelle evidenze e nei feedback, per cui i team provano continuamente a tarare il proprio ritmo, anche utilizzando strumenti o tecniche di cui spesso si dimentica la reale essenza. Si pensi al WIP limit (Work in Progress limit) di Kanban: il suo scopo nobile è proprio quello di trovare il ritmo di lavoro sostenibile dal team. Peccato, però, che spesso venga utilizzato per “valutare” il team dall’esterno, comparando, ad intervalli di tempo regolari, il numero di task attivi parallelamente: più task, più si è bravi. Niente di più errato e forviante può essere fatto… anzi si.. fare la stessa comparazione tra due team diversi!

Stesso discorso, spesso ancora più marcato, per la Velocity: “ma il Red Team ha una velocity più bassa del Blue Team, quindi sono più bravi!” nulla di più insensato! La velocity è del team per il team, da usare solo per Improvement e non per comparazioni relative. Se il team volesse fare il “furbetto”, basterebbe aumentare le stime e la situazione si ribalterebbe.

agilemontessori velocity wrong

La realtà è che i “veri” team Agili guardano alla produttività, o meglio ancora al Valore generato, di qualità e sostenibile, altrimenti si rischia di spezzare quella “magia” che permette ad un team di essere il cuore pulsante di una organizzazione.

Stay tuned J

Agile Montessori, il ruolo centrale della Torre Rosa

A game is a series of interesting choices” [Sid Meier, game designer]

Sicuramente molti di voi avranno partecipato a workshop/meet-up, o sessioni di formazione, in cui vengono utilizzati i cosiddetti serious game, ovvero ambientazioni che utilizzano le dinamiche di un gioco per trasferire implicitamente un messaggio o far provare in condizioni “senza stress” un processo o una specifica pratica.

Ebbene, il gioco è un elemento abilitante della crescita di ogni bambino, inquadrando negli specifici periodi sensitivi diverse attività che sono idonee a stimolarne i sensi e l’interesse relativo. I bambini hanno bisogno di “toccare” le cose, cosa che la scienziata osserva fin dagli inizi del suo percorso quando visita un ricovero per bambini ritenuti “diversi” e gli viene fatto notare come questi raccolgano le briciole per terra e le mangino abitualmente.

Montessori non associa il comportamento a disturbi della psiche, ma osservando l’ambiente privo di oggetti da toccare e sperimentare, ha un suo ha-ha moment: i bambini non raccolgono le briciole per mangiarli (quello è un effetto collaterale se si vuole), ma le raccolgono proprio per la necessità di stimolare il senso del tatto e le altre conquiste affini ai periodi sensitivi dell’esplorazione e dello studio dei piccoli oggetti (si veda il post precedente).

Montessori, nel suo lungo percorso di ricerca e applicazione, evidenzia come, per la riuscita del gioco, sia fondamentale utilizzare materiali specificamente pensati e progettati in modo da consentire di imparare dagli errori e raggiungere gli obiettivi attraverso esperienze tattili, nonché attraverso l’attivazione annessa degli altri sensi.

Infatti, i diversi materiali consento il “controllo dell’errore”, permettendo al bambino di autocorreggersi per scoprire, ricorsivamente, il modo giusto (unico) di farli funzionare correttamente.

Nascono così, ad esempio, il “Cesto dei Tesori”, da cui i bambini possono estrarre oggetti di varia natura/forma/colore per lasciare che il bimbo li scopra con le manine e la bocca, e soluzioni più articolate come la Torre Rosa, formata da 10 cubi a dimensione decrescente che bisogna mettere uno sopra all’altro, nella giusta sequenza, per creare “la torre”.

montessori cesto dei tesori

Cesto dei Tesori

Calandoci nel nostro amato mondo Agile, è innegabile riscontrare quanto meno un’affinità con i succitati serious game e una relativa ricerca nei materiali che ne supportano lo svolgimento.

Uno degli esempi più classici, ad esempio, è l’utilizzo dei Lego nei modi più fantasiosi e diversi (non solo nell’ambito del Lego Serious Play), capaci di entusiasmare persone di ogni età e ogni ruolo, felici di rimettersi in gioco nella costruzione di elementi fantasiosi, ispirati ai film, a oggetti reali e così via.

La progettazione di un serious game e la scelta dei materiali annessi è comunque un processo articolato che passa attraverso 3 aspetti fondamentali:

  • Meccanica: regole e concetti che specificano formalmente il gioco e ne definiscono le possibili azioni 
  • Dinamica: il comportamento in fase di esecuzione del gioco che ne delinea le possibili interazioni che il giocatore può sviluppare
  • Estetica: le risposte emotive sviluppate con l’attivazione delle dinamiche gioco 

Tutto questo consente di invertire il modello tradizionale di apprendimento: da frontale/trasmissivo interattivo, in cui i partecipanti diventano il vero cuore dell’azione e gli insegnati si trasformano in mentori che supportano, evidenziano e permettono di entrare nei dettagli degli aspetti emersi. 

Se quindi state approcciando un’azione di coaching (o supporto Agile che si voglia), non potete prescindere dall’avere nel vostro “cesto dei tesori” una nutrita scelta di giochi seri, più o meno articolati, che vi consentono di interagire direttamente con le Persone (i Team) e affrontare in modo “serio” specifiche tematiche.

Nel mio percorso, ultimamente, mi sto cimentando con la realizzazione di serious game che si ispirano a fatti cruciali della storia informatica. Ad ora ho nel mio “cesto”:Pirates vs Nay… an Apple story (per evidenziare il valore dei team cross funzionali) e Follow your Sensation… a Microsoft story (per sperimentare l’essenza del Business Model Canvas e strumenti affini).

montessori navy pirates

montessori follow

Stay tuned J

Agile Montessori, i Periodi Sensitivi

Nel precedente post abbiamo parlato di Concretezza, evidenziando in chiusura come sia fondamentale individuare il tempo giusto per le cose giuste al momento giusto, per evitare di “soffocare” un team o una organizzazione impegnata in un percorso di trasformazione Agile.

Ebbene, questo aspetto è uno degli elementi cardini del Metodo Montessori, definiti e descritti dalla scienziata attraverso i “Periodi Sensitivi” che consentono [al bambino] di apprendere in modo naturale, inconscio, essendo totalmente assorbito da una particolare attività che porta quasi ad ignorare del tutto gli altri stimoli ambientali. 

agile montessori periodi sensitivi

«Si tratta di sensibilità̀ speciali, che si trovano negli esseri in via di evoluzione, cioè negli stati infantili”

Il manifestarsi dei Periodi Sensitivi è caratterizzato dal ripetere più e più volte azioni che all’apparenza sembrano inutili o basilari, ma che nel concreto portano al manifestarsi, quasi per incanto, di una specifica abilità. La cosa fondamentale è che tali periodi sono determinanti per acquisire specifiche competenze e per progredire nello sviluppo individuale: se si perde l’attimo non c’è più modo di recuperarlo! Per cui, è necessario rispettare le specifiche tempistiche (leggermente diverse da bambino a bambino) senza anticiparle o posticiparle.

Montessori individua una serie di Periodi Sensitivi (anche estesi successivamente ai suoi studi):

  • l’attaccamento (0, 1 anno), che consente al bambino di instaurare da subito un legame forte e duraturo, in primis con la madre;
  • l’ordine (0 mesi, 6 anni), che concretizza l’esigenza di creare un rapporto con e fra gli oggetti, “parlando” all’ambiente;
  • il movimento (6 mesi – 6 anni), che consente di allargare l’ambiente di riferimento ed è alla base dell’intelligenza stessa, così come raccontato da Leonardo Previ in Zainocrazia;
  • il linguaggio (0 – 7 anni), in cui il bambino impara a comunicare progressivamente, prima con i gesti e poi con la voce;
  • gli aspetti sociali (0 mesi, 6 anni), in cui si sviluppa un profondo interesse per i rapporti interpersonali, per la comprensione dei diritti reciproci e per le attività cooperative;
  • l’esplorazione sensoriale (0 – 6 anni), ogni esperienza è conquistate tramite i sensi e si basa sullo sviluppo di quest’ultimi;
  • l’osservazione dei grandi (fino ai 18 mesi) e piccoli oggetti (fino a 7 anni), man mano che la coordinazione oculo-manuale diventa più̀ accurata, il bambino comincia ad apprezzare i piccoli oggetti e i dettagli.

L’elenco non rappresenta di base una sequenza e non contempla l’univocità, nel senso che se ne possono attivare diversi in contemporanea.

Se ci spostiamo nel mondo Agile, scopriamo che ricorriamo abbondantemente a specifici Periodi Sensitivi nel percorso di trasformazione, spesso rappresentati attraverso la progressione SHU-HA-RI-KOKORO.

shu ha ri kokoro

In pratica:

  • Quando siamo in “Shu”, l’attitudine è quella di “copiare” quanto il Coach sta illustrando, sviluppando un attaccamento e un linguaggio plasmato su quanto presentato;
  • Quando siamo in “Ha”, cominciamo ad esplorare possibili opzioni e soluzioni, provando a cercare un ordine in essi e ad osservare i dettagli per capire cosa è meglio per il proprio contesto, anche in funzione al rafforzamento gli aspetti sociali;
  • Quando siamo in “Ri”, siamo pronti a definire il nostro ordine delle cose, sviluppando le nostre specificità e il nostro percorso, andando sempre più nel dettaglio e rompendo gli schemi quando necessario;
  • Nella fase di “Kokoro”, sviluppiamo una estrema osservazione dei piccoli oggetti, ovvero proviamo in qualche modo a destrutturare la complessità raggiunta, ricercandone gli elementi essenziali che caratterizzano il percorso compiuto e che diventeranno, a loro volta, gli elementi fondanti della nuova fase di “Shu” che sta per iniziare (ricordatevi: non c’è mai fine ad una vera trasformazione Agile).

Se uno di questi momenti viene saltato, o se si spinge troppo in fretta a passare al successivo, si mette fortemente a rischio la solidità dei risultati raggiunti, con la conseguenza che ogni piccolo ostacolo può far cadere in un limbo regressivo da cui non si riesce più ad uscire.

Stay tuned J

Agile Montessori, la ricerca della Concretezza al tempo giusto

Sin da piccoli siamo portati ad “assaporare” l’ambiente che ci circonda, imparando progressivamente a sfruttare i nostri sensi a partire dal tatto che, secondo le conoscenze attuali, è il primo senso a svilupparsi già nel grembo materno.

Questo percorso connota una necessità ben precisa del bambino: dare concretezza al “suo mondo”, a quanto lo circonda, aiutandolo ad entrare nella sfera dell’adulto. In tal modo comincia a prende corpo la connotazione unica del proprio “Io”, così come evidenziato dagli studi di neuroscienza grazie ai lavori dei suoi massimi esperti come Alberto Oliverio (rif. “Il cervello che impara”):

La struttura del cervello non dipende solo dalla generica, ma anche dalle esperienze che creano nuove connessioni.

il cervello che impara

In pratica, nasciamo con un nostro bagaglio genetico specifico che verrà plasmato grazie a quanto scopriamo a partire dai primissimi mesi di vita: ogni esperienza struttura uno o più percorsi neurali e quindi forgia molto del nostro futuro “io”.

Passando al dualismo che stiamo provando a strutturare con il mondo Agile, un percorso simile è quello che si verifica quando in una organizzazione si comincia operativamente a pensare, e a riflettere, ad un cambiamento organizzativo che impone una svolta Culturale.
Le opzioni iniziali sono tante, così come gli intrecci e le possibili declinazioni che si possono ottenere: l’importante è cercare di dare fin da subito concretezza a quanto si sta approcciando per la prima volta, andando a ricamare il cambiamento sul contesto esistente, ligi nello scardinare quanto necessario, ma senza avere un approccio dogmatico puramente teorico.

Ecco, quindi, che si predilige l’utilizzo di workshop piuttosto che di lezioni frontali sin dai primi momenti: l’idea è quella di far toccare subito con mano quanto si sta descrivendo, con pillole di approfondimento dei principi/concetti, ma coinvolgendo subito i diretti destinatari. In tal modo si comincia ad incentivare la riflessione e la comparazione con la realtà esistente, spingendo a discutere dei dubbi e a fornire feedback che consentono al coach, ma non solo, di essere già incisivo in modo concreto, senza perdersi in concetti troppo astratti.

Si concretizza così la certezza di stimolare la Mente Assorbente, ovvero la capacità [di un bambino] di imparare in modo inconsciosperimentandosbagliando riprovando. Vero, il bambino ha questa straordinaria capacità perché sta modellando le proprie sinapsi, ma anche negli adulti è riscontrabile l’attitudine a sfruttare l’esperienza, e soprattutto gli errori, per diminuire i gradi di libertà e arrivare progressivamente alla scelta giusta di contesto (choice your WoW!, your Way of Working!)

La nostra mente “assorbe” e filtra le informazioni che ci bombardano quotidianamente, ma fissa in modo deciso ciò di cui siamo protagonisti, consentendoci di tracciare nuove direzioni in funzione dei cambiamenti che ci investono e che investono la nostra organizzazione.

Ogni forzatura, ogni tentativo di imprimere una scelta che non sia posta al momento giusto è un’occasione persa, un mattone che va ad alzare il muro metaforico della resistenza al cambiamento, invece di trasformarsi in un volano per un ulteriore miglioramento complessivo.

E’, ad esempio, il caso dell’introduzione troppo anticipata di tematiche come Quality & Testing Strategy Risk Management in un percorso di trasformazione agile che muove i primi passi e che ha un focus molto forte, se non esclusivo, sul Team Building: spingere i membri di un team, che stanno imparando a sentirsi parte di un unico obiettivo a uscire ulteriormente dalla propria confort zone, avrà con molta probabilità un effetto dirompente, vanificando i primi risultati ottenuti.

Ecco, il tempo giusto per le cose giuste, senza forzature e senza imposizioni che tendono ad anticipare i “periodi sensitivi” di cui parleremo nel prossimo post.

Stay tuned J