Ancora sui team “cross-functional”
Uno dei mantra dell’Agilità, declinata a qualsiasi livello, è la necessità di “team cross-funzionali” e che sappiano gestirsi autonomamente. La Guida Scrum [1], nell’ultima versione, recita letteralmente:
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.
Nella riflessione che affrontiamo in questo articolo vogliamo partire dal concetto del team “cross-funzionale” e rivedere ancora una volta cosa significhi in concreto. Ma, nella seconda parte, ci spingeremo avanti — o meglio, indietro nel tempo — per fare qualche considerazione sul fatto che, in definitiva, l’idea non sia poi così nuova, anche se ci appare tale a motivo della storia della produzione industriale nel Novecento.
Ma partiamo dalle parole.
“Cross-funzionale”: perché?
Nella versione italiana della Guida Scrum, il termine cross-functional è tradotto come “cross-funzionale”, parola ormai entrata nel gergo degli agilisti. Ma in realtà, si sarebbero dovute usare delle parole italiane esistenti, più comuni e con un significato più chiaro.
Nella traduzione francese della Scrum Guide, infatti, gli Scrum Team sono definiti pluridisciplinaires (“multidisciplinari”), in quella tedesca interdisziplinär (“interdisciplinari”), mentre il testo greco parla esplicitamente di δεξιότητες από διαφορετικά πεδία (“competenze provenienti da campi diversi”). Guardiamola come vogliamo, ma di certo in italiano esistevano almeno due parole molto più chiare di “cross-funzionale” per esprimere quel concetto: “multidisciplinare” e “interdisciplinare”.
Ad ogni modo, il significato viene comunque spiegato quando si dice che lo Scrum Team possiede tutte le competenze necessarie per creare valore a ogni Sprint.
Chiusa qui la questione terminologica, continueremo a usare intercambiabilmente i termini interdisciplinare, multidisciplinare e “cross-funzionale”, e ci concentreremo invece su cosa significhi un team di questo tipo e perché ereditiamo dalla concezione industriale e manageriale novecentesca un approccio in cui spesso professionisti con competenze differenziate tuttora fanno fatica a lavorare in maniera interdisciplinare.
Il che non significa che non esistano già da molto tempo — o che non stiano aumentando — realtà in cui si lavora con quest’approccio.
Qualche buona ragioneper i team “cross-funzionali”
Quali sono i motivi che spingono sempre più organizzazioni a preferire un approccio per team in cui, fianco a fianco, lavorano insieme persone con competenze diversificate, che in un approccio classico avrebbero lavorato in compartimenti separati? Partiamo dal principio — che approfondiremo più avanti — che tale approccio classico, “per silos” è più adatto alla gestione di progetti con attività ripetitive che non alla realizzazione di prodotti che richiedano una costante dose di ideazione per adattarsi a uno scenario mutevole.
Ciò premesso, e in attesa di tornarci su, vediamo alcuni aspetti che giocano a favore di team interdisciplinari e autoorganizzati. Che, sia chiaro, non si trovano già pronti al supermercato, ma nascono dalla presenza in azienda di persone con una mentalità adeguata, pronta alla condivisione della conoscenza e aperta al cambiamento.
I team cross-funzionali sanno più cose
Che non significa solo che le persone con competenze multidisciplinari assommano più conoscenza e capacità operativa, ma soprattutto che il team sa di più riguardo all’oganizzazione nel suo complesso, perché non resta confinato nel suo silos. Di conseguenza, il team sarà in grado di allargare gl orizzonti e superare i classici confini organizzativi.
I team cross-funzionali prendono decisioni migliori
Non si tratta di preveggenza o lungimiranza, ma sostanzialmente del fatto che il processo decisionale è fatto tenendo in considerazione svariati punti di vista e, soprattutto, andando a ricavare un insieme di informazioni diversificate, provenienti da mondi diversi ma messe in relazione in un processo di sintesi meno uniderezionale (dal “boss” ai mero esecutori) e maggiormente dinamico con veloci scambi di feedback in tutte le direzioni, che portano alla decisione.
I team cross-funzionali migliorano il coordinamento e la comunicazione
Per team formati da persone con competenze diverse, di formazione diversa e che magari hanno esperienza in settori diversi, la comunicazione efficace all’interno del gruppo diventa una necessità non differibile. Parlare un linguaggio comune, evitare i gerghi settoriali affinché tutti capiscano, confrontarsi continuamente è quasi scontato. Ma questo ha effetto anche sull’intera organizzazione, poiché questo approccio si riflette sulle realtà che pur essendo “esterne” al gruppo, con esso interagiscono costantemente.
I team cross-funzionali sono generalmente più produttivi
In un’organizzazione che favorisca una cultura cross-funzionale si assiste spesso a un miglioramento della produttività, con riduzione di colli di bottiglia e di situazioni bloccanti, tipicamente connesse a un’organizzazione a silos.
Per esempio, in un processo di sviluppo del software, con team cross-funzionali in cui tutti possono fare quasi tutto — dall’analisi all’implementazione ai test — si potranno avere situazioni in cui due persone lavorano alla stessa storia utente passando da un task all’altro e in cui la persona momentaneamente libera ne aiuta un’altra a concludere il proprio task, con una riduzione del cycle time. Questo non accadrebbe in un team in cui i professionisti sanno fare “solo quella cosa lì” e non hanno la capacità di spostarsi si più fronti.
Attenzione a non mitizzare
I team snelli, autogestiti, multidisciplinari con tutte le competenze necessarie funzionano e apportano vantaggi alle organizzazioni in cui “vivono”. Ma non mitizziamo questo aspetto. Al di là dell’impegno necessario per crearli, ricordiamoci che esistono tuttora molti silos: progettisti, grafici, sviluppatori, tester, o frontend, back end e così via, tutti abbastanza separati.
E non dimentichiamo che, pur in un’ottica apparentemente “agile”, esiste quell’approccio per cui l’idea del team multidisciplinare viene applicata in maniera acritica con un’imposizione dall’alto, magari di un modello messo a punto per una realtà differente: è successo qualche anno fa quando in tanti si sono infatuati del “modello Spotify” basato sulle squad, ottimo per l’azienda in cui è nato, ma non necessariamente adatto a ogni situazione. Con il risultato che le cosiddette cross-functional squads poi non erano affatto interdisciplinari…
La complessità, ancora una volta…
Forse siamo arrivati alla saturazione con questa storia sulla complessità ma, di fatto, se non fosse stato per la costante crescita della complessità dei mercati, dei prodotti, delle tecnologie, avremmo potuto fare anche a meno di adottare i principi e le pratiche Lean/Agile, continuando a vivere felici e contenti in un modello industriale Fordista/Taylorista. Affermazione, questa, piuttosto perentoria, ma sicuramente con un fondo di verità.
E allora, come si diceva all’inizio, il modello “per silos” è più adatto alla gestione di progetti con attività ripetitive, mentre per la realizzazione di prodotti che richiedano una costante dose di ideazione sono i team multidisciplinari a rappresentare una soluzione migliore.
Ma questa non è una novità come ci dimostreranno un paio di esempi presi dal passato. Che vedremo nel prossimo numero, nella seconda parte di questa miniserie.
Conclusioni
Nel prossimo articolo ci occuperemo di un paio di esempi indicativi sul tema della competenze e dei gruppi di lavoro interdisciplinari; quindi, appuntamento al prossimo mese, quando parleremo della cosidetta “vasca di Taylor” [2] e di popolazioni “primitive” dell’Amazzonia. Storie che, per quanto non provengano direttamente dal mondo Lean/Agile, fungeranno da approfondimento alla comprensione di un tema ampio e impattante.
Riferimenti
[1] La guida Scrum, edizione 2020
https://scrumguides.org/scrum-guide.html
[2] Niels Pflaeging, Organize for Complexity: How to Get Life Back into Work to Build the High-Performance Organization. Lightning Source Inc., 2014
Luigi Mandarino ha cominciato ad appassionarsi ai computer con il glorioso ZX Spectrum 48k: una bomba, per l‘epoca 🙂 Dopo gli studi di ingegneria, si è dedicato per diversi anni allo sviluppo di applicazioni Java, specie per la piattaforma Enterprise. Successivamente, ha svolto il ruolo di architetto dei sistemi interessandosi particolarmente alle architetture di integrazione. Attualmente, svolge consulenze a svariate aziende in particolare nel settore bancario, assicurativo e finanziario, principalmente su temi inerenti le architetture Java EE e le dinamiche di processo secondo un approccio Lean/Agile.