Aperitivi tecnologici

Questo mese riprendiamo una vecchia abitudine, riaprendo una rubrica di qualche tempo fa: gli aperitivi tecnologici o più pretenziosamente, Apéritif Technologique: uno spazio su MokaByte in cui pubblichiamo qualcosa che è a metà fra le interviste agli esperti e la chiacchierata informale.

In questa ripartenza degli aperitivi tecnologici, abbiamo il piacere di dialogare con Francesco Cirillo [1].

Francesco è conosciuto a molti, anche al di fuori dell’ambiente IT, per il successo della tecnica di produttività da lui inventata “The Pomodoro Technique®” i cui concetti sono riassunti in un libro, tradotto in numerose lingue [2] e recensito in maniera positiva dalla stampa internazionale.

Ma Francesco è anche uno di coloro che, fin dalla prima ora, ha contribuito a far nascere il movimento agile nel nostro paese. Da qualche tempo si è trasferito a Berlino dove, fra le altre cose, sta curando la nuova edizione del libro sulla tecnica del pomodoro.

 

Giovanni: Essendo passato molto tempo dall’ultima volta in cui ci siamo scambiati quattro parole, vorrei prima di tutto chiedere a Francesco di presentarsi ai nostri lettori. Chi sei? Cosa fai? Di cosa ti occupi? Perché sei? Dove vai? Cosa vuoi? Come cucini l’uovo?

Francesco: Da una parte faccio evolvere la Tecnica del Pomodoro. Attraverso i corsi che tengo sulla tecnica ho conosciuto persone da ogni parte del mondo e con necessità molto diverse. Ascolto le loro esigenze e troviamo insieme soluzioni. Dopo diversi anni ho raccolto una serie di pratiche per raggiungere senza ansia obiettivi individuali o in team in contesti caratterizzati da incertezza e cambiamento.

Dall’altra, sviluppo Henry Solves It, un sistema software che può fare un po’ di tutto: da un timer alle fatture, dal budget al customer care. Sviluppando Henry, testo da diversi anni le mie idee su come sviluppare software in modo efficace: pochi moduli software (“ingredienti”) in grado di essere combinati e di generare comportamenti di tipo molto diverso tra loro (“ricette”).

Sono una persona che a Berlino ha iniziato a bere caffe e a fare coloratissime frittate. Ma tu delle uova, che ne sapevi?

Giovanni: La domanda sull’uovo l’ho tirata a caso, ma ti avverto che sono campione europeo di frittata di patate…

 

Uno sguardo distaccato ad Agile

Giovanni: La seconda domanda che vorrei farti è una specie di riflessione sulla cultura agile in Italia. Sei stato uno degli “attivisti” agili della prima ora: in tutti questi anni come hai visto cambiare il panorama agile nel nostro paese? Ora che vivi all’estero, stai notando delle differenze sostanziali rispetto all’Italia?

Francesco: Premetto per correttezza che ho iniziato a occuparmi di XP nel 1999 e ho smesso di occuparmi di Agile in un periodo compreso tra il 2005 e il 2010. XP è concreto, Agile è astratto. Mi ci volle parecchio per capire l’essenza di XP e, una volta raggiunto l’obiettivo, mi posi il problema di quale fosse il passo successivo. Iniziai la mia ricerca nel 2008. Non avevo l’ambizione di diventare un “pensionato agile”.

Dalle richieste di lavoro su linkedin, mi sembra che oggi Agile sia diventato lo status quo un po’ ovunque. Almeno nominalmente. Spesso parlo con i CTO di aziende qui a Berlino che fanno pubblicare quegli annunci. Mi raccontano di debiti tecnici rilevanti, software fragile, difficoltà nel consegnare feature al ritmo richiesto dal marketing. Ma questi erano i problemi che avevamo negli anni Novanta. Non li avevamo risolti con i metodi agili? I costi del cambiamento in un sistema del genere non sono alti, insopportabili, pericolosi? La risposta che spesso mi danno è: “Se serve, abbiamo i soldi per riscrivere da zero il software”.

Di sovente gli sviluppatori — soprattutto quelli della nuova generazione: ventenni e trentenni — sono completamente e orgogliosamente disinteressati ad Agile, design pattern, TDD, etc. Tutto ciò rappresenta per loro una gabbia, una inutile costrizione, una forzatura da evitare. Non conoscono Beck e non sono sicuri di aver sentito parlare di Fowler. L’idea che Agile possa essere paragonato a una gabbia è per me molto interessante. L’idea che non sappiano che Visitor sia il nome di un pattern mi affascina.

Negli ultimi anni ho insegnato Sistemi Informativi in una universita di Berlino. Si tratta di studenti di economia. Organizzo le classi in team e ogni team sceglie un tema tecnologico: AI, sistemi di pagamento, criptovalute… quello che vogliono, sempre che sia rilevante in termini tecnologici o metodologici.

Di recente un team di studenti ha scelto il tema “Waterfall vs. Agile”. Si tratta di giovani di 19-20 anni. Si sono sorpresi quando gli ho detto che i metodi agili provengono dallo sviluppo software. Occhi totalmente innocenti e privi di pregiudizio. Tre mesi di ricerca li portano a questa conclusione: il Waterfall è da preferire ad Agile. Al mio stupore la loro replica è inesorabile: “senza dubbi: Waterfall è chiaro, ben organizzato, Agile è confuso e caotico.”

Allora provo la mia carta migliore: “Ma il cambiamento? La mancanza di feedback?”, “No, prof. Troppo caotico e incerto”.

Trovo questa osservazione molto interessante: “Questa generazione mi sta dando i requisiti per il processo di sviluppo per loro ideale: chiaro e ben organizzato sul da farsi. Sono in grado di trovare una soluzione?”.

Insomma, per qualche anno ho pensato fosse in atto una regressione: niente design, niente processi, niente Beck e Fowler, viva il waterfall… Poi ho iniziato a pensare che questi input rappresentassero i requisiti per il prossimo passo.

E in Italia succede qualcosa del genere?

 

Buone pratiche di sviluppo software

Giovanni: Entrambi gli scenari mi sono noti. Quanto alla prima affermazione — conoscenza delle buone pratiche di sviluppo del software — mi verrebbe da chiederti: servono? TDD è utile? Usare i pattern ha senso? È proprio necessario fare refactoring? Voglio dire, se certe pratiche e metodologie puntano a costruire un prodotto di valore, ben fatto, durevole, etc. perché non le applichiamo e via?

Francesco: Prima di valutare se quelle pratiche “evolutive” siano efficaci o meno in generale, bisogna valutare se esse se siano adatte agli sviluppatori. Infatti il TDD, l’uso di design pattern e l’applicazione di refactoring sono pratiche “aperte”: richiedono decisioni soggettive da parte dello sviluppatore per poter essere applicate. Ti faccio qualche esempio.

• TDD: meglio testare il caso con due transazioni? O meglio testare il caso con una transazione più complessa?
• Design Pattern: meglio far evolvere il sistema verso un pattern di Observer? O meglio un Composite combinato con uno Strategy?
• Refactoring: meglio estrarre una serie di metodi in uno Strategy? O meglio far evolvere il design introducendo una nuova classe?

Pur applicando le stesse pratiche evolutive — TDD, design pattern e refactoring — sviluppatori diversi potranno dare risposte diverse alle questioni di design che ho esposto sopra anche se devono sviluppare la stessa feature…

Le decisioni rispetto al passo di design successivo sono soggettive: dipendono dalle nostre conoscenze, dalle esperienze pregresse e dalla nostra personale attitudine all’incertezza, all’esplorazione e al cambiamento.

Nel design evolutivo, nel momento in cui si inizia a sviluppare, non si sa e non si “vuole conoscere” il design finale: si “preferisce” essere sorpresi dal codice e, piccolo test dopo piccolo test, far emergere la soluzione finale.

Non tutti gli sviluppatori apprezzano l’incertezza e il caos che il design evolutivo richiede. E queste pratiche ricche di incertezza e caoticita possono rivelarsi frustranti e quindi non produttive. Quegli sviluppatori di cui ho parlato hanno ragione a non voler applicare “TDD, design pattern e refactoring” se per loro l’incertezza e la caoticità di quelle pratiche sono difficili da sostenere.

Giovanni: Sì, il tuo ragionamento mi convince, ma ti chiedevo provocatoriamente se TDD o XP siano utili perché volevo provare a contestualizzare. Prendo a pretesto quanto è successo a MokaByte nel corso degli anni per ampliare il discorso.

Nel 1996, insieme ad altri — allora — baldi giovani, cominciammo a pubblicare questo sito. Anzi, si trattava di una vera e propria “rivista online”. Erano anni in cui Internet si afferamava, nasceva il web come lo conosciamo, e arrivano Java e altre novità tecnologiche del momento. All’epoca mi ricordo che dedicavamo appassionatamente giorno e notte allo studio di tutto questo mondo nuovo. Succhiavamo le poche risorse disponibili al momento: io ho imparato Java studiando il JavaDoc, perché libri ancora non ce ne erano. Quando vidi il mio primo pattern rimasi folgorato.

Poi riuscimmo a concretizzare in lavoro i nostri sforzi di appassionati, MokaByte divenne una s.r.l. e, pur ligi al dovere di proporre contenuti di valore, affiancammo servizi di consulenza e formazione. Negli anni, mi sono spostato sempre su nuovi fronti, passando dalle tematiche più elementari di linguaggio a quelle architetturali e di progetto. E anche MokaByte è cambiata tanto nel frattempo.

Arrivo al dunque: inizialmente conoscere tre istruzioni JDBC e qualche altro “trucco” ti poneva fra i pochi detentori della fiamma della conoscenza, ma con il tempo si rese evidente che una sempre maggiore concorrenza richiedeva di aumentare le proprie conoscenze e far crescere il “livello” del servizio erogato

Ora, so di dire una cosa “brutta”, ma bastava guardare agli onorari per capire che, con il tempo, una consulenza sulla scrittura di buon codice non veniva più pagata come prima: stavano arrivando eserciti di consulenti formati in serie, che scrivevano “quasi” lo stesso codice, ma costavano molto molto meno.

Ecco, io oggi vedo la stessa cosa nell’Agile, con Scrum Master che, dopo aver letto un libro e fatto due giorni di corso, sono paracadutati oltre le trincee.

Siccome non mi piace generalizzare, ti posso dire che vedo anche il contrario. Vedo programmatori in gamba che sanno usare con senno i pattern e che non si offendono se gli dici GOF e non pensano che Uncle Bob sia un cantante indie-folk delle praterie statunitensi… C’è effettivamente di tutto, anche l’eccellenza.

Quindi ti rifaccio la domanda: siamo certi che sia colpa dei “giovani d’oggi” che — oltre a non voler lavorare più la terra — non studiano i pattern? Qualcuno sopra di loro sta misurando il tempo di rilascio? O il numero di ricicli di un bug?

Francesco: In realtà io penso che quei giovani abbiano ragione a non voler applicare “TDD, design pattern e refactoring”. Tu non vorresti una soluzione meno “incerta e caotica” per sviluppare software?

Fanno bene quegli sviluppatori a non applicare “TDD, design pattern e refactoring” se pensano o meglio ancora se hanno sperimentato che quelle pratiche non sono efficaci per loro o non si adattano alla loro attitudine all’incertezza. Troveranno qualcosa di piu efficace e meno frustrante. Troveranno la loro soluzione.

Giovanni: Sul secondo passaggio — la reazione degli studenti che preferiscono la “tranquillità di un processo normato alla vaghezza dell’Agile — non mi dilungherò dicendo che Agile non è una metodologia ma una filosofia mentre Scrum o Kanban lo sono; OK potrei essere più preciso ma poi i lettori ci abbandonano. Quindi forse l’errore, se di errore si tratta, nasce dal confronto di una metodologia superstrutturata con una filosofia fatta di principi e valori. Scrum invece è tutt’altro che vago e approssimativo. Poche regole ma moltissima disciplina. Cosa che, specie nel nostro Paese manca moltissimo.

Detto questo, non è raro imbattersi in giovani che si oppongono a cose come l’autoorganizzazione, la sperimentazione, l’approccio iterativo. Così come invece trovo in Project Manager “anziani” il desiderio di provare qualcosa di differente, di lavorare in gruppo e di riuscire a decidere senza aspettare un’autorizzazione da sette livelli gerarchici.

Sto generalizzando, lo so. Se dovessi sintetizzare in modo da non banalizzare ti potrei dire che processi normati ovviamente sono più facili da applicare: “schiaccia tasto, mangia banana”. Metodologie che si basano su un approccio “sperimentale” sono per ovvi motivi più faticose da usare. Di mezzo c’è la personale attitudine — schiacciatori di tasti vs. scienziati pazzi — ma c’è anche da considerare il costo/beneficio che un approccio può dare.

Agile non è per tutte le casistiche. Se devi fare 100000 di penne a sfera forse non ha senso mettere in piedi un modello sperimentale. Sappiamo come mettere in piedi un processo che lo faccia nel modo migliore possibile. Ford era contentissimo di fare catena di montaggio: funzionava. Qui si sfocia nella teoria della complessità, per cui mi fermo.

Tornando a quegli studenti: forse mancava loro il contesto, forse non hanno vissuto abbastanza a fondo la questione, oppure forse uno di loro era follemente innamorato della bassista dei “Waterfall”, noto gruppo musicale della loro università… L’assenza di prove non è la prova dell’assenza… Ma prima di sfociare nel “marzullismo”, dico anche che, in condizioni analoghe, probabilmente anche io avrei risposto nello stesso modo.

Buoni motivi per non adottare agile

Francesco: Io difendo la scelta di quegli studenti. Hanno studiato i valori e i principi agili, Scrum, il Waterfall e hanno preso la loro decisione in maniera autonoma e consapevole. Tra l’altro, la loro decisione, proprio perché mette in primo piano le persone — le loro paure e necessita — più che i processi, non è proprio per questo una decisione che segue i principi agili?

Se i giovani non apprezzano autoorganizzazione, sperimentazione e approccio iterativo, se l’ambiente corrente non favorisce un approccio “sperimentale”, per me si dovrebbe smettere di insistere di applicare lo sviluppo Agile. Troveranno qualcosa di nuovo ed efficace per loro.

Per molti sviluppatori applicare TDD e refactoring porta ad aumentare le proprie paure a causa della maggiore incertezza intrinseca nel processo di esplorazione di quelle pratiche evolutive. Una volta che questi sviluppatori hanno visto fare TDD, l’hanno provato, lo hanno capito, dovrebbero essere liberi di non usarlo.

Insomma, seguendo la filosofia agile, non si dovrebbe cercare di adattarsi alle persone e ai loro contesti invece di finire per imporre un processo, una pratica o una filosofia? A me sembra chiaro il motivo per cui molte persone smettono o non sono interessate ai metodi agili: non si sentono ascoltate dal mondo agile.

Giovanni: Una visione forse pessimistica? Se con l’approccio agile dobbiamo risolvere le paure di quei giovani posso darti ragione. L’output — raggiungbile con una metodologia agile, iterativa, incrementale — potrebbe essere qualcosa che protegge quegli studenti. Potremmo quindi usare agile per confezionare waterfall per quegli studenti. Dubito però che per un’azienda sia quello l’obiettivo. Nel contesto dove mi muovo abitualmente ci sono prodotti da realizzare, requisiti da raccogliere, stime, budget…

Quindi qui il quesito che dovremmo porre a quegli studenti — e a noi stessi — è se l’approccio deterministico possa aiutarli nel portare a casa il progetto. Ci sono alcuni contesti in cui il determinismo funziona, altri dove variabilità e innovazione richiedono un approccio di tipo diverso. Lo abbiamo visto molte volte. Forse non stiamo spiegando bene agli studenti cosa succede sui progetti.

Sono d’accordo che, sulla carta, Waterfall è più facile: regole da seguire, tempistiche, output chiari. Poi sappiamo che molte volte un Gantt compilato il giorno zero di progetto risulta totalmente infedele con quello che succede sul campo. Che avere l’elenco dei requisiti inciso nella pietra prima dell’inizio del progetto non è un vantaggio, ma un terribile vincolo che può portare a un prodotto non utile per i l’utente. A quegli studenti forse mancava un pezzo. Portiamoli sul campo (genbustu).

 

Cambiamento e trasformazione

Giovanni: Quanto abbiamo detto fin qui mi fa venire in mente il tema della trasformazione. Nel cercare di introdurre il cambiamento — che sia agile o un nuovo paradigma organizzativo — qual è l’errore principale che vedi compiere dagli attori coinvolti nella cosiddetta trasformazione? Quali sono le maggiori difficoltà. E i successi maggiori a cosa sono legati?

Francesco: L’errore principale sta… nel cercare di introdurre “il cambiamento”. Cerco di spiegare. Adottare un paradigma, agile o meno che sia, viola uno dei principi dei metodi agili: i processi dipendono dalle persone, non le persone dipendono dai processi. Meglio: i processi dipendono dalle paure dei membri del team.

Se in un’azienda lavorano due team — Marco e Stefano in un team e Maria, Ilaria e Giuseppe in un altro — questi due team dovrebbero seguire due diversi processi perché le paure di Marco e Stefano sono diverse da quelle di Maria, Ilaria e Giuseppe. L’applicazione di un paradigma — aperto quanto vuoi — prevede invece che le persone, tutti e 5 insomma, si adattino a esso: la gabbia, insomma.

Se ai miei studenti fa paura il caos e la confusione agili, se essi sono consapevoli della loro paura, e sentono che la struttura rigida del waterfall li protegge da quelle paure, se sono consapevoli delle conseguenze positive e negative del waterfall, be’ la soluzione più produttiva per loro sara scegliere di applicare waterfall.

Mi dirai, Giovanni: “ma sappiamo già che avranno problemi”. Be’ quegli studenti sono consapevoli di quegli eventuali problemi, ma questa evidentemente non è la loro paura. “Inutile anticipare” vale anche per le paure, no? Pull vs. push, no? Se si svilupperà in loro una nuova paura, troveranno una soluzione in modo consapevole: la loro soluzione. E se la troveranno, quella soluzione potrebbe essere “il prossimo passo” dopo l’era agile. La loro consapevolezza è la chiave di tutto. Mi fido di loro come di ogni sviluppatore consapevole.

L’errore principale nelle trasformazioni agili è, per me, delegare ad altri — consulenti, coach, mentor, team leader, collega sviluppatore con le “idee chiare” — la ricerca di una soluzione alle proprie paure, individuali o di team. Nessuno conosce le nostre paure meglio di noi stessi!

Far adottare il paradigma agile a chi perfino non condivide le paure alle quali “Agile” risponde significa metterlo in gabbia. Chi è in gabbia non solo non risolve le proprie paure, ma il paradigma, la gabbia che lo imprigiona, rende più complicato risolvere le proprie paure. L’essere in gabbia può diverntare una nuova paura.

In altre parole, “diventare agili” è una inutile illusione. La paura è l’impedimento a essere produttivi. Diventare consapevoli delle proprie paure è il fattore chiave per diventare produttivi. Il vero successo per me si dovrebbe misurare in termini di consapevolezza del team verso le proprie paure e del processo messo in atto per risolverle.

Giovanni: Risposta molto interessante. Vedo nella tua risposta tematiche di autodeterminazione, individuazione delle paure, consapevolezza… Mi sa che non ci basta tutto lo spazio che possiamo avere qui. Forse dovremmo vederci davanti a un buon Wiskey. Ti riporto intanto qualche mia brevissima considerazione sui vari punti che hai toccato.

OK che ogni team/gruppo di persone tenti di applicare un proprio metodo di lavoro, di indagine, di processo. Non sempre l’organizzazione offre questo livello di autonomia. #autodeterminazione

Non sempre le persone hanno fiducia in questo approccio, spesso preferiscono essere consigliati o guidati. #paura

Se sviluppano nuove paure, ovvero incontrano nuove difficoltà, sapranno come reagire e trovare un modo per risolverlo. Nuovamente #autodeterminazione

Ma, in questo processo di ricerca, è necessario anche comprendere le paure e i benefici di una azione. #consapevolezza

Parto da un primo punto: non sono un crociato della battaglia Scrum vs. Waterfall. Tutti sappiamo che, a seconda del contesto, la pianificazione vecchio stile e il waterfall possono funzionare con benefici risultati: prodotto di qualità, guadagno economico, rispetto dei tempi e così via).

Essere agile probabilmente è oltre la sfida di oggi. Ragionare con le proprie paure è il vero tema. Se le persone si sentono a loro agio con un approccio più vicino a sconfiggere le loro paure, probabilmente questo le porterà a essere più produttive. Loro. Singolarmente. Ma sappiamo tutti a cosa portano le ottimizzazioni locali; e quanto invece sia importante una visione sistemica.

Il termine paura è abbastanza azzeccato. Sembra a volte che Agile voglia puntare dritto verso quella paura, la stuzzica, la provoca; doversi mettere al posto di guida e prendere in mano il volante; valutare e quindi mettere in discussione gli schemi che sembravano funzionare; misurare gli effetti di lavorare alla vecchia maniera. Agile da questo punto di vista è un bel “rompiscatole”. Ma non potevamo fare come abbiamo sempre fatto?

Il passaggio che mi piace di più del tuo pensiero è quello della “consapevolezza” e di quanto manchi. consapevolezza di quello che stiamo facendo, del senso di fare le cose in un certo modo, dei costi o dei benefici derivanti dall’applicare Waterfall o Scrum.

Non è un caso che molti dei pavidi progetti di cambiamento a cui ho assistito sono magicamente “evaporati” quando qualcuno provava a dire “Bello! Adesso che abbiamo fatto i primi esperimenti, che ne dite se provassimo a introdurre una qualche metrica? Così, giusto per vedere se quello che stiamo facendo è utile oppure no”. Paure e consapevolezza.

Proprio per questo motivo sono d’accordo con te quando dici che la trasformazione non si delega. La si guida direttamente. Non credo nel farsi guidare da esperti o da consulenti del cambiamento o dell’agile.

Combatto fortemente con il tema dell’empowerment — a cui preferisco il termine emancipazione — delle persone, perché preferisco stimolare la capacità della sperimentazione e addirittura di “metasperimentazione” (imparare a sperimentare come sperimentare). Delegare la trasformazione di fatto introduce un fattore di fragilità che alla lunga diventa pericolosa, giusto per citare quello che adesso è il mio focus, l’antifragilità.

Credo invece che un approccio di coaching possa essere utile. Sembra una sfumatura — in fondo, osserverai, stai comunque cercando di vendergli qualcosa —ma è una sfumatura importante: non proponi una soluzione preconfezionata, ma stimoli la ricerca e la sperimentazione affinché siano le persone a trovare autonomamente la soluzione adatta per loro. Di fatto anche tu con i tuoi studenti hai un approccio di questo tipo.

Magari quello che potrebbe essere utile proporre a quegli studenti è di capire cosa voglia dire “adatto”: indipendentemente dalla facilità con cui ci si ritrovano, come misurano il valore o l’utilità di un modo di lavorare? Costi/Benefici. Il fatto che un singolo lavori meglio probabilmente a livello sistemico potrebbe non essere la soluzione. Ottimizzazioni locali vs. miglioramenti sistemici.

Francesco: La produttività del team non puo migliorare se i singoli membri del team non sono consapevoli delle proprie paure e necessita. Il ruolo del coaching è molto delicato soprattutto nell’ottica agile.

Penso che potrebbero esistere dei consulenti agili, ma il loro ruolo dovrebbe essere limitato a rispondere alle domande dei membri del team, dare chiarimenti o dimostrazioni rispetto a pratiche o concetti e offrire esperienze. Dare cioè la possibilita al team di prendere una decisione informata rispetto al proprio processo.

Un consulente che prende temporaneamente il ruolo di coach di un team rischia di influenzare le decisioni del team rispetto al miglioramento del proprio processo. Un buon consulente agile, per me, dovrebbe offrire un servizio di supporto alle decisioni del team, senza la minima ingerenza.

 

Temi per il futuro

Giovanni: per il mio lavoro di coach agile, spesso sono coinvolto nell’organizzazione di molti eventi e conferenze. Io stesso spesso presento talk ai vari IAD, Agile for Innovation, Agile Venture, Agile Business Days e via dicendo. Le conferenze sono spesso alla ricerca di un “tema” portante su cui incentrare i vari interventi. Per esempio la prossima edizione dell’Agile for Innovation è quello della cosiddetta platform economy.

Ecco, se tu dovessi darmi un suggerimento per la prossima conferenza da organizzare in Italia, quale potrebbe essere secondo te un argomento di frontiera intorno al quale incentrare il dibattito?.

Francesco: L’argomento ce l’ho! Il tema è il seguente: “Come mai, dopo quasi 20 anni dal Manifesto Agile, non abbiamo ancora scoperto un metodo migliore dei metodi agili per sviluppare software?”. L’Agile Manifesto dice infatti: “Stiamo scoprendo modi migliori di creare software, sviluppandolo e aiutando gli altri a fare lo stesso.”

Ricordo il mio professore di sociologia ed epistemologia dire qualcosa del genere: un buon metodo è un metodo organizzato per essere “sconfessato” — ossia confutato — nel più breve tempo possibile. Il metodo migliore, cioè, è quello capace di favorire la ricerca del prossimo passo…

Giovanni: Bello! Mi si riaccendono lampadine su antifragiltà e metasperimentazione. Sarebbe bello proporre qualcosa insieme al prossimo Italian Agile Day, anche se questo è un terreno scivoloso… Provi a formulare un metodo che rispetti questo pensiero, e non appena hai finito di scriverlo è già vecchio, confutabile, superato… Pare che stiamo entrando in un vortice ricorsivo. Anzi, ora che ci penso, quello che ho appena pensato, immaginato e detto… è già sbagliato.