Digital evolution, la lezione delle cattedrali romaniche

Il Medioevo lascia in eredità un modello future proof per la digital transformation. Dagli stand-up meeting sul campo all’approccio “zero top-down” del magister, l’analisi comparata di tipologie di governance che l’evoluzione innovativa riporta d’attualità.

Romanico e digitale, un legame a sorpresa

Recentemente ho visitato le stupende chiese romaniche di Verona (S. Zeno, S. Fermo, S. Anastasia, il Duomo, la Trinità…) e non ho potuto fare a meno di pensare al legame che esiste tra queste opere d’arte e l’argomento di cui ho parlato in un articolo scritto qualche tempo fa: la trasformazione (o meglio evoluzione) digitale e la governance agile dell’IT e delle aziende. Follia? Spero di no, ma per capirlo bisogna fare qualche passo indietro.

Aggiungo che, soprattutto in questo momento storico in cui i cambiamenti sono stati e saranno violenti per tutte le aziende e le organizzazioni, la flessibilità e l’agilità sono virtù fondamentali. Fino a prima della crisi innescata dal coronavirus, alcune aziende erano “costrette” a cambiare continuamente, altre navigavano placide come se il mondo fosse un mare tranquillo e sempre uguale. Ora quel tempo è finito. Nel mio ambito ad esempio (l’università), è cambiato completamente sia il modello operativo che il modello di business in due settimane!

Mi è sembrato giusto allora riprendere i temi della governance agile è l’ho fatto guardando al passato. Un passato non vicino, molto più mobile e cangiante di quanto siamo abituati a pensare, dove pandemie e instabilità sociali erano comuni e dove l’adattamento al cambiamento era questione di sopravvivenza: il medioevo.

Ma andiamo con ordine: innanzitutto, va detto che quello che ho sintetizzato nel citato articolo sul metodo G.and.A.L.F. non è in realtà nulla di nuovo e questo per almeno due buoni motivi.

Il primo è che, come spiega lo svolgimento dell’acronimo (Governance and Agile Lean Frameworks), il contesto da cui derivano i principi espressi è quello dei movimenti Agile e Lean. Molti dei principi sono presi proprio da questi mondi.

Il secondo motivo invece è forse meno evidente, ma non meno importante. Il riferimento a Tolkien è certamente dovuto alla mia passione per la mitologia che questo incredibile studioso e scrittore ha saputo creare, ma esprime anche il fatto che forse il passato remoto (e in particolare il medioevo che tanto affascinava Tolkien) ci può fornire dei paradigmi per la trasformazione/evoluzione digitale di oggi più utili di quelli del passato prossimo.

Più ci penso e più mi convinco che i modelli di leadership e di specializzazione che si sono imposti dal XVI-XVII secolo in poi stanno segnando il passo rispetto al cambiamento in atto. Questo ancora prima del coronavirus, in modo stridente ora. Insomma, lo scienziato e poi il tecnico, che si sono evoluti in un gruppo di tecnici e specialisti in grado di condurre le grandi innovazioni tecnologiche, sono un modello semplicemente non adeguato per l’evoluzione digitale. Si noti che questo è stato (e in alcuni casi ancora lo è) un modello anche virtuoso: ci ha permesso di andare sulla Luna, probabilmente ci porterà su Marte ed ha prodotto e produce grandi scoperte scientifiche in tantissimi ambiti.

Strategie per un sistema tecno-umano

Però quando si parla della trasformazione/evoluzione digitale, si sta trattando una materia un po’ diversa. Non stiamo parlando solo di tecnologia o di scienza, ma piuttosto di un sistema tecno-umano (o umano-tecnico) complesso. Per questo credo sia interessante guardare a come venivano costruite le chiese romaniche.

Non voglio fare una classifica, quindi facciamo che qui ogni lettore a questo punto può pensare alla sua chiesa romanica preferita. Ciò che le accomuna tutte è il fatto che “La cattedrale romanica rappresenta un perfetto equilibrio tra sapere aulico e inventiva popolare, ed è insieme il centro dell’interesse comune”^[2]. Senza volermi spacciare come esperto d’arte che non sono, ho trovato però alcune caratteristiche del percorso di costruzione di una chiesa romaniche particolarmente interessanti. Istruttiva è la storia documentata della costruzione del duomo di Modena da parte di Lanfranco, un famoso architetto medioevale^[3].

Adattabilità e vision a lunghissimo tempo

Questo è a mio parere un punto cruciale. Uno dei rischi delle metodologie derivate dal mondo Agile e Lean è quello di enfatizzare la velocità, l’adattabilità e la flessibilità con un’ottica di breve periodo. Gli architetti romanici non facevano piani dettagliati, si adattavano continuamente e in modo flessibile alle evoluzioni del cantiere: crepe, cedimenti del terreno, cambiamenti nel conteso.

Nessuno può negare però che avessero anche un’ottica di lungo periodo. Le chiese che hanno realizzato sono lì a dimostrarlo. Questo perché l’architetto e tutti gli stakeholder coinvolti, che vedremo tra poco erano tanti e diversi, avevano dei valori comuni (la fede, il senso di appartenenza ad una comunità, un’idea del bello…) e una vision condivisa (la volontà di dare gloria a Dio, ma spesso più prosaicamente alla propria città e alla propria casata).

Da questi valori derivavano poi degli outcome o risultati/obiettivi condivisi. Il principale obiettivo era naturalmente la costruzione della Cattedrale stessa. Questa distinzione è fondamentale, perché i valori e la vision sono stabili, gli outcome adattabili. L’esito è un’opera (outcome) che cresce senza un piano formalizzato e rigido, si adatta bene ai cambiamenti del contesto e resiste alla prova del tempo perché persegue una vision ancorata a dei valori^[4]. Non dovrebbe essere questo l’obiettivo di ogni percorso di Business Agility?

Nel contesto G.and.A.L.F., quanto visto si mappa sui primi due principi: “Salviamo la terra di mezzo” e “Distruggiamo l’anello”.

Coinvolgimento degli stakeholder

Amo particolarmente la vignetta di Dilbert che ho riportato perché troppe volte si parla di Change Management in modo acritico. L’assunto è che qualcuno (il vertice? Il top management? La proprietà?) abbia tutte le risposte, quindi proponga un piano di cambiamento che deve essere seguito da tutti. Se questo non avviene… il change management è la soluzione.

Purtroppo in questa visione il change management è una forma di manipolazione. Le resistenze sono feedback e nel modello Agile/Lean i feedback non possono essere ignorati. Nella costruzione della cattedrale gli stakeholder erano tanti. Vi erano i potenti (la Chiesa, il governo locale), il committente (che poteva essere distinto in ideatore e finanziatore o essere unico), vi era l’architetto, vi erano le maestranze organizzate (gli artigiani) e il popolo. Il popolo rientrava in diversi modi: partecipando ai lavori, fruendo della cattedrale finita e a volte finanziando in modo importante la costruzione (si veda la cattedrale di S. Maria del Mar a Barcellona).

Qui vorrei enfatizzare il ruolo delle maestranze. Nulla di più lontano dell’idea tayloristica del lavoro organizzato scientificamente, dove qualcuno decide e gli operai eseguono. Qui gli artigiani sono parte attiva. “La complessa tecnologia dell’architettura romanica deriva quindi da una serie di invenzioni e soluzioni di problemi tecnici, per le quali è stata fondamentale la stretta collaborazione del magister murario con capimastri, muratori e operai. Il cantiere funziona come un lavoro di squadra, dove qualsiasi problema, una crepa, un crollo, un cedimento del terreno, viene di volta in volta affrontato, discusso e risolto, magari con soluzioni sperimentali. Individuato l’errore, la soluzione veniva trovata sfruttando tutte le competenze del team. In questo contesto, l’esperienza assume un’importanza fondamentale”^[4] . Questa importanza dell’artigiano (che si è persa durante l’industrializzazione) ha delle risonanze chiarissime con l’Agile, perché questa metodologia nasce proprio dagli sviluppatori, ossia gli artigiani di oggi: “Agile has its origins in the field, lead by programmers inspired by excellence in craftsmanship^[5].”

Insomma, anche la costruzione della cattedrale era governata da una sorta di “Consiglio di Elrond”, per rifarci ancora al metodo G.and.A.L.F., dove tutti erano non solo rappresentati ma erano parte attiva.

Leadership collaborativa e sul campo

L’architetto romanico non era un esperto o uno studioso distaccato. Era certamente un leader, ma un leader collaborativo e che si spendeva sul campo: “Lanfranco controllava tutte le fasi dei lavori. Ogni giorno riuniva i suoi collaboratori più stretti in un apposito locale, poi, fatto gettare a terra uno strato di gesso, disegnava con un bastone le basi dei pilastri e le forme delle strutture. Quindi venivano stabiliti i compiti di ognuno e si avviavano i lavori. Probabilmente le operazioni concrete richiedevano continue soluzioni, modifiche e aggiustamenti. Si seguivano quindi le idee-guida del magister, ma le decisioni venivano prese insieme.^[6]

Ci colpiscono qui due cose: la prima è che sembra si stia descrivendo uno stand-up meeting. La seconda è che emerge in modo interessante la figura dell’architetto medioevale. Come dice un altro autore: “Ruolo fondamentale e nuovo all’interno del cantiere è quello dell’Architetto da non intendersi in senso moderno, connotazione nata durante l’epoca rinascimentale. Le fonti dell’epoca lo indicano con il termine generico di magister, aedificator, fabricator, caput magister, artifex. La sua figura viene identificata con quella del costruttore, dell’abile capomastro nel quale l’attività manuale prevale su quella intellettuale teorico-progettuale.^[7]”

Non ricorda questo il principio “La compagnia dell’anello”? Il modello G.and.A.L.F. non solo definisce le strategie in modo collaborativo, ma condivide anche l’execution e parte con la Compagnia!

Così si governa l’execution

La fase di execution, che nel modello G.and.A.L.F. copre i principi dal 4 al 7, presenta nelle cattedrali romaniche una serie di temi molto interessanti per le analogie con il mondo Agile.

Innanzitutto anche gli architetti romanici partivano da un MVP, o Minimum Viable Product. “La cattedrale può sorgere porzione dopo porzione e la costruzione solitamente partiva dall’estremità dell’abside poiché spesso era necessario rendere subito praticabile al culto almeno il presbiterio”^[8]. Quindi se la funzionalità base della chiesa era poter praticare il culto, il primo passo era costruire l’abside e rilasciare il prodotto (MVP).

Un altro aspetto interessante è la capacità di adattarsi e di riciclare il materiale esistente. Le rovine delle civiltà precedenti (quella romana in particolare) vennero usate abbondantemente. Non si trattò però di un saccheggio sconsiderato. Il valore delle rovine romane era spesso quello di creare un legame simbolico con l’impero e la classicità. È questo che intendo quando dico che sarebbe meglio parlare di evoluzione e non di trasformazione digitale.

L’evoluzione mantiene un legame con il passato. La digital transformation, o ancora di più la digital disruption, rompono con il passato. È chiaro che anche in natura le disruption esistono, ma sono l’eccezione. La norma è l’evoluzione. Il cambiamento va accettato (“Non ci si può bagnare due volte nello stesso Brandivino”), ma accettarlo vuol dire anche inglobare il passato nel presente^[9].

Gli altri due spunti che si legano ai principi di G.and.A.L.F. sono relativi al ruolo del popolo e a quello delle maestranze. Ne abbiamo già accennato: il popolo era sia parte del processo di costruzione che destinatario. Si pensi a tutti gli affreschi e i cicli pittorici, che erano fatti proprio per educare il popolo che non sapeva leggere. Inoltre le maestranze, lo abbiamo visto, avevano un ruolo estremamente attivo nella costruzione e condividevano le decisioni con un buon livello di autonomia (“Principio Olistico: ogni membro della Compagnia è la Compagnia”).

Un metodo anti-gerarchico

Credo che fin qui siano emerse una serie di analogie interessanti tra il mondo Agile e i processi di costruzione delle chiese romaniche (e anche gotiche in verità). Se da un lato è stupefacente, dall’altro è anche comprensibile: in entrambi i modelli culturali sottostanti la voce di “chi fa” (le maestranze e gli sviluppatori) ha avuto un ruolo importante nel formare il metodo di lavoro.

Vista in questa prospettiva, l’organizzazione del lavoro come si vede in tante realtà, come le gerarchie soffocanti e la governance top down, sono un imbarbarimento rispetto all’eredità medioevale.

L’Agile, il Lean e il metodo G.and.A.L.F. ci riportano ad una metodologia più umanistica e realistica, legata ad un tempo dove il delirio di onnipotenza e la presunzione di poter prevedere e manipolare tutto non si era ancora insinuato nelle nostre menti. L’incertezza era pane quotidiano e su questo si misuravano i costruttori e le maestranze. Forse, come spesso è successo nella storia, dobbiamo guardare anche indietro per trovare ispirazione per costruire il nostro futuro. Soprattutto ora, nel momento in cui la nostra civiltà razionalista e tecnologica è stata travolta dal più prevedibile tra gli imprevisti, il che dovrebbe riportarci a un po’ più di umiltà e di concretezza (oltre che di agilità!).

__________________________________________________________________

1. Cantieri edili nel Medioevo
2. Relatio de innovatione ecclesiae Sancti Geminiani ac de transaltione eius beatissimi corporis (1106). Musei del Duomo, Modena.
3. Per altri riferimenti rispetto all’approccio basato su vision/goal: “EDGE: Value-Driven Digital Transformation” di Jim Highsmith (Autore), Linda Luu (Autore), David Robinson (Autore)
4. La cattedrale e il cantiere medievale
5. Agility as an Expression of Empiricism
6. I cantieri edili nel Medioevo
7. La cattedrale e il cantiere medievale
8. La cattedrale e il cantiere medievale
9. Digital transformation is a misnomer