Essere o non essere agili? Quando e perché applicare la metodologia agile

Di fronte ai cambiamenti 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 della metodologia agile, il secondo il razionalismo e l’approccio direttivo delle metodologie tradizionali o waterfall. Shakespeare aveva già capito tutto. E il suo Amleto ha ben rappresentato il dilemma dei leader digitali di oggi. È meglio essere agili o il suo contrario?

Il contrario di agile, secondo uno dei tanti dizionari dei contrari, è “lento, pesante, rigido, impacciato, stupido, ottuso”.

Posta così, chi non vorrebbe essere agile? La metodologia agile è senza dubbio un’evoluzione importante rispetto agli approcci più tradizionali, ma la potenza di questi strumenti va valutata attentamente nel contesto di applicazione.

Lavoro agile: quale modello culturale per i massimi benefici

La metodologia agile alla prova del contesto

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^[1], 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 è semplice da capire, difficile da padroneggiare”. Quel “difficile da padroneggiare” nasconde spesso il tema della maturità del team. Per lavorare in modo agile, il team deve avere una capacità di collaborazione notevole, sia interna che esterna. Ci sono molti modi per valutare questi aspetti, tra i quali quello proposto da D. Logan in “Tribal Leadership”^[2] e quello di F. Laloux in “Reinventing Organizations”^[3]. Secondo il modello di Logan, solo ai livelli 4 e 5 i team riescono a collaboare 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^[4], 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 la metodologia 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:

Come far evolvere le organizzazioni non mature?

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 (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 con il film “Tenet“) è 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.

Note

1. 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”. ↑
2. https://www.triballeadership.net/ ↑
3. https://en.wikipedia.org/wiki/Teal_organisation ↑
4. “An Executive Guide to Disciplined Agile” – S.W. Ambler and M. Lines ↑