TL;DR: Ho passato sei mesi con quasi 1000 bambini pensando di insegnargli a programmare. Invece mi hanno riprogrammato. Mi hanno insegnato che fallire va bene se capisci perché, riuscire senza capire non va bene, e che osservare gli errori altrui è efficienza, non pigrizia. E che tutto questo vale soprattutto per noi adulti.
Racconterò questa esperienza in dettaglio all’AgileDay 2025 organizzato da Italian Agile Movement. Se siete curiosi, non leggete oltre ci vediamo lì, altrimenti questa che segue è la prima bozza della trascrizione del talk.
Mi sono seduto a un tavolo. Davanti a me: un quaderno chiuso, un astuccio chiuso con dentro alcune penne. Di fronte: venticinque bambini di quarta elementare che mi guardavano curiosi.
“Ecco le regole,” dico. “Uno per volta mi darete istruzioni precise per scrivere il vostro nome sul quaderno. Potete venire a vedere quando volete, anche quando non è il vostro turno.“
Il primo bambino, chiamiamolo Quattrocchi (non tanto per gli occhiali che non aveva ma per l’atteggiamento), parte sicuro: “Scrivi sul quaderno il mio nome.“
Io, con la faccia più seria possibile, prendo l’astuccio e scrivo sulla copertina del quaderno, usandolo come una immaginaria penna, in grande: “IL MIO NOME”.
Risate. Frustrazione. “No! Non così!“
“Ma hai detto ‘scrivi il mio nome’,” rispondo innocente. “E io ho scritto ‘il mio nome’. Cosa c’è che non va?“
Partono le iterazioni, come in un debug di gruppo fatto ad alta voce. “Apri l’astuccio.” “Prendi una penna.” “No, stappala!” “Girala con la punta verso il basso!” “Apri il quaderno!” “No, su una pagina bianca!” E poi, finalmente, lettera per lettera: “Scrivi Quattrocchi. Q-U-A-T-T-R-O-C-C-H-I.”
La cosa che ancora mi colpisce? Chi è venuto a vedere gli altri tentativi, anche quando non era il suo turno, ha capito il pattern quasi subito. Chi invece ha aspettato “educatamente” il proprio momento ha ripetuto gli stessi identici errori. Come quando in un team tutti fanno lo stesso errore perché nessuno legge davvero le post-mortem.
Non stavo insegnando precisione nelle istruzioni. Stavo insegnando che imparare dagli errori altrui non è barare, è efficienza. E che osservare attentamente spesso riduce il lavoro più di mille tentativi alla cieca.
Quella lezione non prevedeva computer, robot o codice. Solo un quaderno, una penna, e la volontà di sbagliare insieme.
Il patto sociale
«Lo sviluppo sostenibile è uno sviluppo che soddisfi i bisogni del presente senza compromettere la possibilità delle generazioni future di soddisfare i propri.»
Rapporto Brundtland, UN 1987
La definizione del Rapporto Brundtland del 1987 è chiara, ma quando pensiamo a sostenibilità pensiamo (giustamente) a CO2, energia, economia circolare. Raramente pensiamo al sapere, ai metodi, alla cultura che lasciamo.
A cavallo tra l’inverno 2024 e la primavera 2025 ho deciso di prendermi sei mesi per un esperimento. Ho lavorato con quasi 1000 bambini dalla terza elementare alla prima media, non per formare futuri developer, ma per provare a formare future persone raziocinanti. Persone che sappiano ragionare autonomamente, abbiano spirito critico, non abbiano paura di sbagliare, e soprattutto apprendano dai loro errori e da quelli altrui.
Premetto che non sono un pedagogo e non ho dati quantitativi da sbandierare. Non so quanti diventeranno developer, manager o astronauti, e onestamente non mi interessa. So però cosa ho imparato io, e penso valga la pena condividerlo.
La Theory of Change
Quando racconti di aver passato sei mesi con bambini per un obiettivo che si vedrà tra dieci-quindici anni, la prima obiezione è sempre: “Ma come fai a sapere se funziona?” La risposta breve: non lo so. La risposta lunga passa dalla Theory of Change.
La Theory of Change non è una teoria astratta da accademici, è un modo di pensare a come avviene il cambiamento nel tempo. L’idea base: parti dal goal a lungo termine che vuoi raggiungere, poi lavori all’indietro per identificare tutte le condizioni che devono essere presenti perché quel goal si realizzi. Non è “faccio X e spero in Y“, è “voglio Y, quindi mi servono le condizioni A, B, C, che a loro volta richiedono le condizioni D, E, F, e allora faccio le attività X che creano quelle condizioni“, per chi ha seguito i miei corsi sugli OKR sa bene di cosa parlo.
Nel mio caso il ragionamento è stato questo.
Goal a lungo termine: tra dieci-quindici anni voglio che almeno alcune di quelle persone siano “raziocinanti”. Cosa significa raziocinanti (almeno per me)? Persone che ragionano autonomamente, hanno spirito critico, non hanno paura di sbagliare, apprendono dai loro errori e da quelli altrui.
Bene, lavoriamo all’indietro. Perché questo accada, quali condizioni devono essere presenti? Devono aver sperimentato che sbagliare non è catastrofico. Devono aver capito che osservare gli errori altrui è efficienza. Devono aver avuto feedback immediato sulle loro azioni. Devono aver iterato più volte sullo stesso problema. Devono aver vissuto un ambiente dove la precisione conta ma l’errore è parte del processo.
E ancora all’indietro: perché queste condizioni si creino, cosa serve? Serve un ambiente sicuro dove sbagliare è permesso. Serve che il feedback sia chiaro e non interpretabile. Serve che ci sia tempo per iterare. Serve che vedano altri sbagliare e imparare. Serve che i vincoli siano espliciti e non arbitrari.
E allora le attività: giochi dove il fallimento è parte delle regole, robot che danno feedback inequivocabile, carte condizione che rendono espliciti i vincoli, gruppi dove tutti vedono tutti, cinque tentativi invece di uno solo, capogruppo che ruota per distribuire responsabilità.
La Theory of Change mappa il “missing middle”, quello spazio tra “faccio un gioco con i robot” e “tra quindici anni queste persone penseranno meglio”. È onesta nel dire: ecco tutte le cose che devono succedere perché il mio goal si realizzi, e ecco perché penso che queste attività possano innescare quelle condizioni. Può non funzionare, certo. Ma almeno so perché sto facendo quello che sto facendo e magari innesco in qualche testa la giusta scintilla.
Il collegamento con la sostenibilità è diretto. La sostenibilità richiede di ragionare su scale temporali lunghe, di accettare che l’impatto di oggi si vedrà domani, di investire in condizioni che oggi non danno risultati immediati. La Theory of Change è lo strumento per farlo senza andare a caso. Non è garanzia di successo, è garanzia di consapevolezza.
Non avevo KPI da dashboard. Non avevo metriche di conversione. Avevo un’ipotesi su come funziona il cambiamento e la voglia di testarla sul campo, sapendo che i risultati veri non li vedrò direttamente io. Ma questo non rende l’investimento meno valido, rende solo più onesta la discussione su cosa significa “impatto”.
Serious Play, sessant’anni di ricerca
“Giocare è una cosa seria. È il modo migliore per imparare.” ed anche “Se ascolto dimentico, se vedo ricordo, se faccio capisco.”
Bruno Munari – Laboratorio Giocare con l’Arte
So che qualcuno penserà “Ah, quindi ti sei creato una scusa per giocare con i bambini per sei mesi”, facciamo un passo indietro ed introduciamo il secondo tassello di questo piano macchiavellico: il serious play, che ha radici profonde e solide.
Seymour Papert al MIT nel 1967 inventa LOGO, il primo linguaggio di programmazione per bambini. Non per fare di loro dei programmatori, ma perché sosteneva che “non puoi pensare sul pensiero senza pensare a qualcosa di concreto“. Il coding era solo un “qualcosa” utile, come potrebbero esserlo gli scacchi o le ricette di cucina. Papert chiamava il suo approccio costruzionismo: impariamo costruendo cose, non ascoltando lezioni.
Papert era stato allievo di Jean Piaget, lo psicologo che negli anni Sessanta aveva teorizzato il costruttivismo: la conoscenza non si riceve passivamente come un bicchiere che si riempie, ma si costruisce attivamente nella mente attraverso l’esperienza. Sembra una banalità oggi, ma all’epoca era rivoluzionario contro la scuola trasmissiva del “io spiego, tu ascolti, tu ripeti“. Piaget diceva: impari facendo esperienza, non ascoltando lezioni.
Papert va oltre. Non basta l’esperienza, serve costruire oggetti esterni, tangibili, condivisibili. Non solo “learning by doing” ma “learning by making”. Quando costruisci qualcosa di concreto – un programma che disegna, un robot che si muove, una struttura LEGO hai feedback immediato, hai qualcosa da mostrare agli altri, hai qualcosa da iterare. L’oggetto esterno diventa l’ancoraggio per concetti astratti. Il costruzionismo aggiunge il layer della materialità al costruttivismo: le mani aiutano la testa a capire.
Ancora prima, Maria Montessori nel 1912 scriveva che “il gioco è il lavoro del bambino“. I bambini apprendono manipolando oggetti, provando, sbagliando. Gli adulti hanno solo dimenticato come farlo, ma il meccanismo funziona ancora benissimo a trenta, quaranta, cinquant’anni.
Stuart Brown, neuroscienziato, nel 2009 pubblica ricerche che mostrano come il gioco non sia un lusso evolutivo ma una necessità biologica per l’apprendimento. Gli studi sulla retention lo confermano: una lezione frontale ti lascia addosso circa il cinque percento dopo ventiquattr’ore, il learning by doing circa il settantacinque, insegnare ad altri circa il novanta.
Negli anni Novanta nasce LEGO Serious Play da una collaborazione tra LEGO Group, IMD Business School e MIT. Il principio base: “thinking with your hands“: le mani sanno cose che la testa non sa ancora. La NASA lo usa per strategic planning dal 2010. Non è “roba” da bambini, è “roba” che funziona.
Il gioco funziona con gli adulti per almeno tre motivi. Primo, bypassa l’ego: quando “giochi” puoi sbagliare senza difendere il tuo status. Secondo, crea psychological safety: puoi fallire perché è parte delle regole. Terzo, dà feedback immediato: il robot si ferma, il calcolo non torna, il risultato è sotto gli occhi di tutti senza possibilità di interpretazione.
Il “serio” in serious play non è il contrario di “divertente”. È serio perché ha obiettivi chiari e impatto misurabile. E soprattutto perché quando impari giocando, impari davvero.
Dal quaderno ai robot
Ho usato strumenti diversi per età e concetti, ma con un pattern comune: problema chiaro, vincoli espliciti, feedback immediato, iterazione consentita. Non “coding for kids”, ma problem solving through play.
Il gioco del quaderno l’ho già raccontato. Funziona perché non ha barriere tecnologiche e forza il focus sul processo. Ed è replicabile con qualsiasi compito procedurale: preparare un tè, disegnare una casa, spiegare come fare il deploy di un’applicazione.
Per i bambini di quarta elementare ho creato Games for Bees, un gioco che usa robot programmabili, le BeeBot, piccole api gialle che si muovono su una griglia combinati con carte condizione. Il setup è semplice: una griglia quattro per quattro sul pavimento, un robot che si muove di casella in casella, carte direzione (avanti, indietro, gira a destra, gira a sinistra), carte condizione (rock per gli ostacoli da aggirare, “usa meno carte”, “usa più carte”), carte partenza e arrivo.
Ogni gruppo di quattro-cinque bambini ha un nome e un capogruppo che cambia ogni giorno. Il capogruppo può parlare solo se tutti sono d’accordo. Hanno cinque tentativi per completare la sfida. Ogni sfida ha un punteggio. È pair programming travestito da gioco, è code review mascherata da sfida, è retrospettiva con le api robot.
Nel mio caso con i bambini: quando costruiscono una sequenza di carte per la BeeBot, non stanno solo “facendo esperienza di programmazione”. Stanno costruendo un artefatto fisico e condivisibile che possono mostrare, discutere, debuggare insieme. Le carte sul pavimento sono il loro programma, visibile a tutti. Questo è costruzionismo.
I concetti che ho insegnato, senza mai dire “questo è un if-then-else” – emergono dai giochi stessi.
Le condizioni: “Vai a fare la spesa, se al supermercato ci sono almeno due confezioni di uova comprane due, altrimenti non comprare nulla.” Mostro tre scenari con le uova disegnate.
- Una confezione, non compro.
- Una confezione, non compro.
- Due confezioni, ne compro due.
Poi chiedo: “Se scrivo ‘SE uova uguale a due’ cosa succede se ce ne sono tre?”
Scoprono da soli che uguale a due è diverso da maggiore o uguale a due. La precisione è importante, le assunzioni implicite uccidono. Proprio come nei requirement aziendali che diamo per scontati e poi ci chiediamo perché il prodotto non fa quello che ci aspettavamo.
I loop li spiego con i biscotti. “Mangia un biscotto finché ce n’è uno.” Mostro tre biscotti. “RIPETI mangia un biscotto FINCHÉ biscotti uguale a uno.” Cosa succede? Mangio, mangio, mangio. Mi fermo quando ce n’è uno. E poi? Il programma si ferma lì. I bambini capiscono subito: “Ma allora ne resta uno!” Esatto, se voglio mangiarli tutti devo scrivere FINCHÉ biscotti uguale a zero. Il robot non mente, non interpreta, esegue. Se il programma è sbagliato, il risultato è sbagliato. Feedback immediato, senza appello.
Le carte condizione cambiano le regole del gioco e diventano una lezione sul design sotto vincoli. “Usa meno carte possibili” diventa ottimizzazione: ogni carta risparmiata vale un punto extra. “Roccia” significa che c’è un ostacolo e devi aggirarlo, non puoi attraversarlo. Passando su certe caselle prendi o perdi punti. I bambini scoprono che i vincoli li fanno pensare diversamente, che la soluzione più semplice senza vincoli spesso non è la migliore con vincoli. È product design, è architettura software, è business: i constraint stimolano creatività invece di soffocarla.
Con i bambini di quinta elementare e dell’asilo ho usato LEGO Serious Play: costruire con le mani per pensare meglio. Il principio è che quando costruisci qualcosa, le tue mani sanno cose che la testa non ha ancora formulato. Un mattoncino diventa una metafora di un’idea, un problema, una soluzione. Funziona perché bypassa il filtro del “cosa diranno gli altri“: non dici “ho questa idea” esponendoti al giudizio, costruisci qualcosa e poi spieghi cosa rappresenta. È più facile, più onesto, più profondo.
Con alcuni gruppi abbiamo usato robot più avanzati come Dash&Dot e Lego SPIKE: sensori, luci, suoni. Stesso pattern di sempre, problemi chiari e feedback immediato. Esempio: “Accendi luce rossa se trovi un ostacolo, verde se la via è libera, ripeti finché non esci dal labirinto.” Condizioni più loop più sensori, stesso problem solving, diverso medium.
I messaggi dietro agli esercizi
Chi è venuto a vedere gli altri al tavolo del quaderno ha imparato prima. Non era pigrizia, era strategia. Imparare dagli errori altrui non è barare, è efficienza. Eppure in azienda quante volte reinventiamo la ruota perché non chiediamo “qualcun altro ha già provato questo?” o perché non leggiamo davvero le post-mortem che scriviamo?
La storia delle uova ci deve ricordare che un simbolo cambia tutto. Uguale a due contro maggiore o uguale a due. In azienda diamo per scontato cosa significhi “fatto”, “produzione”, “urgente”, “priorità alta”. I bambini imparano a chiedere, noi dimentichiamo di farlo.
“Il programma si ferma qui” è una frase che ho sentito decine di volte. I bambini sanno dire quando qualcosa non funziona, senza girarci intorno, senza politichese, senza “funziona ma…”. Il robot non va dove vogliamo, c’è un errore qui, fissiamolo. In azienda dovremmo prendere appunti.
Senza vincoli i bambini trovano subito la via più diretta. Poi, quando aggiungo “usa meno carte possibili“, devono ripensarci completamente. Ma partono sempre dal semplice. L’over-engineering è il nostro sport nazionale come adulti. I bambini ci ricordano: inizia semplice, poi itera se serve.
Il capogruppo non comanda perché ha un ruolo sulla carta. Il capogruppo guida se sa spiegare, se gli altri si fidano, se costruisce consenso. Ho raccontato meglio questo tema in un post precedente sull’autorità contro autorevolezza. I bambini seguono chi ha ragione, non chi urla più forte. In azienda dovrebbe funzionare allo stesso modo, ma sappiamo tutti che spesso non è così.
Insegnare per imparare meglio
“Se non lo sai spiegare in modo semplice, non l’hai capito abbastanza bene.”
Albert Einstein
Se insegnare agli adulti ci insegna ad ordinare meglio i contenuti per spiegarli più efficientemente, insegnare ai bambini ci invita a spiegarli meglio e a renderli più fruibili, obbligandoci ad approfondire, di fatto, la comprensione degli stessi.
Ho riscritto la spiegazione di IF-THEN-ELSE cinque volte prima che funzionasse con i bambini di quarta. Ogni volta ho tolto una parola tecnica inutile, ogni volta ho semplificato una metafora, ogni volta ho chiesto “ma perché?” a me stesso. Alla quinta versione ho capito che anche nelle consulenze o nei corsi uso troppe parole tecniche inutili.
Insegnare ai bambini è il miglior refactoring del tuo sapere. Devi togliere il jargon, devi trovare metafore che funzionano davvero, devi ammettere quando non sai perché loro se ne accorgono subito. Dopo sei mesi con i bambini ho riscritto parti dei miei libri “KPI, the right way” e “OKR, the right way”. Non perché fossero sbagliati, ma perché potevano essere più chiari. Ho usato la stessa logica del serious play applicata a temi aziendali che molti considerano noiosi. Funziona.
La, vera, cultura del fallimento
Tutti diciamo “fail fast“, “embrace failure“, “learn from mistakes“. Poi in azienda chi sbaglia viene punito in modi sottili o meno sottili, mentre chi non sbaglia ma non sa spiegare perché viene promosso perché ha “portato risultati”.
I bambini mi hanno insegnato una cosa diversa: fallire imparando va bene, riuscire senza capire perché non va bene.
Facciamo un esempio concreto. Bambino A fa dieci tentativi con il robot, sbaglia nove volte, ma alla decima sa spiegare perché quella soluzione funziona e le altre no. Bambino B copia la soluzione giusta da un altro gruppo al primo tentativo ma non sa dire perché funziona. Chi ha vinto? Il bambino A. Chi avrebbe preso il voto migliore in una scuola tradizionale? Probabilmente il bambino B, perché ha “risolto il problema velocemente”.
In azienda quante volte celebriamo il risultato senza chiederci “ma abbiamo capito perché ha funzionato?” E poi, quando dobbiamo replicare quel successo, non ci riusciamo e non capiamo il motivo. La cultura del fallimento non è “puoi sbagliare tranquillo”. È “devi capire perché hai sbagliato”. E simmetricamente, anche se meno discusso, è “devi capire perché hai avuto successo”.
Questo ribalta completamente la narrativa del “move fast and break things”. Non basta muoversi veloci e rompere roba. Serve muoversi veloci, rompere, e capire cosa hai rotto e perché. Altrimenti stai solo accumulando debito di conoscenza invece di debito tecnico, che è peggio perché più difficile da misurare.
E Ora?
“Bello Fullo, ma io non insegno ai bambini.“
Appunto. Non serve insegnare ai bambini per applicare questi principi.
L’onboarding in azienda potrebbe essere un “quaderno game” sul vostro dominio. “Spiegami come si fa il deploy.” Vedrete quante assunzioni implicite avete, vedrete quanto la vostra documentazione è chiara o quanto invece dia per scontate cose che scontate non sono. Il technical writing potrebbe passare un test semplice: puoi spiegarlo a qualcuno che non conosce il contesto? Se no, probabilmente o non l’hai capito abbastanza o è inutilmente complesso o c’è troppo jargon di mezzo.
Le code review potrebbero prendere la regola del capogruppo: chi fa review parla solo dopo che tutti hanno dato un’occhiata e c’è consenso su cosa vada cambiato. Trasforma il processo da monologo del senior a dialogo tra pari. Le post-mortem potrebbero concentrarsi non su “chi ha sbagliato” ma su “cosa abbiamo imparato”, e aggiungere anche “perché ha funzionato quella volta, possiamo replicarlo?”.
Il product design potrebbe abbracciare i vincoli come feature invece che come limitazione. “Usa meno carte possibili” è ottimizzazione, non frustrazione. I constraint stimolano creatività quando li accetti come parte del gioco invece di combatterli.
La mentorship potrebbe creare occasioni perché chi impara veda anche altri che sbagliano e imparano, non solo i successi patinati. La formazione continua potrebbe partire dal principio che se non sai insegnare qualcosa a un collega, a un junior, forse non l’hai capito abbastanza. La leadership potrebbe ricordarsi che si guida spiegando e costruendo consenso, non ordinando e sperando nell’obbedienza.
Le barriere esistono, ovvio. “Non ho tempo” è quella che sento più spesso. L’ho fatto fuori orario per mesi perché ci credevo, perché investire sulle persone è guardare oltre il prossimo sprint o il prossimo quarter. “Non ho competenze pedagogiche” è l’altra barriera comune. Non servono competenze pedagogiche, servono onestà intellettuale e voglia di iterare. Ho sbagliato spiegazioni cinque volte prima di trovare quella che funzionava. “È difficile misurare l’impatto” è verissimo. Non ho KPI, non ho conversion rate, non ho metriche da dashboard. So solo che quei bambini ora sanno che sbagliare è parte del processo se capisci perché sbagli. E tra dieci o quindici anni alcuni di loro saranno nei nostri team, nelle nostre aziende. Spero saranno persone raziocinanti, non automi che eseguono senza capire.
Il patto con chi viene dopo
Sono partito dalla definizione del Rapporto Brundtland del 1987 sul sviluppo sostenibile come patto con le generazioni future. Ho passato sei mesi pensando di insegnare ai bambini a programmare. Ho finito capendo che mi stavano insegnando a pensare meglio, a spiegare meglio, a sbagliare meglio.
La sostenibilità non è solo pannelli solari ed economia circolare. È anche cosa lasciamo a chi viene dopo: non solo codice e processi, ma un modo di pensare. Le “papere”, come le chiamavo le idee in un vecchio post di qualche anno fa, cresceranno. Alcune diventeranno developer, altre manager, altre insegnanti, altre astronaute. Ma tutte sapranno che sbagliare non è un fallimento ma un’iterazione, che osservare gli errori altrui è intelligenza non pigrizia, che la precisione conta e le assunzioni implicite uccidono, che la soluzione più semplice è quella da cui partire, che si segue chi sa spiegare non chi sa ordinare.
E magari tra dieci o quindici anni, quando saranno nei nostri team o nelle nostre aziende o nei nostri consigli di amministrazione, ricorderanno il gioco del quaderno. E chiederanno: “Puoi spiegarmelo meglio? Voglio capire perché, non solo cosa.“
Games for Bees è rilasciato con licenza CC BY-SA 4.0. Trovate tutto su darumahq.it/seriousplay: griglie, carte, istruzioni, esempi. Usatelo, modificatelo, miglioratelo, condividetelo.
I miei libri “KPI, the right way” e “OKR, the right way” applicano la stessa filosofia di serious play a temi aziendali che molti considerano noiosi. Perché anche le metriche e gli obiettivi si possono insegnare e imparare meglio, con meno aria fritta e più concretezza.
E voi, quale sarà la vostra “quarta elementare”? Una persona da mentorare, un corso da tenere gratuitamente, una documentazione da riscrivere “a prova di chi non sa”, un processo da spiegare con un gioco? Perché alla fine, come diceva Seymour Papert già nel 1967, “non puoi pensare sul pensiero senza pensare a qualcosa di concreto“. Il coding, gli OKR, i KPI, i processi agile sono solo “qualcosa” di utile. Il vero obiettivo è imparare a pensare meglio.
E se insegnare ai bambini mi ha insegnato qualcosa, è che noi adulti abbiamo smesso di giocare troppo presto.