Team cross-funzionali: cosa sono e il loro ruolo per lo sviluppo agile di un prodotto. Un racconto

Questo articolo è ispirato alla puntata del Reloaded Podcast “Cross-funzionalità: perché è utile per lo sviluppo agile di un prodotto. Un racconto“, a cura di Stefano Marello.

Cosa si intende per cross-funzionalità?
Cosa caratterizza i team cross-funzionali?
Perché sono così importanti per lo sviluppo agile di un prodotto?

Il concetto di cross-funzionalità

Quando parliamo di team cross-funzionali (o forse, più in italiano, multidisciplinari) occorre prima precisare che il termine “cross-functional” non appare nel Manifesto Agile – nel quale, piuttosto, si parla di “auto-organizzazione” -.
Invece, troviamo la parola cross-funzionale nella Scrum Guide, che recita:

Gli Scrum Team sono cross-funzionali.

Ovvero, testualmente:

I membri del team hanno tutte le competenze necessarie a creare valore ad ogni Sprint.

Una citazione, questa, che crea non pochi fraintendimenti.

Analizziamo l’ultima parte: “i membri del team hanno tutte le competenze necessarie a creare valore ad ogni Sprint”. Da qui nasce uno dei primi grandi equivoci quando si parla di team multidisciplinari.
La frase non indica che tutte le persone debbano saper fare tutto. In un gruppo, è inevitabile che alcuni siano più specializzati in certi ambiti piuttosto che in altri; non è realistico che tutte abbiano le stesse competenze e che ognuno sia perfettamente interscambiabile con l’altro.

Riprendendo la Scrum Guide, nel rispetto del vero significato di cross-funzionalità, possiamo affermare che un team può considerarsi cross-funzionale se costituito da una persona per ogni competenza necessaria a sviluppare il prodotto (esemplificando: un designer, uno specialista frontend, uno backend, un testing specialist, uno lato operation…insieme formano un team cross-funzionale).

È quello che succede nella maggior parte dei team che lavorano in aziende di medio-grandi dimensioni. Molto spesso, però, in queste realtà la parte di Design e di Operation sono esterne al gruppo e gestite da un silos apposito. Situazione che va a creare una forte dipendenza per gli sviluppatori.

Per meglio spiegare ciò di cui stiamo parlando, riportiamo il racconto di un’esperienza vissuta direttamente da Stefano (autore dell’episodio podcast).

Un “racconto” sulla cross-funzionalità

La storia che Stefano racconta riguarda un team che, dopo aver sopportato a lungo il peso di alcuni problemi, in qualche modo è riuscito ad affrontarli ed evolversi, facendo leva sulla vera multidisciplinarietà dei suoi individui.

Il team

Stefano faceva parte di un gruppo che, tra le varie attività, stava sviluppando un qualche tipo di e-commerce. Il team era composto da 7 persone, 5 delle quali neolaureate (Stefano sottolinea questo aspetto, poiché potrebbe aver fatto la differenza).
La caratteristica principale del team è che era composto esclusivamente da sviluppatori: non c’erano persone dedicate al Design o al Testing e, per procedere con il lavoro, bisognava interfacciarsi con i rispettivi team di Test e Design.
Il gruppo, però, era abbastanza autonomo sul lato Operations.

La fase di kick-Off

Nella fase di Kick-Off del progetto, erano coinvolti 3 sviluppatori solo Frontend, 3 solo Backend, e Stefano, che in realtà era più Scrum Master che sviluppatore. Ben presto iniziarono i colli di bottiglia: il lavoro prevedeva la costruzione da 0 dell’architettura e di sviluppare una quantità non indifferente di microservizi. Al contrario – senza andare troppo nei dettagli del contesto – la parte di Frontend era generalmente semplice rispetto al motore che la alimentava.

Il principio del Whole Team

Dopo un primo momento di blocco, durante il quale gli sviluppatori Frontend sembravano scarichi da mansioni, è venuto in soccorso del team il principio del “Whole Team” (c.f.r. “team intero”, “un tutt’uno”). Il principio enuncia che il gruppo, oltre ad essere multidisciplinare, deve essere composto da persone cosiddette “T-Shaped” o “Generalizing Specialists“, ossia “Specialisti che si generalizzano“: persone con una specializzazione in un certo ambito, ma che non si limitano a lavorare sul proprio pezzo bensì, all’occorrenza, sono in grado di aiutare gli altri colleghi anche nelle mansioni per le quali non sono altrettanto esperti.

Lavorare secondo il principio del “Whole team” richiede uno sforzo importante da parte delle persone e una forte apertura mentale: ai membri del team viene chiesto di uscire dalla propria comfort zone, di rendersi in qualche modo vulnerabili e di sentirsi inefficienti; almeno inizialmente.

Cultura e mindset

In un tale contesto, gioca un forte ruolo la cultura aziendale e del team, che deve promuovere questi comportamenti convinto che porteranno dei benefici a lungo termine, a costo di un’inevitabile inefficienza iniziale.
Facendo un passo indietro, il fatto che i ragazzi fossero neolaureati ha effettivamente giocato un ruolo importante. Generalizzando, è noto che più uno sviluppatore (o una generica figura) è esperto e “anziano” – con riferimento all’esperienza professionale – , più è restio a rimettersi in gioco e ad adottare un nuovo punto di vista.
Nel contesto che Stefano racconta, anche se i tre sviluppatori Frontend erano consapevoli di non poter contribuire efficacemente sulla parte di Backend, hanno comunque provato a dare il loro contributo attraverso sessioni di pair programming e risolvendo piccoli task semplici.

La stessa dinamica si è registrata nella fase di rilascio, dove la parte di Operations era del tutto nuova ai neolaureati; anzi, in realtà solo un paio di persone nel team ne possedevano una conoscenza approfondita.
Anche in questo caso, i ragazzi hanno deciso di affiancare il team: le prime volte anche senza contribuire attivamente e, potenzialmente, rallentando il processo. Ma nelle settimane e nei mesi successivi, il loro atteggiamento ha dato una forte spinta al lavoro dei colleghi.

Il valore per il cliente

Stefano spiega come, durante gli incontri di planning, l’attenzione non fosse più su chi facesse cosa, né ci si preoccupava del fatto che qualcuno potesse essere scarico di lavoro o assente; invece, il focus era sugli incrementi di valore per il cliente.
Il team era diventato autonomo e consapevole di poter sempre completare lo sviluppo delle funzionalità, dall’inizio alla fine, rilascio compreso, a prescindere da chi fosse in ferie, impegnato su altro, in malattia…grazie al coinvolgimento di ognuno.

In conclusione

La storia di Stefano fornisce una bella rappresentazione di un team multidisciplinare: un insieme di persone esperte nel loro settore e dinamiche – soprattutto mentalmente -, in grado di intervenire a supporto dei colleghi, anche nelle mansioni per le quali sono meno esperte.