Rappresentazione artistica di due prodotti realizzando combinando componenti semplici fatti con i pezzi del Tetris
trianglee

Insights Team cross funzionali per lo sviluppo di prodotti e servizi

Lusso o necessità?

Linkedin Twitter
Scroll
28/07/2020

Articoli, Meetup

di Luca Montanari

 

Spesso si parla di team cross funzionali perchè le aziende sono organizzate in funzioni ognuna delle quali, almeno in passato, si identificava con una disciplina specifica. Utilizzare il termine team cross funzionale è una semplificazione e lascia intendere che sono coinvolte più funzioni, ma se l’organizzazione è davvero agile, il team supera le distinzioni di competenze e riallinea le prospettive spostando il focus sul cliente.

Quando un team inizia a lavorare in maniera agile, di solito subisce alcune sessioni di formazione che servono, tra le altre cose, a introdurre i concetti fondamentali sui quali iniziare a costruire la propria casa agile. Uno dei concetti chiave di cui si parla già nei primi corsi è quello del T-shaped team, in italiano si dovrebbe dire cross disciplinare o multi disciplinare.

Come spesso avviene, questo tema si interseca con altri concetti importanti, come quello dei feature teams vs. component teams, di come scalare quando diventa necessario e come gestire il coordinamento di più teams.

 

 

 

Nel meetup “Team cross-funzionali per lo sviluppo di prodotti e servizi: lusso o necessità?“, organizzato dal gruppo Agile Spirit abbiamo sperimento questi aspetti e abbiamo mostrato come interagiscono tra loro facendo una simulazione della realizzazione di un prodotto complesso. Nella nostra simulazione un prodotto complesso era costruito da 4 componenti, ciascuno con delle linee e un colore di sfondo.

 

Rappresentazione di due dei prodotti complessi nella nostra simulazione di come lavorano i team cross-funzionali. A sinistra un triangolo su uno sfondo composto da quattro quadrati di colore arancio, verde, porpora e giallo. A destra una stella a quattro punte su uno sfondo di quattro quadrati: giallo, verde, porpora, arancio.

Abbiamo lavorato prima in modo tradizionale con 4 team suddivisi per competenze omogenee, ciascuno dei quali era specializzato nella realizzazione di componenti dello stesso tipo più un team di integrazione, per assemblare i componenti e un team di quality assurance. Dato che siamo empiristi diligenti abbiamo anche l’ossessione dei dati: in questa prima iterazione il primo prodotto è stato completato al 7 minuto, e dei 5 prodotti completati, 1 è stato accettato dal team di quality. Lo spreco è stato di 27 componenti: 4 per ciascuno dei 4 prodotti non accettati più ben 11 componenti semilavorati ma non assemblati.

Abbiamo fatto poi un secondo esercizio cambiando le regole del gioco: ogni team aveva al suo interno tutte le competenze necessarie per assemblare il prodotto finito, compresa l’integrazione. In questo caso avevamo 2 team di “sviluppo” mentre il team di QA restava esterno. (sarebbe stato interessante fare un’altra iterazione con anche il QA all’interno del team, sarà per un prossimo meetup!). In questo caso il primo prodotto è stato consegnato dopo due minuti e mezzo, mentre i prodotti accettati sono stati 2 su 4. Lo spreco è stato di 9 componenti: 2 prodotti scartati e un componente pronto ma non assemblato.

Che cosa hanno imparato i partecipanti vedendo team cross-funzionali all’opera? La discussione finale è stata molto interessante ed articolata. Le conclusioni sono state che nel secondo caso abbiamo avuto meno spreco (ridotto di due terzi), un miglior time to market (ridotto a quasi un terzo) e anche più revenues (raddoppiati i prodotti pronti), il tutto con la metà dei teams. Le persone totali occupate non sono cambiate, sono cambiate le loro interazioni che sono diventate molto più produttive.

Abbiamo aggiunto un tassello importante nel mosaico dell’agilità e sfatato anche un falso mito: i feature teams non sono un lusso, anzi permettono di sfruttare meglio le risorse. E c’è anche un effetto collaterale non del tutto trascurabile: le persone sono più motivate, più felici e se lasciate libere di farlo migliorano le proprie competenze.

Feedback ricevuto dai partecipanti al termine del meetup "Team cross-funzionali per lo sviluppo di prodotti e servizi: lusso o necessità?" di Agile Spirit

Prendendo le dovute precauzioni, passando dal gioco alla vita reale, verrebbe da chiedersi perché il lavoro in team multi-funzionali non abbia avuto una diffusione più capillare, visti i benefici che può portare? Ci sono tanti fattori che impediscono la transizione o inibiscono la capacità dei teams di ottenere il massimo dei vantaggi. Ad esempio in un caso concreto che ho trovato presso un cliente i silos aziendali erano la causa primaria del blocco. Il team era multifunzionale, ma la sua capacità di auto-organizzazione era inibita perché, ad esempio, solo il tester poteva dare l’OK: solo la sua funzione aveva la responsabilità di poter accettare o rifiutare un incremento di prodotto. Questo creava un importante collo di bottiglia, oltre a generare frustrazione nel team. Altre volte la causa primaria è l’incapacità o la mancanza di volontà di rilasciare il controllo per darlo al team, o l’eccesso di burocrazia e procedure da rispettare.

 

Nella vostra azienda cosa sta bloccando il potenziale inespresso? Cosa state facendo per sbloccarlo?