Costruire un team è un processo complesso. In questo articolo esploriamo alcuni dei principi fondamentali che ci hanno ispirato in Buildo nello sviluppare il nostro approccio unico alla costruzione di un team di sviluppo efficace.
Claudio Caletti Il concetto di team suggerisce che le competenze e l’esperienza dei membri del gruppo possano generare una sinergia tale da portare a una performance superiore alla somma delle singole parti.
Questo concetto non è frutto di supposizioni: è supportato da ricerche scientifiche, come lo studio di Driskell e Salas, che dimostra come i team coesi ottengano risultati migliori rispetto a semplici insiemi di individui quando si tratta di risolvere problemi. (5)
Team of penguins working at a computer on Mars — Midjourney
Mentre questa idea è ben nota negli sport di squadra, spesso viene trascurata nello sviluppo software. In questo contesto, i team vengono spesso costruiti esclusivamente sulla base delle competenze richieste. Se manca una competenza specifica, si ricorre a un freelancer per colmare il vuoto.
Questa pratica rientra in una strategia comune di espansione dei team di sviluppo, nota come “body rental”. Tale approccio rende particolarmente difficile creare team coesi, poiché i singoli membri possono non condividere obiettivi, incentivi o un senso di appartenenza.
In Buildo crediamo che costruire un team di sviluppo ad alte prestazioni sia essenziale per creare prodotti software di successo. Dalla selezione dei talenti alla costruzione di una cultura di team positiva, ci sono molti passi da compiere per costruire un gruppo in grado di realizzare la tua visione. Come si costruisce e si guida un team di questo tipo?
Costruire un team è un processo complesso; non esiste una procedura universale che funzioni per ogni azienda. Tuttavia, gli spunti derivanti dalla letteratura e dall’esperienza diretta offrono linee guida preziose e possono ispirare un approccio personalizzato. In questo articolo esploriamo alcuni dei principi fondamentali che ci hanno ispirato in Buildo nello sviluppare il nostro approccio unico alla costruzione di un team di sviluppo efficace.
I team che mostrano una dinamica sinergica, in cui la performance collettiva supera la somma dei contributi individuali, vengono spesso chiamati “jelled teams”. Questi team tendono a essere più produttivi rispetto a gruppi di professionisti semplicemente messi insieme, poiché incarnano davvero l’essenza della sinergia. Questo fenomeno può avere un impatto significativo sia sulla delivery che sulla retention.
Citando Tom DeMarco e Tim Lister:
When a team clicks, it seems to perform beyond itself. The members are on a new and different plane, and they can perform feats that even they could not have imagined (2)
Un esempio interessante di jelled team è il celebre team di testing di IBM, comunemente noto come “Black Team”.
Questo gruppo di esperti ha costruito la propria identità non solo attraverso le competenze tecniche, ma anche abbracciando tratti distintivi fisici, come far crescere i baffi e vestirsi di nero. Queste caratteristiche uniche hanno rafforzato il senso di unità, andando oltre le competenze individuali per raggiungere risultati eccezionali.
Anche se questo esempio può sembrare estremo, offre spunti preziosi sul processo di costruzione dei jelled teams e sull’impatto di un forte senso di coesione tra i membri del team.
Uno degli step fondamentali per creare team efficaci è riconoscere che i team si coltivano più di quanto si costruiscano. Come si coltiva un jelled team? Un approccio possibile è assumere, come leader, il ruolo di “giardiniere”. Proprio come un giardiniere si prende cura del proprio giardino, un leader di team può guidare e supportare il gruppo per farlo crescere.
Questo significa fornire risorse e supporto, promuovere una cultura di team positiva e aiutare i membri del team a sviluppare e consolidare le proprie competenze. Adottando la mentalità del giardiniere, i leader possono aiutare i propri team a raggiungere il loro pieno potenziale.
In Buildo adottiamo concretamente questo approccio del “giardiniere” creando team cross-funzionali autonomi, responsabili del successo dei propri progetti. Questi team sono composti da profili con competenze ed esperienze diverse, il che favorisce un ambiente interdisciplinare. Ciò consente al gruppo di avere una visione completa del progetto, affrontando il problema nella sua totalità. Grazie a questa struttura incoraggiamo l’allineamento interno e promuoviamo obiettivi condivisi e un senso di unità tra i membri del team. Questo non solo consolida la coesione del gruppo, ma permette a ogni persona di mettere in pratica le proprie competenze e di acquisirne di nuove, lavorando insieme per raggiungere gli obiettivi di progetto.
Team of rubber ducks working in a futuristic office, digital art — DALL-E
La Legge di Conway è un’osservazione formulata dal programmatore Melvin Conway nel 1967, che afferma:
Qualsiasi organizzazione che progetti un sistema (in senso ampio) produrrà un design la cui struttura riflette quella della propria struttura di comunicazione.
Per esempio, secondo Conway, se un team è diviso in silos, anche il software prodotto avrà una struttura modulare che riflette quei silos.
La logica alla base della Legge di Conway è che lo sviluppo software è un processo collaborativo e complesso, che coinvolge individui con competenze e visioni diverse. Le modalità di comunicazione e le dinamiche sociali di un team di sviluppo influenzano in modo significativo l’architettura e l’implementazione del sistema software che ne risulta.
L’aspetto più interessante della Legge di Conway è che suggerisce la possibilità di plasmare l’architettura software riorganizzando le modalità di comunicazione e le dinamiche sociali all’interno di un team di sviluppo o di un’organizzazione.
Un’applicazione nota è la Inverse Conway Manoeuvre, una strategia che sfrutta la Legge di Conway per orientare decisioni architetturali specifiche.
Ad esempio, il paradigma microservices prevede che ogni servizio abbia il proprio storage indipendente. Avere un team centralizzato di esperti DBA può rendere più difficile implementare correttamente il paradigma, perché i team di database e di microservizi, seguendo le loro abituali modalità di comunicazione, potrebbero tendere a progettare un sistema con storage centralizzato. In questi casi, distribuire la conoscenza del database tra i team di microservizi può favorire l’adozione corretta del pattern architetturale.
Team Topologies (4)
L’integrità concettuale si riferisce al grado in cui un design software aderisce a un insieme unico e semplice di principi. Concentrandosi sull’integrità concettuale, le organizzazioni possono garantire che il proprio software sia ben progettato e risponda ai bisogni degli utenti. Si può ottenere quando il processo di design è guidato da un piccolo numero di persone che condividono la direzione del progetto e hanno una comprensione profonda del sistema (3).
Un esempio emblematico di integrità concettuale è il sistema operativo Linux. Nonostante il numero enorme di contributor e l’estensione del codice, Linus Torvalds mantiene ancora oggi un ruolo centrale nel progetto: è lui a occuparsi del merge della maggior parte del codice nel Kernel Linux, garantendo che ogni contributo sia allineato ai principi fondamentali del sistema. Mantenendo una visione chiara e applicando con costanza le linee guida di design, Torvalds ha creato un ambiente in cui l’integrità concettuale viene preservata, con il risultato di un sistema operativo pulito e di alta qualità.
L’integrità concettuale è un concetto affascinante, con il potenziale di migliorare in modo significativo efficacia ed efficienza dei sistemi software. Non garantisce il successo, ma vale la pena considerarla come principio guida nello sviluppo software.
L’esecuzione efficace all’interno di un team richiede spesso di responsabilizzare i membri affinché possano prendere decisioni, in particolare coloro che sono più vicini al problema da affrontare.
Per poter prendere decisioni consapevoli, queste persone devono avere accesso a tutte le informazioni necessarie. Questo concetto è al centro dell’Open Book management, un approccio che pone l’accento sulla condivisione della conoscenza, sulla formazione e sull’accesso alle informazioni essenziali da parte di ogni dipendente, con l’obiettivo di aumentare il loro contributo al successo dell’organizzazione. Ciò implica offrire accesso a dati finanziari e operativi, oltre agli strumenti e alle risorse necessari per supportare decisioni informate.
È inoltre fondamentale che il management abbia fiducia nei propri team e li metta nelle condizioni di agire in autonomia, permettendo loro di prendere decisioni all’interno delle rispettive aree di competenza. Coltivando un ambiente in cui l’esecuzione è responsabilizzata, i team diventano più agili e reattivi di fronte a sfide e opportunità.
In Buildo, l’empowered execution è alla base del nostro modo di costruire prodotti software. Nel processo di governance dei nuovi progetti, poniamo particolare attenzione all’autonomia decisionale, alla responsabilità, alla trasparenza e alla comunicazione aperta tra i membri del team. L’approccio Open Book management consente ai team di agire con maggiore rapidità e rappresenta un vero e proprio abilitatore del principio di esecuzione responsabilizzata.
Rubber duck opening a book while working at a computer on Mars — Midjourney
In conclusione, costruire team efficaci nello sviluppo software è un processo complesso che richiede un approccio riflessivo e strategico, basato sull’unità, su obiettivi condivisi e su un ambiente che favorisca la crescita e l’apprendimento.
Fare leva su principi come empowered execution, open book management e integrità concettuale, e al tempo stesso abbracciare le caratteristiche distintive dei jelled teams, può portare a team di sviluppo ad alte prestazioni, capaci di affrontare progetti complessi.
Guardando la questione da un’altra prospettiva, le organizzazioni devono anche rimanere vigili nell’identificare e contrastare il teamicide, ovvero quei comportamenti dannosi come la mancanza di allineamento sugli obiettivi, la separazione fisica, gli straordinari eccessivi, la gestione difensiva, la burocrazia e le metodologie eccessivamente prescrittive.
Ci auguriamo che i contenuti presentati in questo articolo, insieme all’esperienza di Buildo, possano rappresentare una guida utile per chi è impegnato a costruire e mantenere team solidi ed efficaci nel settore dello sviluppo software.
1. McChrystal, Gen Stanley, et al. Team of teams: New rules of engagement for a complex world. Penguin, 2015.
2. DeMarco, Tom, and Tim Lister. Peopleware: productive projects and teams. Addison-Wesley, 2013.
3. Brooks Jr, Frederick P. The mythical man-month: essays on software engineering. Pearson Education, 1995.
4. Skelton, Matthew, and Manuel Pais. Team topologies: organizing business and technology teams for fast flow. It Revolution, 2019.
5. Driskell, J. E., and E. Salas. Collective behavior and team performance. Human Factors , 34(3), 277–288, 1992.
Claudio, a partner at Buildo, is a Software Engineer and Entrepreneur with extensive machine learning experience. As the former CTO of Banksealer, he led the technical team, and now concentrates on strategic business development to drive growth and expand Buildo's market presence.
Ogni mese scegliamo articoli utili ma anche idee fresche e stimolanti. Proprio quello che vorremmo trovare noi in una newsletter!
