Articolo pubblicato in anteprima su AgendaDigitale.eu
“To be, or not to be, that is the question:
Whether ‘tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles
And by opposing end them?”[1]
Shakespeare aveva già capito tutto. E il suo Amleto ha ben rappresentato il dilemma dei leader digitali di oggi. Parafrasando: di fronte alla mutevolezza della vita, è meglio adattarsi senza opporre resistenza o lottare per controllare e arginare il cambiamento? Il primo approccio ricalca l’empirismo e lo spirito di adattamento dei framework agili, il secondo il razionalismo e l’approccio direttivo delle metodologie tradizionali o waterfall.
Dunque è meglio essere agili o il suo contrario? Si noti bene che il contrario di agile, secondo uno dei tanti dizionari dei contrari, è “lento, pesante, rigido, impacciato, stupido, ottuso”.
Posta così, chi non vorrebbe essere agile? Dilemma risolto? Non proprio. Infatti l’approccio agile è indubitabilmente un’evoluzione importante rispetto agli approcci più tradizionali, ma la potenza di questi strumenti va valutata attentamente nel contesto di applicazione. In particolare i framework agili sono semplici da comprendere, ma difficili da mettere in pratica e devono essere valutati rispetto a due domande:
- C’è un reale valore nell’adattarsi al cambiamento in modo continuo e nel non definire i requisiti a priori? Così come nell’ambito della conoscenza vale il principio di parsimonia del Rasoio di Occam[2], così anche nella scelta di una metodologia va privilegiata quella più semplice in grado di raggiungere gli obiettivi. Le metodologie agili sono fondamentali in contesti in cui l’adattamento rapido è necessario e magari auspicabile e i requisiti non sono definibili a priori. Se sviluppo un nuovo portale di e-commerce, i requisiti verosimilmente non saranno tutti chiari all’inizio del percorso e devono poter cambiare durante lo sviluppo (e anche dopo) in base ai feedback degli utenti. Ma se invece dobbiamo costruire un ponte, il cambiamento continuo dei requisiti è davvero un valore? Anche nel campo dei progetti software, è innegabile che in alcuni contesti (pensiamo ad un software di contabilità, di gestione delle buste paga o di calcolo delle tasse universitarie) ci si aspetti una definizione abbastanza precisa dei requisiti all’inizio e poca flessibilità in corso d’opera. Casi tipici in cui un approccio tradizionale o waterfall è più adatto di uno agile.
- Il team ha la maturità necessaria a lavorare in modo agile? Questo è un punto cruciale. Il mondo Agile ha una caratteristica: tanto è semplice da capire e da condividere quanto è complesso da implementare. L’Agile manifesto è generalmente compreso e condiviso da tutti coloro che lo leggono. La SCRUM Guide recita: “SCRUM is simple to understand, difficult to master”[3]. Quel “difficult to master” nasconde spesso il tema della maturità del team. Per lavorare in modo agile, il team deve avere una capacità di collaborazione interna (tra i membri del team stesso) ma anche esterna (con gli altri team) notevole. Ci sono molti modi per valutare questi aspetti, tra i quali quello proposto da D. Logan in “Tribal Leadership”[4] e quello di F. Laloux in “Reinventing Organizations”[5]. Secondo il modello di Logan, solo ai livelli 4 e 5 i team riescono a collaborare in modo pieno sia al loro interno che con altri team e altre organizzazioni. Dagli studi di Logan sembra che meno di un terzo delle organizzazioni sia a livello 4 o 5. Se guardiamo al modello di Laloux invece, i livelli sono sempre 5 ma divisi per colori: Red, Amber, Orange, Green, Teal (verde acqua). Secondo alcuni autori[6], anche in questo caso solo gli ultimi due livelli di maturità (Green e Teal) si allineano bene con il contesto agile. Neanche a dirlo, le organizzazioni Green e Teal sono una minoranza del totale.
È quindi chiaro che Agile, per quanto affascinante come modalità di lavoro, richiede che ci sia un valore nell’agilità e che ci siano le condizioni culturali adatte. Altrimenti si rischiano dolorosi fallimenti o, il che forse è ancora peggio, “eresie” in cui si chiama agile ciò che con l’agile centra davvero poco. Perché se l’agilità diventa un’ideologia e una fede cieca, contraddice sé stessa negando i principi dell’empirismo a cui si ispira. Si può provare a rappresentare in un grafico quanto descritto sopra:
Che fare allora, arrendersi e continuare ad usare i “vecchi” strumenti metodologici, con tutti i loro limiti noti, lasciando l’”agile mindset” ai pochi eletti che hanno organizzazioni mature? È come dire che abbiamo trovato una fonte di buon cibo, ma non possiamo darlo agli affamati, perché si ingozzerebbero e sporcherebbero tutto. Lo riserviamo invece a quei ricchi che hanno buone maniere ed educazione di eccellenza. Un paradosso inaccettabile.
D’altro canto ci sono evidenze anche empiriche (chi ha provato ad applicare l’agile lo sa) che i team meno collaborativi rappresentati più a sinistra (diciamo i livelli 1-2 di Logan o Red/Amber di Laloux) difficilmente riusciranno a trarre profitto da queste metodologie. Però se è vero che i team più collaborativi sono pochi, questo è anche vero per quelli meno collaborativi. La grande maggioranza delle aziende e delle organizzazioni sta nel mezzo, diciamo dal livello 2,5 al livello 3,5 di Logan. E qui si apre una finestra di opportunità per far evolvere l’organizzazione.
Come? Non c’è una risposta univoca, ma nella mia esperienza la “manovra a tenaglia” (per dirla alla Tenet[7]) è quella che ha maggiori probabilità di successo. Ossia da un lato si usano metodologie di tipo agile, introducendo cerimonie, valori comuni, modalità che “forzano” la comunicazione e la collaborazione. Ad esempio alcuni esperti di agilità sostengono che le “user story” non siano altro che “pretesti per comunicare”. E il mondo agile fornisce tanti pretesti per favorire la comunicazione, la collaborazione e la trasparenza.
Accanto a questo approccio sul metodo, deve esserci però un percorso di crescita psicologica e relazionale sia singoli che dei team. Sia sulla parte metodologica che su quella relazionale è fondamentale un aspetto di formazione ma anche di coaching sul campo. Ad esempio lo “shadow coach”, ossia un esperto che in modo silente partecipa ai meeting e poi aiuta il team a “leggere” cosa è andato bene e cosa no, è un’arma potentissima. Ci sono poi tanti altri modi per apportare alla cultura aziendale miglioramenti incrementali e continui aumentandone la capacità di collaborazione. Stiamo parlando di Change Management? Non proprio, piuttosto questo è solo un accenno ad un tema vastissimo e affasciante, che va sotto il nome di Culture Hacking, a cui dovremo dedicare un altro approfondimento.
[1] “Essere, o non essere, questo è il dilemma:
se sia più nobile nella mente soffrire
colpi di fionda e dardi d’oltraggiosa fortuna
o prender armi contro un mare d’affanni
e, opponendosi, por loro fine?”
[2] La formulazione originale è: “«frustra fit per plura quod potest fieri per pauciora», ossia: «è futile fare con più mezzi ciò che si può fare con meno». Normalmente viene divulgato come: “A parità di fattori la spiegazione più semplice è da preferire»
[3] “SCRUM è semplice da capire, difficile da padroneggiare” (TdA)
[4] https://www.triballeadership.net/
[5] https://en.wikipedia.org/wiki/Teal_organisation
[6] “An Executive Guide to Disciplined Agile” – S.W. Ambler and M. Lines