I come e i perché di questo articolo

Sono ormai quattro anni che vivo e lavoro in pianta stabile a Londra. Svolgo attività di Agile Coach e l’ho fatto in quattro diverse aziende. Con questo articolo, ho sentito il bisogno di ricapitolare alcuni punti salienti di questa esperienza e di condividerli con i lettori.

Ovviamente mi sono posto la domanda: “Ma interesserà a qualcuno?”; senza false modestie, mi sono risposto che sicuramente ci sarebbero stati vari appartenenti alla comunità agile italiana interessati al modo in cui la mentalità Agile viene adottata nel Regno Unito prossimo alla Brexit; e che, oltre a loro, queste note avrebbero potuto fornire qualche informazione in più a chi, eventualmente, stesse pensando di trasferirsi nel Regno Unito per lavorare in questo ambito.

Disclaimer

Ovviamente questo articolo riflette la mia esperienza e contiene anche opinioni personali: magari ci saranno persone con un percorso in qualche modo sovrapponibile al mio che si saranno fatta tutt’altra idea; e questo è normalissimo. D’altro canto, le opinioni cambiano: ogni giorno imparo qualcosa, incontro team e sfide diverse e potrei anche cambiare idea da qui a un anno. Del resto, questa capacità di adattarsi non è essa stessa parte dell’essere Agile?

L’angolo della curiosità

Come leggerete, poi, ho inserito qua e là un “angolo delle curiosità” in cui, in modo scherzoso, parlo di alcuni “luoghi comuni” legati alle differenze culturali e di abitudini tra il mondo britannico e quello italiano.

Per esempio, l’annosa questione del bidet è meno scontata di quanto si possa pensare: i Britannici — almeno coloro con cui ne ho parlato — lo considerano anti-igienico. Personalmente, dopo quattro anni, continuo a essere perplesso sulla sua mancanza…

A che punto siamo con l’Agile?

Cominciamo le nostre riflessioni con questo interrogativo? Come siamo messi con l’adozione di principi e pratiche agili nell’ambito delle aziende britanniche?

I’m in your waterfall

Una canzone [1] recente recitava:

I’m in your waterfall […]

I’m in the jungle now […]

I’ve lost control […]

Francamente sono rimasto un po’ sorpreso nello scoprire che tante aziende ancora lavorano con un approccio waterfall, o che hanno intrapreso una trasformazione in senso agile ma magari non l’hanno completata, e questo magari non solo per una volta.

Dalla pubblicazione del Manifesto Agile [2] sono pasati ormai 17 anni e facciamo ancora fatica a comprendere o ad aderire ad alcuni dei suoi principi base.

Quasi la totalità delle persone che ho intervistato nel mio ruolo di responsabile delle assunzioni o con le quali ho lavorato ad altro titolo non aveva mai letto il Manifesto Agile o la Scrum Guide. Però in tutte le aziende vi assicureranno che “Certo che stiamo facendo Agile, per esempio gli standup e quelle cose lì…”.

Silos e divisioni

Altro fatto che ho riscontrato è che esistono tuttora molti silos: grafici, sviluppatori, tester, progettisti… e poi front end, back end e così via. Va anche detto che ho visto svolgere tanto lavoro per tentare di rompere questi “compartimenti stagni”. Personalmente in questi anni ho dato il mio contributo in tal senso, a volte con grandi successi, altre con delle cocenti sconfitte.

La sindrome delle Squad

Londra sembra essere vittima dell’incantesimo del “modello Spotify” basato sulle Squad. Il fatto è che le Spotify Squads… non sono un modello: in Spotify hanno analizzato le loro sfide e si sono inventati un modo per risolverle che funzionasse bene per loro. Insomma, il principio Inspect & Adapt messo in pratica.

Putroppo, però, ho visto situazioni in cui questa soluzione è stata applicata in maniera acritica con una sorta di imposizione dall’alto: poco importava che le cosiddette cross-functional squads poi non fossero affatto crossfunzionali — le persone non lavoravano mai fuori dalla loro comfort zone — e, soprattutto, che il “modello Spotify” non stesse risolvendo i problemi di un’altra azienda che non era Spotify…

Agile resta confinato nei team di sviluppo

Un altro aspetto che ho riscontrato nella mia esperienza è stato il seguente: anche quando un framework Agile era stato positivamente adottato nei gruppi di sviluppo, la mentalità Agile aveva comunque difficoltà a diffondersi in altre aree delle organizzazioni.

A fronte di Dev Teams autenticamente agilizzati, ci si trova in presenza di:

• un’area Product in cui i Product Owner si comportano ancora come Product Manager classici, assegnando il lavoro da fare ai membri dei team di sviluppo secondo pianificazioni rigide e richiedendo il rispetto di scadenze decise a priori senza peraltro ancora conoscere bene il prodotto che si andrà a realizzare;
• un’area HR isolata dal resto dell’organizzazione e non sintonizzata con il modo in cui realmente si lavora in sviluppo; questo causa a volte incomprensione degli obiettivi che meglio funzionano per un team agile, e sperequazioni nel modo in cui le persone vengono ricompensate; tipicamente c’è un contrasto tra valutazione delle performance personali vs. performance di squadra, singolo indicatore di feedback vs. feedback ad ampio raggio, valutazione generale annuale a scadenza vs. feedback continuo.

Scrum? Si, ma…

Altro tipico comportamento disfunzionale che ho potuto riscontrare è quello dello “Scrum? Sì, ma…”, che di solito si esplica nella frase: “Usiamo Scrum, ma…”

• …non abbiamo uno Scrum Master.
• …non facciamo retrospettive.
• …non completiamo mai il lavoro in uno sprint
• …lavoriamo in silos isolati.
• …[aggiungere un “ma” a piacere].

Ciò che ho potuto vedere in molte occasioni è che Scrum viene modificato ancor prima di aver compreso le ragioni di alcune sue regole. Per quanto sia favorevole a modificare ciò che non funziona nel proprio peculiare contesto, e anche a tentare soluzioni in cui si mescolano elementi diversi, questo andrebbe fatto solo quando si comprende perfettamente quel che si sta facendo. Il grande chef è in grado di inventare un nuovo piatto, ma i semplici appassionati di cucina fanno meglio a seguire delle ottime ricette…

L’angolo della curiosità

Nella cultura britannica, soffiarsi il naso con il fazzoletto è considerato un gesto piuttosto rozzo; starnutire va invece bene. Per gli italiani, manco a dirlo, vale il contrario…

Scrum è obsoleto. Passiamo a Kanban!

In tutte le realtà in cui ho lavorato, prima o poi è capitato di sentir dire “Passiamo a Kanban!”. Alla domanda “E perché?”, le risposte sono state, senza alcun particolare ordine:

• “Perché Scrum prevede troppi incontri fra i partecipanti”.
• “Perché Kanban è più veloce”.
• “Perché desideriamo aggiungere materiale a metà di uno Sprint”.
• “Perché Kanban è più facile, dal momento che ha meno regole e meno ruoli”.

In quasi tutti i casi, ho visto questi team andare incontro a fallimenti e tornare a Scrum, peraltro non senza che l’esperienza negativa avesse fatto loro maturare un certo cinismo e una insoddisfazione generale nei confronti di Agile. Sì, lo so che tecnicamente il kanban di ascendenza Toyota Production System non può essere considerato propriamente come appartenente alll’ambito Agile, ma il Kanban riferito allo sviluppo software chiaramente lo è…

Anche in questo caso sembra di poter riscontare come il pensiero critico si perda per strada e come il pragmatismo che tanto apprezzo nella cultura inglese finisca a volte per ridursi al suo solo lato oscuro: “Bene… basta copiare qualcosa che già è stato fatto da altri”.

“Agile qualcosa”

I ruoli presenti nelle pratiche agili possono spesso ingenerare confusione: Agile Coach, Scrum Master, Agile Delivery Manager, Agile Process Manager, Agile Project Manager e così via.

Per individuare figure di questo tipo qualitativamente valide, le aziende di ricerca e selezione del personale si trovano quindi in difficoltà ancor più di quanto avvenga con altri ruoli più tecnici.

Eccellenza tecnica

Sul piano delle pratiche ingegneristiche ho avuto molte esperienze positive: nella maggior parte dei team ho potuto riscontrare la sincera volontà di scrivere codice di qualità e di seguire le pratiche tecniche che aiutano a farlo, quali TDD e pair programming.

Gli sviluppatori hanno reale passione per le architetture “pulite” e si impegnano fortemente nell’imparare e adottare le migliori soluzioni tecniche. L’automazione di varie attività del processo sta conoscendo un’adozione sempre maggiore, e il ruolo del tester sta cambiando costantemente per diventare sempre più tecnico, creando una figura campione di qualità che innalza l’asticella dell’eccellenza.

Si comincia a pensare alla qualità fin da subito, con l’obiettivo di prevenire i bug piuttosto che doverli individuare in un secondo tempo. Ad ogni modo, “debito tecnico” è un’espressione che si sente almeno una volta al giorno in tutti i team con cui ho avuto a che fare.

L’angolo della curiosità

La “pasta all’Alfredo”, il pollo nella pasta o l’ananas sulla pizza vi fanno storcere il naso? Per i britannici siamo i soliti italiani di gusti troppo difficili…

La comunità Agile

Su questo piano, la più grande città di Albione offre il suo meglio: le opportunità di imparare e fare rete sono infinite. Meetup, conferenze e ogni sorta di eventi fanno incontrare i grandi nomi internazionali: queste occasioni si rivelano melting pot di esperienze, comprensione e conoscenza.

L’angolo della curiosità

Non sono stato in grado di spiegare ai miei colleghi inglesi perché sia quantomeno strano, in Italia, bere un cappuccino dopo le 11:30 del mattino. Ma anche loro hanno avuto difficoltà a spiegarmi il perché sia impossibile trovare e mangiare carne equina, adducendo quella che per me è suonata come una scusa: “Sarebbe come mangiare un amico”.

La cultura

Non possiamo certo parlare di differenze abissali e inconciliabili tra la cultura italiana e quella britannica; non nel senso, perlomeno, di quelle che possono esistere con società molto più lontane, per distanza geografica e vissuto storico.

Tuttavia, le differenze esistono eccome e sarebbe sciocco non conoscerle e non tenerle presenti.

Gentilezza britannica

La famosa gentilezza britannica, che si esprime anche nel modo di dire certe cose, non è un mito, ma corrisponde a realtà.

A ciò è dovuta la difficoltà di capire, a volte, quale sia il reale significato dietro le parole pronunciate: quando ci si sente dire: “It is OK”, non si deve dare per scontato che significhi “Sì, va bene”, perché molto probabilmente significa “È un disastro”.

Se ci interessa dagli inglesi un feedback sincero e trasparente sul nostro lavoro, dobbiamo trovare un modo per andare oltre lo “schermo” rappresentato dalla loro genetica gentilezza.

Tempo e clima

E che dire dello stereotipo secondo il quale i britannici parlano così tanto del tempo atmosferico? Corrisponde assolutamente alla verità. Non sarebbe possibile alcuna conversazione in un ascensore se non si parlasse del meteo. Altro argomento che può parzialmente aiutare è il weekend con il classico “Progetti per il finesettimana?” di venerdì, e il canonico “Come è andato il finesettimana”, al lunedì…

O è troppo freddo, o fa troppo caldo, o piove troppo: siate preparati a usare questo “trucco” per avviare una conversazione o rompere il ghiaccio (forse è troppo freddo?).

Lavorare nell’IT a Londra

Buone notizie: lo sviluppatore, o chiunque sia in grado di ricoprire un qualche ruolo nell’Information Technology, troverà a Londra numerose opportunità di lavoro.

I professionisti dell’IT vengono tenuti in alta considerazione: le aziende cercheranno di attrarre i talenti migliori, e sono disposte a farlo anche con un gioco al rialzo per quel che riguarda stipendi, benefit e bonus vari. E anche questa è una differenza “culturale” con l’Italia, dove ci sono molte situazioni in cui sembra che l’azienda stia facendo un favore al professionista nel farlo lavorare lì.

La contrattazione è appetibile, dal momento che la pressione fiscale è inferiore rispetto a quella italiana: sempre più professionisti del ramo IT apprezzano la possibilità di guadagnare di più e di accumulare velocemente tanta esperienza che questo tipo di contrattualità mette a disposizione.

Il lato negativo di questo sistema — se vogliamo considerarlo negativo — è che per gli standard italiani il tasso di turnover potrebbe essere piuttosto alto e il mercato risultare molto competitivo.

Diversity & inclusion

Lavorare in una metropoli multiculturale come Londra rappresenta un’esperienza favolosa, difficile da replicare in qualsiasi città italiana. Lavorare con team costituiti da persone che vengono da tutto il mondo offre un’esperienza ricca e diversificata in termini di apprendimento e creatività.

A Londra la diversità si concretizza in uno stile di vita in cui, ogni giorno, si viene esposti a modalità molto diversificata di affrontare le sfide professionali, ma anche a differenti consuetudini, religioni, tradizioni e culture culinarie. Tutto questo ha contribuito significativamente a farmi sviluppare una mentalità aperta.

Conclusioni

[…] when a man is tired of London, he is tired of life; for there is in London all that life can afford. (Samuel Johnson)

Concordo pienamente con la citazione riportata qui sopra: per me Londra è davvero un ottimo posto in cui vivere, sia dal punto di vista professionale che personale.

La comunità Agile è vivace e attiva; e, anche se in molte organizzazioni l’Agilità non è così matura come mi sarei aspettato, nella maggior parte delle aziende c’è comunque la consapevolezza che occorre essere competitive, rilasciare valore reale al cliente e creare sul lavoro un ambiente in cui i team si impegnino e migliorino costantemente.