Nei messaggi precedenti ho introdotto le 3 caratteristiche di un team di sviluppo secondo la concezione moderna.

• Composto un gruppo di persone stabile;
• Numero di persone compreso tra 5 e 9;
• Le persone che lo compongono lavorano insieme verso un obiettivo comune.

Oggi parliamo del secondo punto.

Numero di persone tra 5 e 9

Perché proprio tra 5 e 9 persone? Ti suona familiare?

Sono numeri ricorrenti nel mondo Agile, e probabilmente hai già sentito parlare dei “two pizzas team” di Amazon.

Questo range deriva dagli studi di Robin Dunbar (Neocortex size as a constraint on group size in primates) i quali indicano che 15 è il numero massimo di persone di cui una persona riesce a fidarsi profondamente. Ulteriori evidenze che si accodano agli studi di Dunbar ci indicano questi intervalli:

• Circa 5 persone: limite di persone con cui possiamo avere relazioni personali strette e che rientrano nella nostra memoria di lavoro.
• Circa 15 persone: limite di persone con cui possiamo sperimentare una fiducia profonda.
• Circa 50 persone: limite di persone con cui possiamo avere una fiducia reciproca.
• Circa 150 persone: limite di persone di cui riusciamo a ricordare le capacità.

Ecco perché lasciare crescere un team oltre il range da 5 a 9 mette a rischio le dinamiche di team: oltre quelle dimensioni non è possibile instaurare un livello di fiducia profonda tra tutti con impatti sulla qualità, le tempistiche e i processi decisionali.

Con queste caratteristiche il team diventa l’unità atomica di produzione su cui fare affidamento piuttosto che le singole persone.

Secondo gli autori di Team Topologies un’organizzazione non dovrebbe mai assegnare lavoro ai singoli ma sempre ai team e inoltre le fasi di progettazione, consegna ed esercizio del software dovrebbero partire con un approccio team-centrico.

Ora che abbiamo visto le caratteristiche di un team ben congegnato e che funziona come unità atomica di capacità produttiva… come farlo operare al meglio nel più grande contesto aziendale o insieme ad altri team?

Per vederci meglio andiamo a rispolverare un importante concetto nel mondo del software: la legge di Conway.

Ma sarà per il prossimo episodio!

Sharing is caring

Se conosci qualcuno che potrebbe trovare utile ricevere e-mail per migliorare l’organizzazione dei team di sviluppo software, DevOps e software engineering in generale inoltragli questo post! Qui può iscriversi e cominciare a ricevere subito!