Team piccoli, stabili e il concetto di micro tech debt

Lo sviluppo software oggi è un’attività intrinsecamente collaborativa e complessa. Con i microservizi, le architetture distribuite, la complessità non sta più nel singolo algoritmo, ma nelle interazioni tra sistemi e tra le persone che li costruiscono. In contesti come questi, secondo Google [2], le dinamiche di team contano più dei singoli individui che lo compongono. Il lavoro non viene assegnato alla persona, ma al team, che diventa l’unità operativa minima [1]. Se il team è l’unità fondamentale, cosa lo può rendere efficace? La risposta sta in due proprietà semplici in teoria, ma difficili da mantenere: dimensione ridotta e stabilità nel tempo.

Perché i team devono restare piccoli

L’efficienza di un team dipende dalla qualità della comunicazione interna. Più persone ci sono, più canali di comunicazione esistono, più overhead si genera. Non è un caso che Amazon abbia formalizzato la regola delle “two-pizza teams” [3]: se non puoi sfamare il team con due pizze, è troppo grande. Un team piccolo (tipicamente sotto le 9 persone) mantiene alta la fiducia reciproca. E’ il prerequisito per sperimentare, per proporre idee, per ammettere errori senza paura. Ma un team piccolo che cambia composizione ogni mese non svilupperà mai quella fiducia. La dimensione, da sola, non basta.

Perché i team devono restare stabili

I team hanno bisogno di tempo per diventare coesi. Cambiare continuamente la composizione significa ripartire ogni volta da zero, perdendo la velocità che si acquisisce solo quando le persone si conoscono davvero. Un team stabile sviluppa ownership sul codice che produce [4]. E qui la parola “ownership” va intesa come “caretaking”, non come “gatekeeping”. Altri team possono collaborare, ma la responsabilità finale resta chiara. Quando un team possiede un sistema e ha l’autonomia di pianificare almeno parte del proprio lavoro può prendere decisioni a breve, medio e lungo termine in modo coerente. Ha il contesto per farlo.

Ownership come responsabilità condivisa

Se più team lavorano sullo stesso sistema senza una ownership chiara, nessuno si sente realmente responsabile. Il codice accumula decisioni che nessuno ricorda di aver preso. Il “mess” cresce, e nessuno si sente in dovere di ripulirlo. Ma un team con vera ownership ha una flessibilità che gli altri non hanno. Può permettersi di introdurre quello che possiamo chiamare “micro tech debt”: soluzioni temporaneamente subottimali, introdotte consapevolmente, con l’intenzione esplicita di rimuoverle nel giro di giorni o settimane. Non parlo del tech debt classico, quello che si accumula negli anni e diventa un incubo. Parlo di scelte pragmatiche: “questo fix è brutto, ma ci permette di andare in produzione oggi. Lo sistemiamo la prossima settimana.”

Il micro tech debt funziona solo se:

• Il team ha ownership del codice (sa cosa sta introducendo e dove)
• Il team ha capacità di pianificazione (può allocare tempo per rimuoverlo)
• Il team ha memoria condivisa (nessuno dimentica che quel fix è temporaneo)

Sono esattamente le condizioni che un team piccolo e stabile possiede naturalmente. In questo contesto, il micro tech debt diventa uno strumento. Permette di muoversi più velocemente senza sacrificare la qualità nel lungo periodo. E paradossalmente, rafforza l’ownership: il team che introduce un fix temporaneo e lo rimuove dopo una settimana sente di avere il controllo del proprio codice.

Conclusione

Prima di pensare a pratiche, tool o metodologie, bisogna costruire le condizioni perché un team possa funzionare. Team piccoli, stabili, con ownership chiara. E quando quelle condizioni esistono, si scopre che anche l’imperfezione consapevole può diventare uno strumento.

Riferimenti

[1] Matthew Skelton, Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow (IT Revolution Press, 2019). [2] Julia Rozovsky, “The Five Keys to a Successful Google Team,” Google re:Work, 17 novembre 2015. [3] Jason Crawford, “Amazon’s ‘Two-Pizza Teams’: The Ultimate Divisional Organization,” jasoncrawford.org, 30 luglio 2013. [4] Per approfondire il tema della ownership e dei team stabili: Jez Humble, Joanne Molesky, Barry O’Reilly, Lean Enterprise (O’Reilly Media, 2015).