Parole Agili: Competenze “I” e Competenze “T”

Simone Rastelli
Sep 7, 2018 · 4 min read

Un team formato esclusivamente da specialisti finisce per lavorare a cascata e a generare tempi morti tali che il management sceglie di farli ruotare fra più progetti.

Diventare agile implica cambiare il sistema di riferimento del nostro modo di lavorare: cambiano i problemi, le soluzioni (accettabili) e il linguaggio stesso che li esprime. In questa revisione, anche il concetto di competenza tecnica individuale è sottoposto a forti tensioni. Una breve riflessione sul concetto e il senso delle competenze individuali in una visione agile aiuta a comprendere la profondità e capillarità del cambiamento implicato: per la persona, infatti, questo cambiamento mette in discussione tanto il lavoro quotidiano quanto la visione della propria carriera.

Illustrando la composizione di un team agile, una delle raccomandazioni ricorrenti è che non solo le competenze del team nel suo insieme coprano tutte le necessità del progetto, ma anche che ogni membro abbia competenze “T” e non “I”. Che cioè unisca alla competenza forte in un campo specifico la capacità di contribuire in altri campi utili al progetto. Il motivo profondo di questa raccomandazione sta nel fatto che, in caso contrario, di fatto il team lavorerà in cicli di sviluppo waterfall e la stessa collaborazione al suo interno sarà fortemente limitata dall’assenza di un terreno comune.

Per fissare le idee consideriamo un caso schematico: un team che sviluppa un prodotto la cui realizzazione richiede tre competenze tecnologiche: Javascript, CSS e phyton. In questo caso, avere competenze “I” significa che ciascun membro del team conosce (profondamente) una e una sola delle tre tecnologie: avremo quindi uno specialista javascript, uno specialista CSS e uno specialista phyton (aumentare il numero di componenti del team non cambia questo ragionamento). Competenze “T”, invece, significa che, ad esempio, lo specialista javascript è in grado di lavorare anche al CSS o ai componenti phyton e così via.

La distribuzione di competenze influenza la modalità di lavoro del team, perché, tipicamente, la realizzazione di ciascuna funzionalità del servizio richiede sviluppo sui tre livelli tecnologici. Punto importante: esistono dipendenze fra questi sviluppi, tali che si può lavorare su un livello solo quando le dipendenze sono state risolte.

Quindi, nel caso di competenze “I” accade una cosa piuttosto fastidiosa: ciascun specialista attende che sia terminato il lavoro di un altro specialista, senza essere in grado di aiutarlo.

Che cosa fa lo specialista mentre aspetta? Di solito lavora a un’altra funzionalità.

Sorgono quindi alcuni punti dolenti — almeno una prospettiva agile. Osservando il team e i suoi componenti notiamo infatti che:
- il lavoro procede a cascata, poiché ognuno è costretto ad attendere il completamento del lavoro di un altro;
- nessuno è in grado di eseguire “pull” reale delle attività, perché ognuno può prendere in carico solo i pezzi di attività nei quali ha competenza: questo influenza anche il commitment di ciascuno, poiché l’assegnazione di una data attività dipende esclusivamente dalla tecnologia di implementazione;
- non è possibile eseguire “storming” in caso di problemi: ognuno, per così dire, resta solo di fronte al proprio lavoro;
- si mettono in lavorazione attività prima del rilascio di quelle già in lavorazione, con un conseguente accumulo di “semilavorati”.

Nel caso, invece, di un team i cui membri abbiano competenze “T”, il rischio di tempi morti e di accumulo di semilavorati diminuisce, poiché diminuisce la probabilità che la competenza richiesta per terminare un’attività sia indisponibile nel momento in cui serve.
La presa in carico di un’attività in fase di planning è un “pull” effettivo: poiché più di una persona è in grado di lavorarla, il team ha la possibilità di scegliere chi lavorerà su di essa. È questa possibilità che consente di ragionare in termini di commitment e responsabilità: il team diventa quindi effettivamente responsabile delle proprie scelte.
Infine, quando un’attività si blocca per qualche problema tecnico, tutto il team può contribuire allo sblocco, aiutando la persona che la stava lavorando.
Dal punto di vista Agile, quindi, appare fondamentale promuovere competenze “T”.

Un’osservazione/obiezione tipica a queste osservazioni è che le competenze “T” portano a una perdita di efficienza. Ogni membro investirà parte del proprio tempo a imparare competenze marginali — nelle quali comunque non diventerà un esperto — invece che a rafforzare quella principale. Così facendo ci si espone al rischio di:

- Diminuire la qualità nello sviluppo, visto la disomogeneità dei contributi dei vari componenti;
- Perdere le persone competenti, che vedono indebolire la propria professionalità e possono essere tentate di andarsene prima di perdere competitività sul mercato del lavoro.

Questa considerazione suona molto di buon senso, ma deve essere messa a confronto con le conseguenze sopra indicate. Messe insieme, infatti, esse risultano in un modo di lavorare che abbonda di tempi morti e colli di bottiglia — ovvero un bel po’ di spreco nel famigerato flusso di valore del lavoro. La soluzione tipica che vediamo applicata è quella di muovere le persone fra vari progetti in base alle competenze richieste. L’obiettivo è rendere minimo il tempo nel quale lo specialista se ne sta fermo, ma il risultato di questo giro di giostra è un continuo switch di contesto delle persone, che preclude tanto il loro coinvolgimento profondo quanto la loro efficienza.

La conseguenza interessante e profonda della scelta di valorizzare competenze “T” è che mette in discussione anche il percorso di formazione dei componenti del team: la strategia formativa, infatti, dovrebbe passare dalla specializzazione all’allargamento delle competenze, in base all’esperienza della persona. Un approccio, questo, che spesso stravolge tanto quello tipico all’interno di un’azienda, tradizionale quanto quello inseguito da molte persone.

In chiusura, è importante sottolineare che al cuore di questa trasformazione del senso delle competenze c’è la centralità del team.

Della quale, magari, scriveremo in un’altra occasione.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade