Parte prima. Il treno che attraversa l'organizzazione
Cosa insegna la ferrovia a chi coordina molti team Agile
C'è un momento, nella vita di un'organizzazione che sta crescendo, in cui qualcuno si accorge che i team non si capiscono più. Erano cinque, sono diventati venti. Ciascuno lavora bene al proprio interno, ciascuno applica Scrum con diligenza, ciascuno consegna in tempo gli sprint pianificati. Eppure il prodotto, quello vero, quello che dovrebbe uscire dalla somma dei loro contributi, arriva sempre in ritardo, sempre incompleto, sempre con qualche pezzo che non combacia con gli altri. È il problema della scala, e ha la natura di certi paradossi antichi: ciò che rende Agile efficace quando si è in pochi è la stessa cosa che lo rende difficile quando si diventa molti.
La soluzione a questo paradosso, nella pratica delle grandi aziende, ha preso la forma di framework di coordinamento. Il più diffuso si chiama Scaled Agile Framework, SAFe per gli amici. Ha una concezione articolata, che copre dal singolo team fino al portafoglio strategico, e ha al proprio centro una metafora che vale la pena prendere sul serio: quella del treno. Perché un treno, a ben guardare, è esattamente ciò che serve quando molte persone devono muoversi insieme nella stessa direzione.
I binari
Prima del treno vengono i binari. Senza binari il treno non va da nessuna parte, o meglio, ci va una volta sola e male. I binari sono l'infrastruttura stabile che consente al treno di esistere, e nel linguaggio di SAFe corrispondono a quella che si chiama Agile Release Train, abbreviata in ART. Un ART è un'organizzazione virtuale permanente che riunisce i team necessari per sviluppare un flusso di valore, tipicamente da cinquanta a centocinquanta persone, distribuite in diversi team Scrum o Kanban che lavorano su porzioni complementari dello stesso prodotto.
La parola chiave, qui, è permanente. I binari non si smontano alla fine di ogni corsa. L'ART non è un gruppo di progetto che si forma per un obiettivo e si scioglie quando l'obiettivo è raggiunto. È una struttura stabile, che attraversa nel tempo molti programmi di lavoro, e la sua stabilità è precisamente ciò che consente alle persone di imparare a lavorare insieme, di sviluppare quella conoscenza tacita dei reciproci modi di fare che costituisce il capitale invisibile di ogni squadra affiatata. Un treno che deve posare i propri binari ogni mattina non è un treno: è un cantiere.
L'orario
Un treno ha un orario. Parte a un'ora precisa, arriva a un'ora precisa, ferma nelle stazioni intermedie a orari previsti. Questa cadenza non è un'imposizione burocratica, è la condizione perché molte persone possano contare sul treno e organizzare intorno a esso le proprie vite e i propri traffici. L'orario del treno, in SAFe, si chiama Program Increment, o PI. Dura tipicamente da otto a dodici settimane, e al suo interno contiene diversi sprint, da quattro a sei, che sono le fermate intermedie.
Qui il purista dell'agilità, quello che conosce a memoria il Manifesto del 2001, comincia a storcere il naso. Una cadenza fissa? Un orizzonte di dodici settimane? Non era Agile quella cosa che si adatta di continuo, che abbraccia il cambiamento, che rifugge le pianificazioni lunghe? La risposta, se la si vuole prendere sul serio, è che quando i passeggeri sono pochi si può viaggiare in taxi, adattando il percorso a ogni richiesta. Quando i passeggeri sono mille, senza orario non si viaggia affatto. Il PI è l'orario minimo indispensabile perché molte persone possano coordinarsi senza dover comunicare tutte con tutte, cosa che la matematica, prima ancora dell'esperienza, dimostra impossibile oltre una certa soglia.
La riunione del personale della stazione
Esiste, nella vita del treno SAFe, un evento che riunisce l'intero equipaggio prima di ogni partenza. Si chiama PI Planning, dura due giorni interi, e vi partecipano tutte le persone dell'ART, macchinisti e controllori, capotreno e personale di bordo, insieme ai rappresentanti dei passeggeri che hanno qualcosa da dire sul viaggio che stanno per intraprendere. È l'evento essenziale di SAFe, quello senza il quale il framework perde la propria ragione di esistere.
Durante questi due giorni accadono cose che, a guardarle da fuori, possono sembrare inefficienti. Cento persone in una sala, o in molte sale collegate da videoconferenza, che discutono, negoziano, annotano, si spostano fra gruppi, tornano in plenaria. Eppure ciò che si costruisce in quelle ore ha un valore che nessun'altra forma di coordinamento può produrre. Ciascun team esce dal PI Planning sapendo cosa farà nelle settimane successive, sapendo cosa faranno gli altri team, sapendo dove si trovano le dipendenze che potrebbero bloccarlo o che lui stesso potrebbe causare ad altri, sapendo quali rischi sono stati riconosciuti e quali persone sono state incaricate di presidiarli. Il PI Planning, in altre parole, sostituisce molte settimane di email, riunioni bilaterali, fraintendimenti e scoperte tardive, con due giorni di lavoro collettivo esplicito.
Perché questo lavoro collettivo produca davvero il suo frutto, devono esistere tre condizioni. La prima è la presenza fisica, o virtuale ma effettiva, di chi può prendere decisioni. Un PI Planning in cui mancano le persone che sciolgono i nodi produce piani pieni di clausole sospensive, piani che diventano carta straccia il giorno dopo. La seconda è la qualità della preparazione, perché due giorni non bastano se il lavoro di raffinamento del backlog non è stato fatto nelle settimane precedenti. La terza, che è il punto dove la metodologia incontra la tecnologia, è la disponibilità di uno strumento che renda visibile a tutti, in tempo reale, il piano che sta emergendo.
I semafori e gli scambi
Un treno che circola ha bisogno di sapere, in ogni momento, dove si trovano gli altri treni, quali segnali sta incontrando, quali scambi lo attendono alle biforcazioni. In una rete ferroviaria moderna questa informazione passa attraverso un sistema di controllo centralizzato che vede l'intera rete contemporaneamente. Il corrispettivo, nella gestione di un ART, è uno strumento di portafoglio che consenta di visualizzare insieme tutti i team, tutti gli sprint, tutte le dipendenze, e di aggiornare questa visualizzazione man mano che il lavoro procede.
Esistono diversi strumenti che assolvono questa funzione, con gradi diversi di sofisticazione. Uno di quelli che ho visto funzionare con maggiore efficacia è BigPicture, un'applicazione che si installa sopra Jira e ne estende le capacità nella direzione del portafoglio. La sua concezione è organizzata attorno a strutture gerarchiche chiamate Box, che si prestano bene a rappresentare l'annidamento tipico di un ART: il Box di livello superiore corrisponde al Program Increment nel suo insieme, i Box figli corrispondono ai singoli team, le issue contenute in ciascun Box sono le attività assegnate al team per quel PI, organizzate per sprint. Il modulo Gantt rende visibile tutto questo sulla stessa timeline, con le dipendenze inter-team tracciate come frecce che collegano attività di team diversi.
Lo strumento, beninteso, non sostituisce il giudizio. Un PI Planning condotto con post-it su una parete fisica funziona, e ha il pregio della tattilità che certe forme digitali hanno difficoltà a replicare. Ma i post-it non lanciano alert quando una dipendenza viene violata, le fotografie della parete diventano obsolete nel giro di pochi giorni, e soprattutto la parete fisica è inutilizzabile quando i team sono distribuiti in paesi diversi, come accade ormai nella maggior parte dei programmi di una certa dimensione. Lo strumento digitale non è il cuore del PI Planning: il cuore sono le persone che si parlano. Lo strumento è il sistema nervoso che trasmette gli impulsi dopo che le persone hanno finito di parlare, e li trasmette in modo che restino leggibili quando il PI sarà finito e ne comincerà uno nuovo.
Il viaggio
Il piano costruito durante il PI Planning è una previsione, e come ogni previsione incontra la realtà nei giorni successivi. Alcune attività si riveleranno più semplici del previsto, altre più complesse. Qualche dipendenza emergerà che non era stata identificata. Un rischio si materializzerà, un altro si dissolverà senza conseguenze. Il viaggio del treno, insomma, non sarà mai identico all'orario stampato alla partenza.
La qualità di un sistema di coordinamento non si misura dalla capacità di prevedere perfettamente, che è impossibile, ma dalla capacità di osservare gli scostamenti mentre si verificano e di reagire prima che diventino irreparabili. In SAFe questo accade attraverso cerimonie ricorrenti, la sincronizzazione settimanale dell'ART, le demo di sistema al termine di ogni sprint, l'Inspect and Adapt che chiude il PI e prepara il successivo. Uno strumento di portafoglio ben configurato fornisce a ciascuna di queste cerimonie il substrato informativo necessario: dove siamo rispetto alla baseline fissata al PI Planning, quali team sono in ritardo, quali feature rischiano di non entrare nel PI, quali dipendenze sono in sofferenza.
Il capotreno
In ogni ART esiste una figura che corrisponde al capotreno, e si chiama Release Train Engineer. Non è un capo gerarchico, non decide le priorità del prodotto, non sostituisce i Product Owner dei singoli team. Il suo compito è quello, apparentemente modesto e in realtà essenziale, di fare in modo che il treno proceda. Sblocca i nodi, facilita le cerimonie, rende visibili i rischi, mantiene la conversazione aperta fra i team che altrimenti tenderebbero a chiudersi ciascuno nel proprio Box. È una figura che nel nostro paese ha avuto una diffusione relativamente lenta, probabilmente perché l'organigramma italiano fatica a riconoscere ruoli che non coincidono con un'autorità formale. Eppure è proprio in quell'interstizio fra autorità e responsabilità che si gioca gran parte della riuscita di un ART.
Arrivare a destinazione
Torno al paradosso da cui sono partito. Agile funziona bene quando si è in pochi perché la comunicazione diretta è sufficiente a coordinare il lavoro. Quando si diventa molti, la comunicazione diretta non basta più, e serve una struttura che la sostituisca almeno in parte. Questa struttura rischia di tradire i princìpi dell'agilità, ed è una preoccupazione legittima. Ma c'è una differenza fra tradire i princìpi e adattarli alla scala, e la differenza si vede nei risultati: un'organizzazione che rinuncia a scalare perché teme di perdere l'agilità è un'organizzazione che ha scelto di restare piccola, cosa rispettabile ma spesso non compatibile con gli obiettivi che si è data.
Il Program Increment è il punto in cui l'agilità del singolo team e la disciplina della governance di portafoglio trovano il loro equilibrio. Il PI Planning è il rito che inaugura questo equilibrio, e lo strumento di monitoraggio è ciò che lo mantiene nelle settimane successive. I binari restano quelli posati durante la pianificazione. Il compito di chi governa il programma, giorno dopo giorno, è verificare che il treno vi stia transitando. E, quando scopre che ne è uscito, riportarcelo sopra prima che la prossima stazione diventi irraggiungibile.
Parte seconda. Il panettiere e il pasticcere
Cosa distingue la formazione vera dalla carta stampata
C'è un aneddoto che i vecchi panettieri di Altamura raccontano agli apprendisti, quando vogliono spiegare la differenza fra chi conosce il pane e chi ne ha solo letto la ricetta. Il pane buono, dicono, non si fa leggendo il manuale. Si fa sentendo la pasta sotto le mani, riconoscendo al tatto quando la maglia glutinica ha raggiunto il punto giusto, capendo dall'odore se il lievito sta lavorando come deve. Il manuale serve, certo, ma è uno strumento secondario: chi sa fare il pane potrebbe averne anche fatto a meno, mentre chi il pane non lo sa fare troverà nel manuale soltanto una serie di istruzioni che non sa come eseguire. Il manuale, in altre parole, certifica una competenza che esiste indipendentemente da esso, non la produce.
Questo aneddoto, apparentemente lontano dal nostro mestiere, dice qualcosa di essenziale sulla formazione Agile nel paese dove viviamo. Perché in Italia, negli ultimi quindici anni, si è consolidato un mercato della certificazione che ha molti dei caratteri della pasticceria industriale travestita da artigianato. I biscotti arrivano in vassoi dorati, avvolti in carta velina, legati con nastri di raso. Il prezzo è quello dei prodotti d'eccellenza. L'etichetta promette ingredienti nobili e lavorazioni antiche. Ma se si guarda oltre la confezione, se si morde davvero il biscotto, spesso si scopre che l'impasto è quello standardizzato dei grandi laboratori di distribuzione, che gli ingredienti dichiarati sono presenti in tracce minime, e che la vera differenza fra un biscotto e l'altro sta nella grammatura del pacchetto e nella serigrafia della scatola.
I corsi di certificazione
La forma tipica dell'offerta, in questo mercato, è il corso di due giorni seguito dall'esame. Due giorni in cui un istruttore, a sua volta certificato, espone il corpus dottrinario della scuola alla quale appartiene, proiettando slide che sono state prodotte centralmente dall'ente certificatore e che l'istruttore non ha il potere di modificare. Alla fine dei due giorni il partecipante sostiene un test a risposta multipla, costruito per essere superato dalla maggior parte di coloro che hanno seguito il corso con attenzione, e riceve un attestato che certifica la sua padronanza di una metodologia che, nella maggior parte dei casi, non ha mai visto applicare in un'organizzazione reale.
Il problema non è il formato in sé. Due giorni possono essere sufficienti per trasmettere le basi di un metodo, se i partecipanti arrivano con un contesto di esperienza che consente loro di collocare quelle basi in una mappa cognitiva già popolata di casi concreti. Il problema è che il mercato italiano, per ragioni che hanno a che fare con la domanda aziendale di credenziali formali più che con la domanda individuale di competenza, ha generato una popolazione di certificati il cui rapporto con la pratica dell'Agile è analogo al rapporto fra un sommelier diplomato in un corso di fine settimana e una cantina vera. Si conoscono i nomi dei vitigni, si sa declamare il vocabolario della degustazione, ma non si è mai vissuto il ciclo completo di una vendemmia, non si sono commessi gli errori che insegnano, non si è sviluppato quel giudizio che nasce soltanto dalla ripetizione e dal confronto.
La fragranza ingannevole del packaging
Chi acquista oggi una certificazione Agile in Italia compra, nella maggior parte dei casi, tre cose insieme. La prima è un contenuto didattico, ed è la componente meno preziosa del pacchetto, perché gli stessi contenuti sono disponibili gratuitamente in manuali, articoli, video e repository pubblici, spesso in forma più approfondita di quanto due giorni di corso possano offrire. La seconda è un segnale, un marchio che il partecipante potrà esibire sul proprio profilo professionale per superare i filtri automatici dei software di selezione del personale, i quali cercano acronimi e non competenze. La terza, quella di cui si parla poco, è l'iscrizione a un ecosistema che richiede rinnovi periodici, crediti formativi continui, partecipazione a eventi della comunità, e che nel corso di una carriera può assorbire cifre considerevoli senza che la competenza effettiva del professionista sia minimamente aumentata rispetto al giorno del primo attestato.
Il meccanismo ha una sua coerenza interna. L'ente certificatore vende la credenziale iniziale, poi vende il rinnovo, poi vende i corsi di specializzazione che consentono di ottenere credenziali di livello superiore, poi vende il percorso che consente di diventare istruttori autorizzati, e ciascun istruttore, una volta autorizzato, diventa a sua volta un canale di diffusione dei contenuti dell'ente. È un modello di business auto-alimentato, in cui la domanda di formazione viene sostenuta dalla percezione diffusa che le credenziali significhino qualcosa, e questa percezione viene a sua volta rafforzata dalla presenza delle credenziali nei profili professionali che compongono il mercato. Il giorno in cui i processi di selezione cominciassero a dare lo stesso peso al racconto di un'esperienza reale rispetto all'elenco degli attestati, l'equilibrio del sistema si sposterebbe sensibilmente.
Cosa insegna davvero l'Agile
Vale la pena, a questo punto, ricordare cosa Agile insegna realmente, perché il contrasto con ciò che le certificazioni misurano diventi visibile. Agile insegna a consegnare valore frequentemente, ricevendo feedback dall'utente e incorporandolo nel ciclo successivo. Insegna a trattare il piano come un'ipotesi da verificare, non come un contratto da eseguire. Insegna a privilegiare le conversazioni dirette fra persone rispetto alla documentazione formale, senza per questo abolire la documentazione. Insegna a costruire squadre che possiedano collettivamente la competenza necessaria per portare a termine il lavoro, riducendo le dipendenze da specialisti esterni che generano attese e colli di bottiglia. Insegna, soprattutto, una postura mentale: quella di chi accetta che la conoscenza emerga progressivamente dal lavoro stesso, e che la pianificazione dettagliata di qualcosa che non si conosce sia una forma di autoinganno costoso.
Nessuna di queste cose si impara in due giorni. Si impara osservando un team che le pratica, partecipando alle sue cerimonie, vedendo come reagisce quando qualcosa va storto, notando quali conflitti emergono e come vengono gestiti, verificando sulla propria pelle che un Daily Standup di venti minuti non serve a nessuno e che uno Sprint Review senza utenti veri diventa una liturgia autoreferenziale. Si impara, in altre parole, dentro il pane che lievita, non dentro il manuale che lo descrive.
Il riconoscimento del panettiere
Come si riconosce, allora, un formatore che sappia davvero fare il pane? Alcuni indizi aiutano. Il primo è la quantità di ore che ha dedicato non alla docenza, ma alla pratica operativa dentro organizzazioni che hanno applicato l'Agile sul serio. Un formatore che abbia accumulato molte ore in aula ma poche sul campo rischia di trasmettere contenuti che non ha mai verificato al contatto con la complessità reale, per quanto sia abile nell'esposizione. Il secondo è la sua capacità di raccontare casi concreti con i loro dettagli sporchi, i compromessi accettati, gli errori commessi, le resistenze incontrate nei contesti aziendali reali. Un formatore che parla soltanto in astratto, ricorrendo ogni volta al caso ideale descritto nei manuali, è un formatore che di quei manuali non è mai uscito. Il terzo è il suo rapporto con le tensioni interne all'Agile stesso, con le critiche che alcuni dei padri fondatori hanno mosso alla deriva industriale dei loro stessi metodi, con le zone in cui il metodo non funziona o funziona soltanto a patto di adattamenti pesanti. Un formatore che presenta la propria scuola come coerente, completa e priva di tensioni sta semplificando oltre ciò che il campo consente.
Il quarto indizio, più sottile, riguarda il suo atteggiamento verso la certificazione stessa. Un formatore consapevole dirà al corsista che l'attestato che sta per ricevere è una soglia di ingresso, non una destinazione, e che il lavoro vero comincia il lunedì successivo al corso, quando dovrà applicare in un contesto ostile e imperfetto princìpi che in aula sembravano cristallini. Chi invece presenta l'attestato come un traguardo, suggerendo che il partecipante è ora in grado di entrare in un'azienda e trasformarla, sta compiendo un'operazione commercialmente comprensibile ma didatticamente fragile. Il primo approccio lascerà il corsista più umile di quando è entrato, il secondo più sicuro di sé di quanto l'esperienza reale giustifichi.
Il lascito che conta
Scrivo queste righe sapendo che non saranno gradite a tutti. Il mercato della formazione Agile in Italia dà da vivere a molte persone, alcune delle quali sono miei colleghi e amici, e il mio obiettivo non è togliere pane dalla tavola di chi lavora onestamente dentro questo sistema. È piuttosto quello di offrire, a chi oggi si affaccia al mondo dell'Agile per la prima volta, una mappa che gli consenta di distinguere i prodotti di pasticceria industriale dalla panificazione vera, le confezioni dorate dal pane di Altamura, gli istruttori che ripetono slide altrui dai maestri che hanno impastato per decenni.
Il consiglio pratico, per chi comincia, è semplice. Prima di spendere duemila euro in un corso di certificazione, spendete duecento euro in un buon manuale, leggetelo con attenzione, e poi cercate un'organizzazione che applichi l'Agile davvero e chiedete di osservarla al lavoro anche solo per qualche giornata. Se ciò che vedete vi conferma quanto avete letto, allora il corso di certificazione può avere un senso, perché avrete un contesto mentale in cui collocarlo. Se ciò che vedete smentisce quanto avete letto, avrete imparato la cosa più importante che un professionista dell'Agile può imparare: che la realtà delle organizzazioni è sempre più complessa della teoria, e che il giudizio professionale consiste precisamente nel sapere navigare questa complessità senza tradire i princìpi e senza applicarli in modo meccanico.
Il pane buono, alla fine, si riconosce al morso. E nessuna carta velina dorata, nessun nastro di raso, nessuna serigrafia elegante può sostituire quel morso. I biscotti di alta pasticceria dalle confezioni perfette, quelli che troviamo nelle vetrine dei negozi eleganti, non sempre sono i biscotti migliori. I biscotti migliori, spesso, li fa una signora in una cucina di paese, con una ricetta che le ha insegnato sua nonna e che non ha mai messo per iscritto. Il nostro compito, come lascito a chi viene dopo di noi, è insegnargli a riconoscere quella signora quando la incontra, e a valutare con spirito critico i vassoi dorati che gli verranno offerti come alternativa.