Capire il valore dei team cross funzionali è uno dei cambi di mentalità più importanti che un’organizzazione possa fare. E’ decisamente un salto impegnativo, sperimentabile con dei team pilota, ma comunque un grande salto. Sì, perché ti chiede di andare “contro natura”, contro il fatto che gli imbianchini lavorano tutti insieme nel loro bel silos di imbianchini, che la ditta di muratori ha tutti muratori sul libro paga e quella di elettricista ha tutti elettricisti al suo interno. Cioè: perché dovrei mettere insieme a lavorare un imbianchino, due muratori, un elettricista, un cartongessista e un pavimentatore quando posso pagare un capo-cantiere che mi coordina le 4-5 ditte, ognuna delle quali ha altre 10 case a cui pensare? Mmmm…. no, non ne vale la pena.

Per team cross funzionale si intende un gruppo di persone con skill diversi, che hanno mestieri diversi, che normalmente sono “allocate su funzioni diverse” (per questo cross funzionale), che lavorano insieme e formano un team con lo scopo di portare a casa un progetto, un risultato che ha bisogno di tutti i loro skill per essere completato. Più il team sarà autonomo e avrà risorse dedicate, più la magia potrà accadere.

Non facciamoci ingannare dalla bibliografia. I team cross funzionali non esistono soltanto nel mondo dello sviluppo software: questo concetto è applicabile in moltissimi altri contesti, ovunque ci sia un progetto comune che necessità di persone con skill diversi per essere concluso.

I team cross funzionali prendono anche il nome di feature team, termine che evidenzia in maniera inequivocabile l’obiettivo principale del gruppo: produrre feature, funzionalità, ma non solo. Il team cross funzionale produce oggetti e si ottimizza per consegnare al cliente, al mercato, al CEO quegli oggetti per il quali nasce: quindi un team di prodotto consegnerà pezzi di prodotto (funzionalità, feature, user story) e un team di marketing produrrà campagne. Nella filosofia del lean agile marketing ad esempio i team del marketing sono cross funzionali includono tutti gli skill utili per “macinare” campagne.

Vediamo ora quali sono i benefici che un team cross funzionale o feature team può portare all’organizzazione che li adotta.

1. Focus

Un team cross funzionale non ha scuse, non deve aspettare nessun altro team per raggiungere il proprio risultato, perché ha tutte le persone delle quali ha bisogno per produrre quello che gli serve. Sviluppa un oggetto che è proprio quello che è richiesto dall’organizzazione, non è un semilavorato che poi verrà gestito da un altro reparto e poi da un altro e da un altro ancora. Chi sviluppa è lo stesso che mette il prodotto sul mercato e vede se funziona o meno.

2. Contaminazione

Lavorare con colleghi che hanno professionalità, esperienze, modi di approccio diversi è un enorme arricchimento per ognuno, soprattutto in un periodo storico in cui la professionalità non paga. Cosa ripaga invece? Sapersi muovere in ogni occasione, sapersi adattare al contesto, sapersi reinventare alla velocità della luce. Discutere con altri che non fanno il tuo mestiere, lavorare gomito a gomito per un risultato comune, apre le porte alla classica soluzione “C”, sinergica e solitamente “win-win” e permette ad ognuno di indossare gli occhiali dell’altro, di capire il suo punto di vista e di rimanere positivamente contaminati.

3. Comunicazione

Si parla tanto di problemi di comunicazione nelle aziende, soprattutto in quelle grandi e strutturate. Citando una frase del presidente dell’Italian Agile Movement, “le chiamano divisioni e si lamentano della mancata comunicazione”. Succede che si lavora sugli strumenti di comunicazione, sui vari tool, processi, formati delle email, form di richiesta bla bla bla, con la conseguenza che si rende estremamente complessa una cosa che si risolve cambiando il paradigma. In un team cross funzionale non ci sono problemi di comunicazione: il programmatore è nella stessa stanza del designer e del tester. Fanno una cosa ormai in disuso: parlano. Senza bisogno di strumenti, di interfacce, di protocolli di comunicazione.

4. Accountability

Quando si lavora per mestieri, chi è il responsabile del progetto, chi è accountable? Bella domanda. Tutti ognuno per la sua parte e quindi nessuno. Nei team cross funzionali si impara la responsabilità. Il team consegna un prodotto finito e non può dire che il problema si è presentato nell’altro reparto: non ha scuse o e non ha alibi. Questa mancanza di vie di fuga, questa impossibilità di puntare il dito contro qualcun altro, fa cambiare mentalità alle persone che, diventate “accountable” per il loro progetto, iniziano ad alzare il proprio sguardo e a guardare oltre il proprio orticello: il prodotto sta funzionando? i clienti sono contenti? quanti ne stiamo vendendo? Al team interessa perché lo sente suo.

5. Diversità

L’esercizio quotidiano al rispetto e all’apprezzamento delle diversità è fondamentale e non succede quanto si lavora in contesti nei quali siamo tutti uguali. Invece di guardare chi ne sa di più, si cominciano ad apprezzare le passioni degli altri, si capisce in maniera profonda le ragioni degli altri mestieri. Quante volte, in un’organizzazione funzionale, ci si chiede “ma che farà quel reparto?” e si ha l’impressione che il vero valore al prodotto finito sia portato soltanto dal nostro reparto. In un team cross funzionale questo non succede e si impara ad apprezzare il valore finale di ogni mestiere e il suo contributo per la riuscita del progetto.

6. Troubleshooting

Per chi pensa che il troubleshooting sia un problema di un mestiere specifico tipo “sono giù le piattaforme, ci pensano i sistemisti” si sbaglia di grosso. I problemi possono essere risolti da una funzione specifica, ma spesso hanno conseguenze diverse in base a come vengono risolti. Avere un approccio olistico, coinvolgere persone diverse alla risoluzione di un problema può cambiare radicalmente l’approccio al troubleshooting. Chi lavora nell’IT sa benissimo che un problema tecnico, oltre ai sistemi (per esempio) può coinvolgere gli sviluppatori (per capire se il guasto deriva da un pezzo di codice), il customer care (che poi dovrà gestire i clienti), il marketing (che magari dovrà comunicare il guasto sui vari canali), i legali (se il problema potrebbe avere conseguenze legali). Questo non significa che per risolvere un problema urgente si debba fare una riunione con 10 persone: tutt’altro. Chi lavora in un team cross funzionale per sua natura avrà sviluppato il punto di vista del cliente, del marketing, del legale, perché vive il prodotto/progetto a tutto tondo, invece di avere una visione parziale come avviene nei silos.

7. Leadership

In un team cross funzionale la persona può sviluppare la propria leadership in maniera controllata e meritocratica. Solitamente questi team si auto organizzano, magari con l’aiuto di una persona tipo Scrum Master (per i team Scrum) che facilità l’auto organizzazione, risolve i conflitti e rimuove gli impedimenti di percorso. In questo tipo di contesto, il leader emerge, impara a farsi strada, a guidare le persone in maniera naturale e senza bisogno di job title. La propria opinione è vera, reale e riceve la giusta considerazione se supportata da un valore che gli altri riconoscono. Si forma l’autorevolezza, a dispetto dell’autorità che invece arriva in contesti gerarchici.

8. Management

Una delle caratteristiche e delle sfide più importanti di un manager è di sapersi interfacciare con successo, quotidianamente, con tutte le funzioni aziendali, capirne le logiche, al fine di ottenere il risultato che si sta ricercando. Nei team cross funzionali, la funzione di management viene esercitata dal team stesso, che si auto gestisce e, quotidianamente, negozia i rapporti fra il programmatore, il designer e il tester. In questo contesto si preparano coloro che hanno aspirazioni di diventare manager a saper dialogare con le varie funzioni aziendali.

9. Conflitto

Nel team cross funzionale ogni team member è estremamente esposto a potenziali conflitti, perché non ci sono mediatori. Nei team gerarchici i rapporti 1to1 con il manager e quelli con i propri colleghi sono di natura molto diversa: con il manager si parla di cose da fare, di task e anche di problemi con gli altri, mentre con i colleghi si parla soltanto di lavoro. In un team senza il manager gerarchico questo non può accadere e si devono risolvere i conflitti in maniera naturale: al bisogno ci può essere un facilitatore (tipo Scrum Master), ma è una figura che comunque faciliterà la risoluzione fra le persone senza imporsi. Nel team cross funzionale si impara la difficile arte di affrontare, risolvere, mediare i conflitti.

10. Allineamento e Vision

Nelle grandi organizzazioni è difficilissimo avere un obiettivo comune: si può fare ma è un percorso molto lungo e ci vuole un ingaggio fortissimo e quotidiano di tutto il management. Quello che solitamente succede è che ogni reparto, ogni silos, avrà le proprie priorità, che assomiglieranno più a propri obiettivi, non necessariamente allineati con quello unico aziendale e a volte anche in contrasto l’una con l’altra. In più: ogni silos prova ad “imporre” la sua priorità sugli altri team, perché sicuramente avrà bisogno di altri mestieri per raggiungere i propri obiettivi di reparto. In un team cross funzionale, in una product unit, si può avere, si deve avere una vision chiara e il team, dato che è in grado di sviluppare in autonomia il progetto richiesto, può allinearsi continuamente al suo obiettivo, lo vive tutti i giorni, mentre sviluppa, mentre decide cosa sviluppare la settimana o il mese prossimo. Non ha da mettersi d’accordo con nessuno se non con sé stesso.

E’ il momento delle scuse

Non convinti da questi 10 motivi (ma ce ne potrebbero essere anche altri), molti adducono delle scuse per difendere il punto di vista del mestiere.

“Se tengo insieme chi fa lo stesso mestiere, la qualità aumenta”

Se per qualità si intende quella dell’oggetto finale, del prodotto da consegnare al cliente, questo non è assolutamente detto, anzi. Lavorare in silos porta inevitabilmente a quelle che si chiamano “ottimizzazioni locali”, ovvero si rafforza al massimo un anello della catena senza avere una visione globale di quello che quella ottimizzazione comporta.

“Se tengo insieme chi fa lo stesso mestiere, l’efficacia aumenta”

Direi che avviene assolutamente l’opposto, se per efficacia si intende il tempo di delivery o quella percepita dal cliente finale che riceve il prodotto. Solitamente il lavoro in silos di mestiere è drammaticamente più lento dato che ogni gruppo ha le proprie priorità e mettersi d’accordo richiede tempo e negoziazione.

“Se tengo insieme chi fa lo stesso mestiere, le persone crescono professionalmente”

Anche qui non penso sia vero. Il concetto moderno di crescita professionale va ben oltre diventare il massimo esperto di una materia. Negli ultimi anni si prefiscono professionalità T-shaped o “double deep”, dove quindi non conta solo il proprio mestiere ma anche saper dialogare o addirittura confrontarsi su altri argomenti fuori dalla propria zona di comfort.

“Se tengo insieme chi fa lo stesso mestiere, il mestiere potrà sviluppare i propri standard”

Beh, sì, certamente, lo può fare, ma si ricade nel problema dell’ottimizzazione locale. Lavorare sui propri standard senza vedere come questi influiscano sull’intero flusso di delivery porta spesso a irrigidimenti sia in termini di time-to-market ma anche di possibilità di innovazione. In questo caso meglio che i vari (ad esempio) sviluppatori nei vari team cross funzionali si riuniscano di tanto in tanto per discutere sugli standard, portando il punto di vista dei team dai quali provengono.