Tre moschettieri o due pizze?
In tanti hanno dato la propria ricetta sulla dimensione ideale di un team, ma guardiamo cosa c’è dietro quel numero.
Dentro amazon c’è la regola del “two pizzas team”, ovvero i singoli team non devono essere così grandi da non poter essere sfamati da due pizze, in stile americano però, quindi circa 8-10 persone in tutto.
La Scrum Guide suggerisce meno di 10 persone, e l’eXtreme Programming ha raccomandazioni analoghe.
Secondo ‘Getting real’ per creare un nuovo prodotto il team ideale è di 3 persone, due sviluppatori ed un designer, i cosiddetti “3 moschettieri”.
Dietro questi numeri però ci sono molti ragionamenti per ottimizzare l’efficacia di un team, vediamo quali sono gli aspetti cruciali per una scelta di questo tipo.
Autonomia
Una tra le cose più importanti per rendere efficace un team è renderlo autonomo, ovvero mettere dentro il più possibile tutte le competenze che servono per poter perseguire il suo scopo. A seconda dei casi questo può voler dire portare degli sviluppatori in un team del marketing, o legali in un team principalmente di sviluppatori, unire designer e data scientist…
Perchè rimescolare così le persone? Uno degli ostacoli che rallentano i progetti è dover aspettare che un altro team con altre priorità faccia qualcosa che ci serve. In più lavorare assieme permette di prendere decisioni migliori in tempi molto più rapidi.
Ad esempio piuttosto che completare un grosso progetto di sviluppo, farlo controllare al reparto legale e scoprire che bisogna rifarne metà per rispettare le leggi, è molto meglio includere un esperto legale nel team per fare le analisi e prendere le decisioni nel corso dei lavori.
Per darvi un’idea il caso peggiore che mi è capitato di vedere è un’azienda che per consegnare una funzionalità doveva in media far collaborare più di 10 team diversi, tipicamente ogni sviluppo non impiegava meno di un anno!
Allora facciamo un bel team grande con tutte le persone che ci servono dentro?
Condivisione delle informazioni
Il problema con il crescere del team è anche il numero di conversazioni che devono accadere per rimanere tutti informati.
Come si vede dall’immagine qua sopra 3 persone creano 3 connessioni, un team di 6 ne crea 15, un team di 12 persone ne crea 66. La complessità della comunicazione aumenta molto più velocemente del numero delle persone coinvolte, riuscire a tenere tutti allineati e a non creare fraintendimenti diventa più difficile molto in fretta.
Allo stesso tempo c’è un altro fattore da tenere in considerazione.
Il bus factor
Il “bus factor” è il numero di persone che se finiscono improvvisamente sotto un autobus mettono il tuo progetto a rischio perchè non sono sostituibili. Ad esempio se c’è un solo sviluppatore che ha fatto tutto il sistema e nessun altro sa metterci le mani, il tuo bus factor è 1 e tu sei in una posizione molto rischiosa.
In alcuni casi tuttavia è accettabile anche un bus factor di 1, ad esempio in un progetto breve e secondario, o se è una situazione temporanea e/o di emergenza.
L’impronta
Ho lavorato con programmatori molto bravi, ma ogni persona ha il suo punto debole. Quando ho visto fare un software da una persona sola, si riesce sempre a vedere una piccola stortura tipica di quella persona. Magari c’è chi è fissato su dare troppa importanza ad un certo aspetto e lo complica, chi ne trascura un altro. È un po’ come se fosse l’impronta digitale, ognuno ha la sua. Ma basta far collaborare due persone che queste storture vengono smussate facilmente a vicenda.
Vogliamo tutte le voci
Se vuoi davvero sfruttare tutta la potenzialità del tuo team, devi dare a tutti la possibilità di esprimere i propri dubbi, le proprie idee e le proprie perplessità. Le persone tendono a farsi più problemi a parlare in team più numerosi, in particolare se sono introverse o appartengono a minoranze.
Tempi necessari
Come ci ricorda Fred Brooks in “The Mythical Man-Month” una donna impiega circa 9 mesi per partorire un bambino, ma se mettiamo 9 donne non ci impiegheranno un mese.
Ci sono cose che hanno bisogno di tempo ed aggiungere persone non migliorerà le cose, anzi potrebbe peggiorarle anche parecchio. Per iniziare un progetto nuovo è molto meglio essere un piccolissimo team affiatato piuttosto che un esercito agguerrito, finchè il progetto non cresce un po’ metterci più persone rischia solo di creare grossi problemi di coordinamento. Ho visto team di 10 persone iniziare assieme un nuovo prodotto da zero ed è stata una sofferenza.
Pensare “voglio un team grande perchè così andiamo più veloci“ può essere un grosso sbaglio.
Ma quindi?
Quindi cerca di fare il team più piccolo possibile, che abbia tutte le competenze che ti servono (le persone con competenze diverse potrebbero esserti molto utili) e che sia un minimo resistente agli imprevisti che possono capitare. Se devi iniziare un progetto valuta di partire con un team ridotto e poi farlo crescere nel tempo, ed orientativamente stai sempre sotto le 10 persone.
Ci risentiamo tra due settimane, buona giornata!
Pietro
Un altro fattore importante che influisce sulla dimensione (ma anche sulla "forma") di un team è il carico cognitivo e come è distribuito tra:
- carico intrinseco - quante informazioni sono "automatizzate" nella testa delle persone?
- carico estrinseco - quante informazioni sono "disperse" e vanno cercate in giro?
- carico pertinente - c'è per esplorare e imparare cose nuove?
L'obiettivo della dimensione e della "forma di un team" dovrebbe essere anche quello di: evitare sovraccarico cognitivo, e diminuire il carico cognitivo estrinseco per aumentare e massimizzare quello pertinente.