Team Topologies: organizzare i team intorno al flusso di valore

Il modo in cui un'organizzazione struttura i suoi team determina come il valore si muove al suo interno. Eppure, in molte realtà, quella struttura è il riflesso di come l'organizzazione è cresciuta: attorno a linguaggi, tecnologie, confini tra reparti. Team Topologies, il framework di Matthew Skelton e Manuel Pais, porta a chiederci: i nostri team sono organizzati per far fluire il valore o per preservare competenze tecniche isolate?

Il problema: team organizzati per componente

In molte organizzazioni, i team sono strutturati per strato tecnologico: un team frontend, un team backend, un team database, un team API. Ogni modifica attraversa più team prima di arrivare al cliente. Il risultato è prevedibile: "handoff" continui, priorità contrastanti e un senso diffuso di lentezza. I team perdono la visibilità sull'impatto del proprio lavoro e la motivazione diminuisce.

Questa dinamica ha un nome. La Legge di Conway dice che un sistema software tende a riprodurre la struttura di comunicazione dell'organizzazione che lo progetta. Se i team comunicano attraverso passaggi burocratici, anche il sistema avrà passaggi burocratici al suo interno. La struttura organizzativa determina la qualità del sistema che ne consegue.

Il costo più alto emerge quando un team dipende da tre o quattro gruppi diversi prima di rilasciare una funzionalità. Ogni passaggio aggiunge tempo, introduce rischio di interpretazioni divergenti e riduce la motivazione del team, che non vede mai il risultato del proprio lavoro.

Cosa sono le Team Topologies

Team Topologies ci aiuta a progettare la struttura dei team in modo che il flusso di valore sia il più continuo possibile. Pubblicato da Matthew Skelton e Manuel Pais, il modello ha trovato applicazione in organizzazioni di ogni dimensione, dalle startup alle grandi aziende, perché offre un linguaggio comune per discutere di struttura organizzativa senza cadere in modelli rigidi o prescrittivi.

L'idea centrale è che la struttura dei team va trattata come una decisione di progettazione esplicita, da rivedere periodicamente e da allineare al flusso di valore che si vuole ottenere.

In questa progettazione viene preso in considerazione anche il carico cognitivo. Ogni team ha una capacità limitata di assorbire informazioni complesse. Quando un team deve occuparsi di troppi domini, tecnologie e contesti diversi, la qualità delle decisioni peggiora. Team Topologies affronta questo problema aiutando a distribuire il carico cognitivo, in modo che ogni team possa operare entro un perimetro che conosce bene.

Skelton e Pais distinguono quattro topologie fondamentali di team, con responsabilità e confini diversi, e tre modalità di interazione tra loro. In generale, ogni team dovrebbe essere composto da 5 a 9 persone.

Le quattro topologie fondamentali

Stream-aligned team

Lo "stream-aligned team" è la topologia predefinita e consiste in un team allineato a un flusso di lavoro specifico: un prodotto, un servizio, una funzionalità o un percorso utente. Questo team ha tutte le competenze necessarie per operare in modo autonomo entro quel perimetro. Funziona come un piccolo team Scrum che possiede un frammento di valore end-to-end, dalla discovery al rilascio, e non deve attendere che un altro team completi una dipendenza per procedere.

Uno stream-aligned team ha un Product Owner che conosce il dominio, sviluppatori che coprono le competenze necessarie e un modo diretto di interfacciarsi con gli utenti.

La maggior parte dei team in un'organizzazione dovrebbe essere stream-aligned. Quando questa topologia è l'eccezione invece che la regola, la struttura organizzativa sta frammentando il valore.

Enabling team

L'"enabling team" aiuta gli stream-aligned team ad acquisire competenze che ancora non hanno, intervenendo in modo temporaneo o periodico con l'obiettivo di rendere l'altro team autonomo.

Un enabling team lavora a fianco degli stream-aligned team per un periodo predefinito, insegnando pratiche, strumenti o tecniche specifiche. Per esempio, può aiutare un team a migliorare le proprie pratiche di test automatici, introdurre deployment continui o adottare un nuovo framework. Una volta che il team ha acquisito l'autonomia, l'enabling team si sposta altrove.

La differenza rispetto a un modello tradizionale di "center of excellence" è sostanziale. Il centro di eccellenza tende a produrre standard e linee guida che i team devono adottare. L'enabling team lavora dentro i team, risolvendo problemi reali e trasferendo competenze in modo contestuale.

Complicated-subsystem team

Alcuni domini richiedono una conoscenza specialistica che ha poco senso distribuire in ogni team. Un sistema di rendering 3D, un motore di raccomandazione basato su "machine learning" o un protocollo crittografico rientrano in questa categoria.

Il "complicated-subsystem team" è un team piccolo di esperti che ha la responsabilità su un sottosistema complesso e si interfaccia con gli altri team attraverso un contratto chiaro e stabile. Gli stream-aligned team sanno cosa aspettarsi dall'interfaccia senza dover capire come funziona internamente.

Questa topologia va usata con parsimonia. Ogni complicated-subsystem team introduce un punto di coordinamento aggiuntivo. Se utilizzato in sostituzione, o dove basterebbe un enabling team temporaneo, rischia di creare un collo di bottiglia permanente.

Platform team

Il "platform team" costruisce e mantiene una piattaforma interna che gli stream-aligned team consumano in modo autonomo. L'obiettivo è ridurre il carico cognitivo dei team, offrendo loro servizi pronti all'uso.

La piattaforma viene trattata come un prodotto, con propri utenti (gli stream-aligned team), un Product Owner che ne comprende i bisogni e un ciclo di feedback continuo. Le API, gli strumenti e i servizi devono essere auto-servibili, documentati e stabili.

Un platform team efficace è praticamente invisibile per i suoi utenti finali. Quando funziona al meglio, gli stream-aligned team trovano la documentazione, consumano il servizio e continuano il loro lavoro senza dover contattare il team.

La piattaforma può anche essere un insieme di pratiche e strumenti che riducono la complessità per chi deve consegnare valore. Non deve essere necessariamente una soluzione tecnica.

Le tre modalità di interazione

Le topologie definiscono il tipo di team. Le modalità di interazione definiscono come i team collaborano tra loro.

Collaboration: due team lavorano insieme per un periodo limitato su un obiettivo comune. Questa modalità funziona bene per scoprire soluzioni innovative o risolvere problemi complessi che nessuno dei due riuscirebbe ad affrontare da solo. Richiede un "timebox" chiaro, perché senza confini temporali la collaborazione tende a diventare permanente e i team rischiano di perdere la propria autonomia.

X-as-a-Service: un team fornisce qualcosa a un altro team con il minimo coordinamento necessario. Il rapporto è definito da un'interfaccia, una documentazione e accordi sul livello di servizio. Questa modalità funziona bene quando i confini tra i team sono chiari e le responsabilità sono ben definite.

Facilitating: un team aiuta un altro a sviluppare nuove capacità. L'enabling team usa questa modalità per default: insegna, affianca e poi si ritira. Il successo si misura dall'autonomia che il team assistito raggiunge.

Reverse Conway Maneuver

Il "Reverse Conway Maneuver" inverte la direzione della Legge di Conway. Invece di accettare che la struttura organizzativa plasmi passivamente l'architettura, si riorganizzano i team per ottenere l'architettura desiderata.

Per esempio, se un'organizzazione vuole passare a un'architettura a microservizi, bisogna creare team allineati ai "bounded context" del dominio, ognuno responsabile di un servizio specifico. La nuova architettura diventa una conseguenza della nuova struttura dei team.

Il primo passo per applicare il Reverse Conway Maneuver è capire dove si trova il flusso di valore. Il Value Stream Mapping è lo strumento giusto per questo: rende visibile il percorso che il valore compie attraverso l'organizzazione, rivela dove si accumulano attese e sprechi, e indica quali sono i confini naturali intorno a cui allineare i team.

Da dove iniziare

Team Topologies si può introdurre in modo graduale, senza necessità di una riorganizzazione su larga scala dall'oggi al domani. Il metodo suggerito da Skelton e Pais prevede di partire dai flussi di valore e costruire la struttura intorno a essi. In pratica:

1. Identificare i flussi di valore principali dell'organizzazione. Ogni flusso corrisponde a un percorso che parte da un bisogno del cliente e arriva a un risultato riconoscibile.
2. Creare stream-aligned team come configurazione predefinita. Ogni team assume la responsabilità di un flusso.
3. Aggiungere enabling team, platform team o complicated-subsystem team solo quando servono.
4. Definire le modalità di interazione per ogni coppia di team.
5. Rivedere periodicamente la struttura. Ogni trimestre può essere una cadenza ragionevole.

L'importante è iniziare con un flusso alla volta, evitando di voler riorganizzare tutto contemporaneamente. Un approccio incrementale permette di correggere la rotta man mano che si impara.

Team Topologies e Scrum

Team Topologies e Scrum operano su piani diversi e sono complementari. Team Topologies descrive come organizzare i team in relazione tra loro. Scrum descrive come un singolo team opera al proprio interno.

Uno stream-aligned team corrisponde naturalmente a uno Scrum Team. Ha un Product Owner che è responsabile del flusso di valore, sviluppatori con le competenze necessarie per portare un'iniziativa dalla scoperta al rilascio, e uno Scrum Master che aiuta il team a migliorare il proprio modo di lavorare.

In un contesto tradizionale, il Product Owner gestisce il backlog ma dipende da altri team per la consegna. In un contesto Team Topologies, il PO di uno stream-aligned team ha il controllo sull'intero flusso, dalla priorità al rilascio.

Errori comuni

Il più frequente è trattare gli enabling team come centri di competenza permanenti. Un enabling team che si protrae nel tempo sta togliendo autonomia agli stream-aligned team invece di crearla.

Un altro errore è usare la modalità collaboration senza un timebox. Due team che collaborano senza una scadenza chiara finiscono per dipendere l'uno dall'altro in modo permanente, vanificando il vantaggio della separazione.

Creare un platform team senza ascoltare i potenziali utenti è altrettanto problematico. Una piattaforma interna che nessuno usa consuma risorse, produce strumenti disallineati e genera frustrazione.

C'è anche l'errore opposto: creare troppi team specializzati. Quando ogni competenza viene incapsulata in un team separato, il costo di coordinamento cresce più del valore che la specializzazione porta. La topologia complicated-subsystem va usata solo quando il dominio è oggettivamente complesso.

Infine, dimenticare che la struttura va rivista. Un'organizzazione che ha definito le proprie team topologies due anni fa e le ha mantenute invariate probabilmente sta operando con una struttura che non riflette più il lavoro di tutti i giorni.

In pratica

Team Topologies offre un modo di pensare la struttura organizzativa come una variabile di progetto. Richiede di osservare come il valore si muove oggi, identificare dove si ferma e creare le condizioni per farlo fluire in modo più continuo.

La struttura dei team è uno dei fattori che determina il successo di un'organizzazione. Quando è sbagliata, nessun miglioramento locale può compensare il costo dei passaggi, delle attese e del carico cognitivo che genera. Iniziare a vedere i team come unità di valore è il primo passo.

La struttura dei team è una variabile organizzativa prima ancora che tecnica. Quella giusta permette al valore di fluire senza interruzioni.