Tutto quello che ho imparato su Team Topologies

Stabile e veloce non sono più alternative

Per avere successo, le moderne organizzazioni IT devono affidarsi a sistemi software facili da utilizzare e che siano anche sicuri e affidabili. Allo stesso tempo questo tipo di organizzazioni devono poter crescere e adattarsi alle pressioni dell’ambiente circostante: cambiamenti di mercato, di legislazione, innovazioni tecnologiche. Non è più possibile scegliere in modo binario tra l’ottimizzazione per la stabilità e l’ottimizzazione per la velocità. Servono entrambe, contemporaneamente.

Affrontare la complessità in modo efficace non è alla portata dei singoli. Soltanto il lavoro in team, la cui efficacia è maggiore della somma dei contributi dei singoli, garantisce velocità, qualità e capacità di adattamento. Prestiamo attenzione a questo concetto:

I team non vanno considerati collezioni di persone intercambiabili tra di loro nella convinzione che, per avere successo, sia sufficiente utilizzare i “giusti” processi e strumenti calati dall’alto.

Affidarsi a organigrammi, linee di riporto e KPI, per suddividere e controllare il lavoro delle persone in maniera top-down, porta a false aspettative. Al contrario, i team vanno visti come sistemi “socio-tecnici” umano-computer, carbonio-silicio, intrinsecamente motivati dalla più ampia autonomia di autodeterminazione, e da una chiara visione. Costruire e operare sistemi software è un’attività socio-tecnica, non una catena di montaggio come in una fabbrica.

Organigrammi e re-organizzazioni

Uno dei grossi problemi degli organigrammi è che pretendono di incanalare i flussi comunicativi lungo le linee di riporto: i collegamenti gerarchici. Ma le persone e i team, per lavorare efficacemente, non si basano solo sui quei collegamenti. Al contrario, comunicano con chiunque dipendano per andare avanti col proprio lavoro, piegando o eludendo le regole imposte per raggiungere i propri obiettivi. Un organigramma è sempre de-sincronizzato con la realtà; è una rappresentazione ideale, approssimata, illusoria e soggetta a rapidissima obsolescenza.

Limitarsi ai canali di comunicazione ufficiali lungo le linee di riporto è un modo efficace per paralizzare completamente un’organizzazione (un divertente approfondimento sul “>Simple Sabotage Field Manual” lo ha scritto Jacopo Romei in questo articolo).

Le decisioni basate su organigrammi tendono inoltre a creare ottimizzazioni locali, che ignorano gli effetti su altre parti dell’organizzazione, e spesso mortificano la produzione di valore per i clienti/utenti.

Anni di tentativi e anti-pattern

Negli ultimi decenni ci sono stati molti tentativi di superare gli organigrammi tradizionali (per esempio con le organizzazioni matriciali, ove ciascuna persona riporta sia a un business che a un functional manager). Nonostante miglioramenti sul piano del focus sul valore di business rispetto a un approccio puramente funzionale, questo tipo di struttura è ancora una visione statica che diventa obsoleta mentre il dominio di business e la tecnologia evolvono. Si assiste a una frenesia della riorganizzazione alla “prova e spera“, che causa preoccupazioni, paura, drena tempo ed energie. Il management inoltre, che è ansioso di vedere risultati a breve termine, non attende nemmeno di osservare razionalmente gli effetti di una riorganizzazione, che è già tempo di cominciare la prossima, facendo saltare per aria quel poco di positivo che aveva appena iniziato a consolidarsi.
Altro comune anti-pattern è l’applicazione acritica di modelli “alla moda” tipo Spotify, adottati senza comprenderne l’origine, lo scopo, la cultura, le dinamiche.
È essenziale che le organizzazioni tengano conto della loro specificità, e della loro evoluzione nel tempo, piuttosto che dedicarsi all’estemporanea applicazione di modelli statici in modo decontestualizzato.

Legge di Conway

Nel contesto di una sua ricerca intitolata “How committees invent? – 1968“, il pioniere della programmazione Mel Conway esplorò la relazione tra le strutture organizzative e il risultante design dei sistemi software, formulando la sua celebre legge:

“Le organizzazioni che disegnano sistemi sono vincolate a produrre design che sono copie delle propria struttura comunicativa”.

Nel 2015, James Lewis, Tech Director in ThoughtWorks propose l’idea della “Manovra di Conway Inversa“:

Un’organizzazione deve concentrarsi nel definire strutture di team che siano precursori dell’architettura che si vuole ottenere, e non subire passivamente l’effetto opposto descritto dalla legge di Conway.

Infatti, ordinare a team preesistenti di perseguire un’architettura incompatibile con la loro struttura organizzativa, e pensare che un qualunque gruppo di team sia in grado di produrre qualunque architettura arbitraria, è un approccio destinato a fallire. Da questa constatazione deriva un corollario alla legge di Conway:

“Se l’architettura del sistema e l’architettura dell’organizzazione sono in contrasto, l’architettura dell’organizzazione vince sempre”.

Organizzazione e sistema software: come comportarsi?

In particolare, un’organizzazione che è strutturata in silos funzionali (DBA, QA, BE, FE, ecc.) è improbabile che riesca a produrre sistemi software efficaci nel gestire flussi end-to-end. Infatti, sempre Mel Conway, nel suo articolo del 1968, osservava che “Data una particolare struttura organizzativa, esiste una classe di possibili design che non possono essere esplorati da quella particolare organizzazione, perché i necessari flussi comunicativi non esistono”. I flussi comunicativi dentro un’organizzazione (che combacino o meno con le formali linee di riporto dell’organigramma) restringono inevitabilmente i tipi di soluzione che l’organizzazione è in grado di concepire.
Se si decide di strutturare un’organizzazione col fine di ottenere una specifica architettura del sistema, ne consegue che i tecnici devono avere voce in capitolo nelle decisioni che riguardano la composizione e le responsabilità dei team. Se si lascia che siano i manager e i dipartimenti HR decidere quali parti di un sistema vengono realizzate da quali team, e come i team sono composti, stiamo implicitamente dando ai manager e ai dipartimenti HR la responsabilità di definire l’architettura del sistema. Quanta consapevolezza hanno i dipartimenti HR circa i sistemi software?
Riorganizzazioni che non tengano conto della legge di Conway e delle dinamiche di team, rischiano di avere effetti simili alla cardiochirurgia operata da un bambino: altamente distruttiva.

Carico cognitivo e colli di bottiglia

C’è un limite alla quantità di informazioni che possono essere contenute in un cervello umano in un dato momento. Lo stesso vale per un team, il cui limite è dato dalle capacità cognitive combinate dei singoli membri.
Carico cognitivo è un concetto teorizzato dallo psicologo John Sweller nel 1988 come

“La quantità totale di sforzo mentale usato nella memoria di lavoro”.

Sweller definì 3 tipi di carico cognitivo:

1. Intrinseco: relativo ad aspetti fondamentali del task eseguito nello spazio del problema, ad esempio “Quale deve essere la struttura di questa classe Java?” oppure “Come creo questo nuovo metodo?“.
2. Esterno: relativo all’ambiente in cui un task viene eseguito, ad esempio “Come faccio a fare deploy di questo componente?“ oppure “Come configuro il servizio?“.
3. Attinente: relativo ad aspetti del task che necessitano di attenzione speciale all’apprendimento o ad elevate performance, ad esempio “Questo servizio come deve interagire col servizio X?” oppure “Questo bugfix che impatto avrà su quell’altra porzione di codice?“.

Come fare per contenere il carico cognitivo?

In linea generale, le organizzazioni dovrebbero cercare di:

• Minimizzare il carico cognitivo intrinseco (attraverso l’assunzione delle persone giuste, il training, le buone scelte tecnologiche, il pair programming, ecc.).
• Eliminare del tutto il carico cognitivo esterno (costituito, di fatto, da task noiosi o superflui, o da operazioni che non aggiungono valore al prodotto realizzato, occupando invece preziosa memoria di lavoro, e che possono spesso essere automatizzate).
• Lasciare spazio per il carico cognitivo attinente, perché è quello in cui si genera creatività spesso non pianificata e quindi positivi incrementi di valore del prodotto.

Come operare per ridurre i carichi cognitivi intrinseci ed esterni?

• Fornendo un ambiente di lavoro (fisico o virtuale) costruito attorno al team
• Minimizzando le distrazioni, limitando i meeting, riducendo le email, assegnando (anche a turno) una singola persona al supporto e alle richieste esterne, e così via.
• Fare in modo che il management comunichi col team in forma di goal e outcome, invece che di task e micromanagement.
• Usando piattaforme, che sono esplicitamente disegnate per semplificare la vita e ridurre il carico cognitivo per i team che ci costruiscono sopra un prodotto/servizio.
• Aumentando la qualità della vita degli sviluppatori che utilizzano i servizi realizzati dal team, tramite approccio ad API, buona documentazione, consistenza, UX: più gli sviluppatori esterni hanno la vita facilitata, meno il team sarà subissato di richieste di aiuto e chiarimento. Minimizzare il carico cognitivo per gli altri (utenti finali, sviluppatori di altri team) è una delle migliori strategie per uno sviluppo software efficace.
• In particolare l'”approccio ad API” non deve limitarsi soltanto a come il team produce software, ma anche a come il team si pone verso l’esterno, a tutte le sue interazioni con gli altri team e utenti, ad esempio mostrando all’esterno, anche tramite l’uso di information radiators:
  • Codice: endpoints, librerie, UI prodotte dal team.
  • Versionamento: come il team comunica i cambiamenti al suo codice e ai servizi esposti (versionamento semantico, come una promessa che il team fa di non “rompere le cose”).
  • Wiki e documentazione: in special modo guide “how-to” per il software che il team realizza.
  • Principi e pratiche: quali sono i modi di lavoro che il team preferisce utilizzare.
  • Comunicazione: qual è l’approccio del team all’uso dei tool per la comunicazione remota (chat, video call, ecc.).
  • Informazioni sulle attività in corso: su cosa il team sta lavorando in ogni momento, cosa farà prossimamente, e le sue priorità nel breve e medio termine.

Attenzione a sottovalutare il carico cognitivo di un team

Quando il carico cognitivo non viene considerato, i team vengono sovraccaricati con un’eccessiva quantità di responsabilità e domini.

In questo modo non viene lasciato spazio per raggiungere sufficiente padronanza del dominio e degli strumenti, sufficiente qualità, e le persone soffrono di context switching, causando dispersione di energie, ritardi nelle consegne, calo di qualità, demotivazione. Il team smette di essere un’unità coesa e inizia a comportarsi come un gruppo di individui blandamente associati, ciascuno dei quali cerca di completare i propri task individuali senza spazio per valutare se questi siano nel migliore interesse del team o dell’organizzazione.

Tuttavia non si discute praticamente mai di carico cognitivo quando vengono assegnate responsabilità o parti di software a un dato team. La pianificazione di nuovi prodotti e servizi è spesso condotta come se i team fossero disponibili h24 e avessero carico cognitivo nullo con cui partire. Questa incuria è problematica perché ai team, tipicamente, viene sempre richiesto di mantenere ed estendere prodotti e servizi già esistenti. Alla fine il team diventa un collo di bottiglia, perché la sua capacità cognitiva è stata largamente superata.
Limitare il carico cognitivo di un team significa quindi anche limitare la dimensione del sistema software di cui il team è responsabile, e quindi l’organizzazione non dovrebbe permettere a un sistema di crescere oltre il carico cognitivo del team che ne sarà responsabile.

Come valutare il carico cognitivo di un team?

Un semplice modo di valutare il carico cognitivo è di chiedere al team: “Sentite di essere efficaci e in grado di eseguire in maniera accurata e tempestiva il lavoro che vi viene richiesto di svolgere?“. Benché questa non sia una misura accurata, la risposta alla domanda aiuterà a misurare se il team si sente sovraccaricato. È fuorviante tentare di valutare il carico cognitivo imposto al team da un sistema software usando misure semplici come le linee di codice, il numero di classi, metodi, o di librerie da cui dipende.

Comunichiamo troppo, collaboriamo troppo

Un’implicazione chiave della legge di Conway è che non tutta la collaborazione e la comunicazione sono buone. Molte organizzazioni danno per scontato, si vantano o addirittura fanno un mantra del fatto che i loro team comunicano e collaborano il più possibile. Non è così. Henrik Kniberg, in “Real Life Agile Scaling”, vede la comunicazione in questo modo:

• All’interno dei singoli team: larghezza di banda comunicativa larga.
• Tra team “accoppiati” (che lavorano esplicitamente sulla stessa codebase): larghezza di banda comunicativa media.
• Tra la maggior parte di team: larghezza di banda comunicativa limitata o zero.

La comunicazione richiede tempo ed energie alle persone. Secondo la “Legge di Brooks“, che prende il nome dall’informatico Fred Brooks:

“Il costo della comunicazione in un team aumenta con il quadrato delle persone che compongono il team”.

È necessario perseguire una comunicazione focalizzata, specifica e consapevolmente definita; quindi osservare l’organizzazione e capire le cause di comunicazione non prevista. Se un’organizzazione è in grado di ottenere una comunicazione tra team che richiede una larghezza di banda limitata, o addirittura zero banda, e nonostante questo realizza e rilascia software in maniere sicura, efficace e rapida, allora dovrebbe percorrere questa strada.

Non tutti devono comunicare con tutti. Se “tutti devono leggere i messaggi in chat” o “tutti devono partecipare allo stand-up meeting generale” o ancora “tutti devono essere presenti ai meeting di allineamento” sono diktat imposti dall’organizzazione, siamo in presenza di sintomi di cattivo design organizzativo, che tenderà a produrre sistemi monolitici, aggrovigliati, altamente accoppiati e interdipendenti, che non supportano un’efficace produzione di valore per gli utenti finali.

È possibile migliorare la comunicazione organizzando opportunamente gli spazi di lavoro?

Limitare o agevolare la comunicazione è possibile tramite un’attenta scelta degli ambienti di lavoro (fisici o virtuali) e degli strumenti di collaborazione (fisici o digitali).
Pensiamo a scelte deliberate quali l’uso di open space piuttosto che di stanze dedicate ai singoli team piuttosto che cubicoli individuali. A quali team mettere in uno stesso open space, quali in stanze attigue piuttosto che distanti, quali addirittura nello stesso piano di un edificio piuttosto che in piani diversi, edifici diversi, ubicazioni geografiche diverse.
Talvolta persone differenti hanno bisogno di ambienti differenti o tempi differenti per essere produttive. Dovrebbero essere le persone a poter scegliere di volta in volta l’ambiente per loro più confortevole in ogni momento.
Una configurazione efficace degli uffici dovrebbe rendere quindi disponibili multiple soluzioni per multipli modi di lavorare:

• Individualmente, focalizzato.
• Collaborativamente intra-team.
• Collaborativamente cross-team.

Gli strumenti di lavoro che si utilizzano influenzano la comunicazione?

Anche la scelta degli strumenti di lavoro guida i pattern comunicativi. Talvolta le organizzazioni hanno molteplici strumenti, quando uno solo basterebbe. Altre volte un solo strumento è in uso, e questo crea problemi tra team che beneficerebbero ognuno del suo strumento individuale.
Se si desidera che due team collaborino, allora uno strumento condiviso ha senso. Se si desidera instaurare un chiaro confine di responsabilità tra due team, allora strumenti separati (o al limite istanze diverse dello stesso strumento) potrebbero essere la soluzione migliore.
Esempio: avere due sistemi di ticket management diversi per un team di sviluppo e un team IT che lavorano allo stesso prodotto, è probabile risulti in una comunicazione scadente tra i due team.
Allo stesso modo, potrebbe essere controproducente avere uno strumento “solo di produzione” riservato esclusivamente a team con particolari livelli di accesso privilegiato agli ambienti di produzione.
Come regola generale, andrebbero usati strumenti diversi per team indipendenti tra di loro, e strumenti condivisi per team che collaborano tra di loro.
Generare veloci flussi di valore richiede di restringere il più possibile la comunicazione tra i team a quella strettamente indispensabile, e non di incentivarla indistintamente. La comunicazione tra team è importante per le aree grigie dello sviluppo, quando l’esplorazione e le competenze delle persone sono richieste per progredire. Ma nelle fasi in cui l’incertezza è stata superata, la complessità esplorata, e arriva il momento di accelerare la costruzione del prodotto, la comunicazione può diventare un costo non necessario.

Come gestire la comunicazione “extra” lavoro?

Un diverso discorso merita invece la comunicazione che avviene al di fuori del lavoro quotidiano di realizzazione e operatività dei sistemi responsabilità del team. In questo caso la legge di Conway gioca un ruolo assai meno vincolante, e liberi scambi tra diversi team e tra persone appartenenti a diversi team possono avvenire in modo positivo. È importante fornire tempo, spazio e denaro per abilitare ed incoraggiare persone con skill o interessi comuni ad incontrarsi per imparare reciprocamente e sviluppare le loro competenze professionali. In questo modo le organizzazioni possono rendere l’apprendimento e la costruzione di fiducia tra le persone parte del normale ritmo lavorativo (dando spazio a un tipo di comunicazione che compensa le restrizioni comunicative attuate in precedenza, che possono oggettivamente risultare ostiche a qualcuno quando si inizia ad implementare un simile approccio).
Alla fine, i team che si occupano di tecnologia devono investire per apprendere, sperimentare, e poi portare nel lavoro quotidiano pratiche come la Continuous Delivery, Test-first Development, operability, affidabilità, security. Senza queste pratiche, tutti gli sforzi investiti per costruire una migliore architettura organizzativa saranno largamente insufficienti per mancanza della basi, dopotutto il 9° principio dell’Agile Manifesto recita le seguenti parole:

“Continuous attention to technical excellence and good design enhances agility”.

Prima i team

Inizio riportandovi una citazione di Allan Kelly:

“Dissolvere team altamente performanti è peggio del vandalismo: è psicopatia aziendale”.

Team che lavorano come unità coese rendono molto meglio di collezioni di individui, quando si tratta di attività ricche di conoscenza, che necessitano di problem solving e di processare grandi quantità di informazioni.

Nello sviluppo software la velocità, la frequenza, la complessità e la diversità degli interventi richiesti dai moderni sistemi software significano che i team sono essenziali. Affidarsi a singoli individui per comprendere e avere a che fare col volume e la natura delle informazioni da elaborare non è sostenibile. I team contano molto di più dei singoli: chi fa o non fa parte di un team conta molto meno delle dinamiche di team.

Team di massimo 15 persone: il Numero di Dunbar

Un team dovrebbe essere un gruppo stabile costituito da un minimo di 5 a un massimo di 9 persone che lavorano verso un obiettivo condiviso. L’antropologo Robin Dunbar, in uno studio degli anni ’90 che lo portò a teorizzare il Numero di Dunbar, osservò che 15 è il limite di persone di cui ciascuno di noi può fidarsi, e, tra queste, soltanto di 5 ci si può fidare in modo profondo e completo.
Team di tali dimensioni aiutano le organizzazioni a raggiungere uno dei loro obiettivi fondamentali: massimizzare la fiducia tra le persone. Mantenere alti livelli di fiducia è ciò che consente a un team di sperimentare ed innovare. Se la fiducia manca o non è sufficiente a causa di un gruppo troppo grande, la velocità e la sicurezza del rendimento ne soffriranno.
Organizzazioni con elevati livelli di fiducia possono anche sostenere team di dimensioni più grandi, da una a massimo di 15 persone. Tuttavia è bene che i team grandi non siano creati già con quella dimensione, ma nascano da un team maturo di 5-9 a cui aggiungere gradualmente nuovi membri.
I limiti dettati dal Numero di Dunbar si estendono anche a gruppi di team, dipartimenti, business unit, e così via

• 5 – 9 persone (team piccolo): limite di persone in grado di mantenere strette relazioni personali e memoria di lavoro.
• 9 – 15 persone (limite di dimensione di un team in organizzazioni ad alto tasso di fiducia): massimo numero di persone che possono sperimentare fiducia profonda.
• < 50 persone (famiglie, tribù): numero massimo di persone che possono avere fiducia reciproca.
• < 150 persone (divisioni, business unit): il totale delle persone di cui un individuo può ricordare capacità e prerogative.

Stabilità

I team hanno bisogno di tempo per formarsi e diventare altamente efficaci. È necessario fornire stabilità dentro e attorno al team per consentirgli di raggiungere quell’alto livello di efficacia. Non c’è tipicamente alcun beneficio nel riassegnare persone a team differenti se il team ha iniziato a lavorare insieme da 6 mesi ed ha appena cominciato a performare bene. Allo stesso modo, aggiungere persone a un team causa un iniziale decremento delle performance, fintanto che i nuovi membri non vengono coinvolti appieno nella cultura, nelle pratiche e raggiungono lo stesso livello di fiducia dei membri del team preesistenti.
I team devono essere stabili, ma non statici: cambiamenti occasionali nel lungo periodo possono portare benefici come la realizzazione di aspirazioni di persone che vogliono fare esperienze diverse; l’arricchimento di nuove skill; la cross-pollinazione. In organizzazioni con alti livelli di fiducia alcune persone potrebbero cambiare team una volta l’anno (certamente non tutte le persone di uno stesso team ogni all’anno) senza provocare effetti negativi sulle performance dei team.

Ownership

I team devono avere ownership del prodotto/servizio a cui lavorano. La ownership aiuta a fornire la vitale continuità di cura, interesse e responsabilità che i sistemi software moderni necessitano per poter mantenere la loro operabilità e capacità di fornire valore agli utenti finali. Ogni parte di un sistema dovrebbe essere responsabilità di un team solo. I rischi legati al consentire che team multipli effettuino cambiamenti allo stesso sistema o sotto-sistema, non risiedono tanto nel pericolo di conflitti di merge sui repository, bensì nel fatto che nessuno ha responsabilità precisa dei cambiamenti fatti e dei danni in produzione che ne possono derivare.
Ciò significa che non dovrebbero esserci componenti, librerie o codice con ownership condivisa. I team possono usare servizi condivisi a runtime, ma ogni servizio in produzione dovrebbe essere responsabilità di un solo team. Dal di fuori di quel team possono arrivare pull request o suggerimenti di cambiamento, ma le modifiche vere e proprie rimangono responsabilità di quel team. Un team potrebbe anche fidarsi di un altro team e lasciare libertà di azione sulla codebase per un tempo limitato, ma con l’esplicito accordo che la responsabilità di quelle modifiche ricadrà sempre sul team che ha la ownership del componente.

Domini di lavoro per il team e le 4 euristiche

Per meglio definire quali “parti di sistema” sono adatte a determinati team, tenendo conto del carico cognitivo, viene in aiuto il concetto di Dominio (vedere Domain Driven Design – DDD pratico formalizzata da Eric Evans nel suo libro del 2003) e una loro classificazione in:

• Semplici (la maggior parte del lavoro ha un chiaro percorso d’azione).
• Complicati (gli interventi devono essere analizzati e possono richiedere diverse iterazioni e modifiche della soluzione iniziale per essere completati).
• Complessi (soluzioni che richiedono molta attività di sperimentazione ed esplorazione).

Definiti i domini in questi termini, 4 euristiche possono essere usate per la loro assegnazione i team:

1. Prima euristica: assegnare ciascun dominio ad un solo team. Se un domino è troppo grande per un solo team, invece di dividerne le responsabilità su più team, spezzare il dominio in sotto-domini indipendenti ed assegnarne uno per team.
2. Seconda euristica: un singolo team dovrebbe essere in grado di accogliere 2 o 3 domini semplici. Poiché sono semplici e “meccanici”, il costo del context switching sarà limitato, ma al contempo potrebbero sorgere problemi di scarsa motivazione delle persone dovuti alla natura routinaria del lavoro.
3. Terza euristica: un team responsabile di un dominio complesso non dovrebbe aver assegnato alcun altro dominio, anche se semplice.
4. Quarta euristica: evitare che un team sia responsabile di 2 domini complicati.

L’approccio team-first

Seguire un approccio team-first significa non solo costruire l’organizzazione in modo da abilitare i team a prosperare e produrre valore, significa anche assicurarsi che le persone che compongono i team abbiamo la giusta mentalità team-first:

• Rispettando le persone e le loro diversità. Promuovere la diversità è un vantaggio competitivo perché persone diverse tendono a produrre soluzioni più creative più rapidamente.
• Rispettando le regole che il team si dà (orari, coding standards).
• Aiutando proattivamente altri membri del team in difficoltà.
• Essendo mentori per i membri più junior o per i nuovi arrivati.
• Essendo umili nel confronto con gli altri, accettando le opinioni diverse dalle proprie per concorrere verso una visione comune.

Tuttavia ci sono persone che, nonostante il supporto di attività di coaching, si rivelano inadatte a lavorare in team, o non sono disposte a porre le esigenze del team al di sopra delle proprie. Tali persone possono ostacolare il lavoro di team, e in casi estremi distruggere il team stesso. Queste persone sono “tossiche” e dovrebbero essere rimosse prima che compiano danni seri.

Eventuali ricompense (premi produttività, bonus) andrebbero indirizzate al team nel suo complesso, piuttosto che ai singoli individui: cercare di premiare le performance individuali nelle moderne organizzazioni può portare ad ottenere risultati scadenti e a danneggiare il comportamento delle persone mettendole in competizione tra loro. Questo principio non vale solo per i bonus di produttività, ma anche ai budget per la formazione (spesso più importanti dei bonus produttività): il team, non i singoli individui, dovrebbero essere i destinatari dei budget formazione.

Organizziamoci per generare un flusso continuo di valore

Il modo purtroppo prevalente di creare o riorganizzare team è adottare soluzioni affrettate, focalizzate al soddisfare bisogni immediati delle organizzazioni, piuttosto che l’abilità di adattamento futura.
Per essere più efficaci possibile, c’è bisogno di disegnare i team consapevolmente, piuttosto che consentire che si formino a casaccio, guidati dall’urgenza del momento. Ecco due comuni anti-pattern che derivano da tali cattive abitudini:

1. “Ad-hoc” team design: include ad esempio team che sono cresciuti troppo, vengono spezzati quando il sovraccarico comunicativo comincia a pesare, ma i team risultanti continuano a mantenere in condivisione le stesse responsabilità del team originario. Altri esempi sono dati da team che vengono creati per:
   • Badare a una collezione di software legacy da mantenere.
   • Rispondere in conseguenza di un grave crash in produzione (team DBA).
   • Dedicarsi a una nuova feature urgente destinata a un “cliente-a-cui-non-si-può-dire-di-no”.

   Naturalmente simili situazioni vanno affrontate, ma, senza mantenere una visione più ampia, l’effetto è quello di rallentare l’organizzazione invece di renderla più reattiva, e minare il morale delle persone.

2. Continuo rimescolamento dei membri dei team: questo porta a team estremamente volatili assemblati sulla base di progetti temporanei e disassemblati immediatamente dopo. Può sembrare che così facendo l’organizzazione sia flessibile e risponda velocemente al cambiamento, in realtà il costo della formazione di nuovi team e il context switching esigeranno il loro dazio.

Organizziamoci Agilmente

Vecchi metodi organizzativi, con silos funzionali tra differenti dipartimenti, uso massiccio dell’outsourcing, ripetuti passaggi di consegne tra team, non riescono a garantire la sicurezza, la velocità e i necessari cicli di feedback fondamentali per una evoluzione del software adeguata a rispondere alle mutevoli esigenze dei clienti e dei mercati dei nostri giorni. Un modo più efficace è organizzarsi per enfatizzare un rapido flusso di cambiamenti e produzione di valore, dalla concezione del software fino alla sua operatività in produzione.
Le Metodologie Agili ci dicono che lo sviluppo software non può essere un processo unidirezionale analisi->sviluppo->test->deploy->manutenzione, ciascuna delle fasi magari responsabilità di un team diverso. Sarà invece un processo iterativo e incrementale che beneficia largamente di feedback rapido e quindi dell’esposizione dei team agli ambienti di produzione, ai problemi degli utenti, ai problemi di operabilità del software realizzato.

Organizzazioni tradizionali che iniziano ad adottare Metodologie Agili, muovendosi verso release di dimensioni sempre più piccole, possono beneficiare, ad esempio, di un “team DevOps” temporaneo (dove DevOps è un termine usato spesso a sproposito, perché DevOps è un approccio culturale, non un ruolo o un titolo professionale) composto da specialisti che portano esperienza su pratiche e strumenti. Ma senza una chiara missione e una chiara data di scadenza, per un “team DevOps” è facile oltrepassare quella sottile linea che porta all’anti-pattern di avere in casa un silos, un collo di bottiglia che genera continuamente dipendenze e tempi di attesa. Il ruolo di un tale team dovrebbe essere invece quello di “evangelizzatore” che porta conoscenza e mentoring ai team di prodotto, per poi dissolversi quando tutti hanno raggiunto un livello di conoscenza tale da poter andare avanti autonomamente.

Mantenere team il più autonomi possibile

Altro valore chiave perché i team riescano a realizzare un flusso continuo di cambiamenti e di valore è rimanere autonomi facendo in modo che le eventuali dipendenze esterne non siano bloccanti. Ad esempio, è estremamente difficile assicurarsi che un team di Quality Assurance (QA) dedicato sia disponibile a testare una nuova feature esattamente ogni volta che un team di prodotto ne completa la scrittura. Così come un “team DevOps” che sia un semplice “rebranding” di un più tradizionale team di sistemisti, fallirà nel beneficiare della velocità e scalabilità che il moderno cloud sarebbe in grado di garantire. Se il “team DevOps” mima semplicemente i precedenti processi dei team di sistemisti, l’organizzazione impatterà contro gli stessi ritardi e colli di bottiglia precedenti. Al contrario, deve esserci una separazione tra la responsabilità di disegnare processi e infrastrutture (“team QA“, “team  DevOps“) e la responsabilità di testare e mettere in produzione il software (team di prodotto). In questo caso vedremo, a breve, cosa dovrebbero davvero essere un “team QA” o un “team DevOps“.

Tenere sotto controllo le dipendenze tra vari team

Dipendenze non-bloccanti spesso hanno la forma di servizi self-service forniti da altri team (ad es. il provisioning di ambienti di test, la creazione di pipeline di deploy, dashboard di monitoraggio, ecc.). Questi servizi possono essere consumati dai team di prodotto al momento del bisogno.
Man mano che l’organizzazione cresce è tipico vedere team che vengono replicati o ingranditi “buttandoci dentro” nuove persone. Al contrario, prima di aggiungere persone, è importante pensare a quali dipendenze tra team andrebbero rimosse e quali esplicitamente assegnate ai team. Un ragionamento consapevole e razionale sulle dipendenze può essere operato classificando le dipendenze in 3 categorie:

• Dalla conoscenza: “X dipende da Y perché solo Y sa come si fa quella cosa“.
• Dai task: “X dipende da Y perché solo Y può realizzare quella cosa sopra la quale, in un secondo momento, X potrà costruirci sopra“.
• Dalle risorse: “X dipende da Y perché solo Y ha accesso a quella risorsa (ad es. un’area protetta, una pipeline, la creazione di credenziali o certificati, l’acquisto di una licenza o di un componente hardware, ecc.)“.

Creando poi una mappa visuale di team e dipendenze, magari su una grande parete visibile a tutti nell’organizzazione, si potrà innescare una discussione collaborativa sulla loro rimozione o corretta assegnazione.

4 tipologie

Team Topologies propone che in un’organizzazione vengano considerati soltanto 4 tipi di team:

• Stream-Aligned Team
• Platform Team
• Enabling Team
• Complicated-subsystem Team

Le 4 topologie fondamentali dovrebbero agire come delle calamite. Tutti i team di un’organizzazione dovrebbero muoversi verso uno di questi poli magnetici. In altri termini, questi 4 tipi andrebbero preferiti adottandone gli scopi, il ruolo, le responsabilità e i tipi di interazione. Semplificare i tipi di team adottando soltanto questi 4 aiuta a ridurre l’ambiguità all’interno dell’organizzazione.

Stream-Aligned Team

Un team Stream-Aligned è allineato a un singolo flusso di lavoro che produce valore per l’utente finale. Il flusso di lavoro può riguardare un singolo prodotto o servizio, un insieme di funzionalità di un prodotto/servizio più grande, uno user journey, o una singola user persona.
Inoltre, il team è messo nelle condizioni di creare e rilasciare al cliente/utente finale valore in modo più possibile sicuro, veloce e indipendente, senza bisogno di passaggi di consegna da e verso altri team.
I team Stream-Aligned sono il principale tipo di team in una organizzazione, e lo scopo delle altre tre tipologie di team è di ridurre il carico cognitivo per i team Stream-Aligned.
Siccome i team Stream-Aligned lavorano all’intero spettro della creazione e rilascio di valore, sono necessariamente vicini al cliente/utente finale ed in grado di incorporarne rapidamente il feedback, monitorando il funzionamento del software in produzione.
Diversi flussi di lavoro possono coesistere in una organizzazione: per diversi clienti, differenti business, aree geografiche, prodotti, user-persona. Un flusso potrebbe anche avere forma di una micro-impresa all’interno di un’azienda più grande, con focus e scopo indipendente (ad esempio innovazioni per creare prodotti che ancora non esistono).
Qualunque sia il tipo di flusso a cui il team si allinea, il team è costruito per durare a lungo, in maniera sostenibile, magari come parte di un portfolio, ma non per un fugace progetto (vedere anche anche #noproject di Dimitri Favre).

Le skill dei componenti di un team “Stream-Aligned”

Un team Stream-Aligned è ovviamente in grado di produrre valore end-to-end e deve quindi possedere tutte le skills necessarie (security, design, architecture, coding, operability, metrics and monitoring, product ownership, testing, UX). È critico non assumere che ciascuna skill mappi su specifiche singole persone nel team, altrimenti il team dovrebbe comprendere troppi membri e ciascuno di essi sarebbe un piccolo silos all’interno del team, diventando un collo di bottiglia nei confronti di tutti gli altri. Bisogna invece fare in modo che, nel suo complesso, il team abbia tutte le skill necessarie, tramite la coltivazione di persone t-shaped o un opportuno mix di generalisti e (pochi) specialisti.

Perché team “Stream-Aligned”?

Per questo tipo di team è stato scelto il nome “team Stream-Aligned”, e non “Product team” o “Feature team”, perché oggigiorno i clienti non interagiscono più soltanto con uno specifico pezzo di software, bensì con un vasto ecosistema di prodotti e device su ciascuno dei quali girano diversi tipi di software. I clienti interagiscono inoltre con le aziende tramite molteplici canali (social networks, sito istituzionale, telefono, di persona a meetup e conferenze). In questo contesto multi-canale altamente connesso un “prodotto” può significare molte cose diverse, rendendo difficile capire quali sono le responsabilità di un “Product team” o ancora peggio di un “Feature team”. “Stream-Aligned” è quindi un termine più adatto per comprendere diverse situazioni, inoltre “stream” enfatizza un senso di flusso continuo, di cambiamento continuo, che meglio si sposa col mantenimento di una relazione di lungo periodo con il cliente/utente finale, anche al di là di un singolo prodotto che potrebbe essere dismesso in favore di un altro, pur appartenendo al medesimo, stabile flusso di generazione di valore di lungo termine.

Comportamenti attesi da un team “Stream-Aligned”

• Produzione di un costante e stabile flusso di funzionalità in produzione.
• Rapide correzioni di rotta basate sulla raccolta di feedback.
• Uso di un approccio sperimentale, continuo apprendimento e adattamento al contesto.
• Totale mancanza, o per lo meno un ridottissimo numero, di passaggi di consegna da e per altri team.
• Un sistema di valutazione e incentivazione basato sulla collettività e legato al flusso di valore rilasciato.
• Ricorrenti e costanti periodi di tempo dedicati alla riduzione del debito tecnico (refactoring).
• Per i suoi membri, un senso di realizzazione, di continua crescita, di mastery.

Enabling Team

Come può un team Stream-Aligned che ha una ownership end-to-end trovare spazio per fare ricerca, leggere, imparare e praticare nuove skill? I team Stream-Aligned sono spesso sotto pressione per rilasciare e rispondere rapidamente al cambiamento.

Perché Enabling team?

Vengono in aiuto gli Enabling Team, composti da specialisti in un dato dominio tecnico (o di business) che aiutano gli altri team a colmare i gap di conoscenza.
Gli Enabling Team hanno una natura fortemente collaborativa, sono estremamente capaci di comprendere i problemi e le carenze dei tram Stream-Aligned al fine di fornire loro assistenza e orientamento. Gli Enabling Team forniscono conoscenza, non eseguono lavoro, evitando attivamente di diventare delle torri d’avorio che dettano scelte tecniche per tutti gli altri. Applicano la Servant Leadership a livello di intero team, con l’obiettivo di aumentare le capacità e l’autonomia dei team Stream-Aligned con un focus sui problemi più che sulle soluzioni. Se un Enabling Team fa bene il suo lavoro, il team che sta ricevendo assistenza dovrebbe non averne più bisogno entro alcune settimane o mesi. Non deve esserci una dipendenza permanente tra un Enabling Team e i team suoi “clienti”. Terminato il lavoro con un team “cliente”, l’Enabling Team può spostarsi ad assistere un altro team. In ogni modo, un Enabling team dovrebbe pianificare la sua stessa estinzione fin dal giorno della creazione, per evitare che i team “clienti” ne diventino dipendenti.

Comportamenti attesi da un Enabling Team

• Comprensione dei problemi e dei bisogni dei team Stream-Aligned.
• Astensione dal sistemare problemi; focus sull’insegnare ai team clienti come risolverli in autonomia.
• Costante ricerca di nuova conoscenza, nuovi approcci, strumenti, tecnologie e pratiche nella sua area di competenza, prima che reali necessità sorgano nei team Stream-Aligned.
• Anticipazione, a tutta l’organizzazione, delle novità attese nel medio-lungo periodo, nel bene e nel male. Ad es. “È uscito un nuovo framework in grado di ridurre il tempo di esecuzione delle test suite del 50%” piuttosto che “La libreria X arriverà a fine vita tra 9 mesi, la libreria Y sembra essere un buon rimpiazzo, vediamola insieme“.
• Promozione dell’apprendimento non solo all’interno dell’Enabling Team stesso, ma anche verso tutti gli altri team, agendo come un curatore che facilita la diffusione della conoscenza dentro l’intera organizzazione.

Responsabilità

Le responsabilità degli Enabling Team sono sovrapponibili a quelle che un CTO esercita in una moderna organizzazione. Metriche per la valutazione dell’efficacia di un Enabling Team andrebbero individuate osservando i miglioramenti che i loro team “clienti” manifestano, ad es.:

• Tempo richiesto per un deploy di successo.
• Cycle time.
• Numero di deploy giornalieri senza intoppi.
• Tempo necessario a rilasciare un fix in produzione.

Complicated-Subsystem Team

Questo tipo di team ha la responsabilità di realizzare e mantenere una parte del sistema che dipende in modo sostanziale da conoscenze specialistiche, tali che la maggior parte dei suoi membri deve essere specialista in quell’area di competenza per poter gestire in modo efficace il sotto-sistema
Lo scopo di questi team è di ridurre il carico cognitivo dei team Stream-Aligned che lavorano al sistema di cui il sotto-sistema complicato è parte.
Il team gestisce la complessità del sotto-sistema attraverso specifiche skill che sono difficili da trovare e coltivare, e non ci si può aspettare di includere tali skill in tutti i team Stream-Aligned che fanno uso del sotto-sistema complicato, perché non sarebbe fattibile, o economicamente accettabile, o in linea con gli obiettivi dei team Stream-Aligned.

Un’organizzazione dovrebbe avere il minor numero possibile di team di questo tipo, che vengono creati solo se il sotto-sistema richiede principalmente competenze rare e specialistiche. La decisione se creare o meno tali team è guidata da considerazioni sul carico cognitivo legato al sotto-sistema, e non da considerazioni legate alla possibile opportunità che il sotto-sistema sia condiviso o riutilizzabile.

Alcuni esempi di sotto-sistemi complicati:

• Video processing codecs.
• Modelli matematici.
• Algoritmi real-time di analisi finanziaria.
• Motori di riconoscimento facciale.

Perché Complicated-Subsytem team?

La creazione di questo tipo di team deve essere molto ben ponderata, al riparo da considerazioni legate a vecchi modi di lavorare, del tipo “Il nostro team di soli UX designer è un Complicated-Subsystem Team, perché hanno un set di competenze molto specifico, quindi tutta la UX è in carico a loro“, o “Il nostro team di soli DevOps engineers è un Complicated-Subsystem Team, perché hanno un set di competenze specifiche, quindi tutto il DevOps-ing è in carico a loro“, o ancora “Il nostro team di soli backend developer è un Complicated-Subsystem Team, perché hanno un set di competenze molto specifico, quindi tutto lo sviluppo del backend è affidato a loro“, e così via. C’è bisogno di Complicated-Subsystem Team solo quando aiutano ad aumentare il flusso di rilascio del valore, la velocità e i tempi di risposta ai problemi. Quando si introducono team specializzati in parti della delivery end-to-end (come UX, QA, DevOps, ecc.) si stanno di fatto introducendo dipendenze funzionali che sono uno dei principali ostacoli alla capacità di delivery dell’organizzazione.
Inoltre, la parola “sotto-sistema” non è casuale. Non è una “area funzionale complicata”, è un vero e proprio sotto-sistema (idealmente un servizio in esecuzione basato su API, ma in alcuni casi può essere anche una libreria di codice) che nasconde complicati dettagli di implementazione ai team Stream-Aligned per mantenere il carico cognitivo sotto controllo.
I team Stream-Aligned dovrebbero comunque includere almeno un certo livello di comprensione dei sottosistemi complicati che utilizzano. Ciò non accade magicamente, quindi potrebbe esserci bisogno di Enabling Team per colmare le lacune, ma sempre in un ruolo di mentore, e non creando un’altra dipendenza.
Il sotto-sistema complicato che richiede un team dedicato dovrebbe avere un ciclo di vita abbastanza disaccoppiato dai sistemi che lo utilizzano, in modo che non diventi un costante collo di bottiglia per i team Stream-Aligned, rallentando il lavoro fino a quasi fermarlo del tutto.
Bisogna avere molta paura dei Complicated-Subsystem Team: sono l’eccezione alla regola di avere per lo più team Stream-Aligned, più alcuni Platform Team (la 4a tipologia illustrata più avanti) e talvolta Enabling Team.

L’esempio del Machine Learning

Si può prendere ad esempio il Machine Learning: la maggior parte delle organizzazioni lo tratta come un sotto-sistema complicato, il che può andare bene quando si introduce questa tecnologia per la prima volta. Il fatto è che, nel tempo, è comune che l’utilizzo del Machine Learning aumenti in maniera drastica nei sistemi moderni, con i team di Machine Learning che diventano inevitabilmente un collo di bottiglia e rallentano l’organizzazione. Bisogna guardare all’evoluzione dei team e capire quando certi tipi di team non sono più adeguati.

Comportamenti attesi da un Complicated-Subsystem Team

• Consapevolezza dello stadio corrente di sviluppo del sotto-sistema, agendo di conseguenza: alto livello di collaborazione con i team Stream-Aligned durante la fase esplorativa e di costruzione; e successivamente ridotte interazioni e focus sull’interfaccia che il sotto-sistema ha col mondo esterno nella fase di maturità e manutenzione del sotto-sistema.
• Maggior velocità e qualità dello sviluppo del sotto-sistema rispetto a quando era gestito da un team Stream-Aligned.
• Prioritizzazione del lavoro in accordo coi bisogni dei team Stream-Aligned che usano il sotto-sistema.

Platform Team

Lo scopo di questo tipo di team è di abilitare i team Stream-Aligned a generare valore con sostanziale autonomia. I Platform Team forniscono servizi interni per ridurre il carico cognitivo che sarebbe richiesto ai team Stream-Aligned per sviluppare anche questi servizi sottostanti.
Con “piattaforma” si intende una base di API self-service, strumenti, servizi, conoscenza e supporto combinati insieme nella forma di un prodotto interno ben confezionato. Grazie alla piattaforma i team Stream-Aligned possono realizzare e rilasciare valore a un ritmo più elevato, con un costo di coordinamento ridotto ai minimi termini. La facilità d’uso della piattaforma è fondamentale: i Platform Team devono vedere il loro lavoro come un prodotto affidabile, efficace, di qualità, come se fosse consumato da clienti esterni.

Comportamenti attesi da un Platform Team

• Stretta collaborazione con i team Stream-Aligned per comprendere il loro bisogni.
• Uso di tecniche di prototipazione rapida e coinvolgimento di membri dei team Stream-Aligned per ricevere rapido feedback su cosa funziona e cosa non funziona.
• Grande focus sulla usabilità e affidabilità dei suoi servizi, capacità di monitoraggio dei servizi in produzione.
• Approccio “lead by example”, usando esso stesso i servizi realizzati, e utilizzando servizi realizzati da altri Platform Team.
• Consapevolezza che l’adozione dei propri servizi da parte dei team Stream-Aligned, così come per le nuove tecnologie in generale, non è immediata, richiede tempo ed evolve lungo una curva di apprendimento che richiede supporto iniziale.

In organizzazioni di grandi dimensioni, una piattaforma potrebbe aver bisogno di più di un team per essere realizzata e mantenuta in produzione. In queste situazioni una piattaforma è composta da gruppi di team, potenzialmente di tutte e 4 le tipologie. Una piattaforma può essere essa stessa costruita su una piattaforma di più basso livello.

In ogni modo, i flussi di valore a cui una piattaforma si allinea sono diversi da quelli a cui si allineano i team Stream-Aligned che realizzano il prodotto/servizio principale (quello che genera la revenue, usato dagli utenti finali). In una grande piattaforma, i flussi sono relativi a servizi e prodotti all’interno della piattaforma, ad esempio logging, servizi di monitoraggio, API per la creazione di ambienti di test, ecc.

Questo tipo di organizzazione può essere definito “annidato” o “frattale”.

Tuttavia è necessario sempre tenere sotto controllo le dimensioni o le responsabilità di una piattaforma. Gli sviluppatori software adorano creare framework e piattaforme, con il rischio di degenerare in mostruosità che fanno molto più del necessario, generando debito tecnico, limitando la flessibilità dei team Stream-Aligned che devono utilizzarlo. È opportuno assicurarsi che i Platform Team, e ancora più i gruppi di team che lavorano a grandi piattaforme, abbiano ferree capacità di product management.

Come considerazione finale sulle 4 topologie, un’organizzazione dovrebbe essere costituita principalmente da team Stream-Aligned, con non più del 15% di team di tipo diverso.

Convertire team esistenti in una della 4 topologie

Vediamo ora come convertire classiche tipologie di team in una delle 4 tipologie appena descritte.

• Team di infrastruttura (talvolta chiamati anche team IT, team “DevOps” (a sproposito), team di sistemisti) verso Platform Teams. Convertire un team di infrastruttura in un Platform Team abilita un rapido e sicuro flusso di valore sia all’interno della piattaforma, sia all’interno dei team Stream-Aligned. Questa conversione non è generalmente semplice perché, siccome una piattaforma deve essere gestita come un prodotto, spesso al team di sistemisti mancano capacità di product management e i suoi membri possano sentirsi spaesati. Questo è un ambito dove un Enabling Team può venire in supporto.
• Component Team verso Platform Teams o altri tipi. Team esistenti che si basano su componenti tecnologici dovrebbero essere dissolti, con il passaggio delle loro competenze a team Stream-Aligned, oppure convertiti in altri tipi: come Platform Team (se il componente è una “piattaforma” di basso livello), come Enabling Team (se il componente è sufficientemente semplice da essere gestito, a regime, da team Stream-Aligned), come Complicated-Subsystem Team (se il componente è veramente troppo complicato per i team Stream-Aligned).
• Tooling Team verso Enabling Teams o parte di una piattaforma. Anche in questo caso, team che si occupano della manutenzione ed evoluzione di particolari tool rischiano di diventare silos rallentando l’organizzazione. Dovrebbero essere convertiti in Enabling Team di durata limitata, fintanto che la competenza non è stata assimilata dai team Stream-Aligned, oppure diventare parte di una piattaforma se l’evoluzione del tool prevede sforzi consistenti e duraturi.
• Team di Supporto: il modo tradizionale di fornire supporto è attraverso un team di generalisti in gradi di assistere i clienti/utenti finali su tutti i servizi erogati dall’organizzazione. Quando la velocità del cambiamento e la dimensione dell’organizzazione sono limitate, questo modello può essere economico ed efficace. Quando però la velocità di cambiamento o la dimensione dei prodotti/servizi erogati cresce, le cose cambiano perché il team di generalisti non riesce a mantenere la sua conoscenza sui servizi/prodotti al passo con la loro velocità di evoluzione. Un modello migliore prevede:
  • Team di supporto accoppiati a team Stream-Aligned.
  • Gruppi di persone di brevissima durata (swarming) per la risoluzione degli incident (war room).

  In caso team di supporto siano necessari, dovrebbero affiancare i team Stream-Aligned nello stesso spazio fisico o virtuale, in modo da maturare la massima consapevolezza possibile sul prodotto/servizio, e contemporaneamente restituire ai team Stream-Aligned feedback proveniente dal campo, e mantenendo i diversi stream il più  indipendenti possibile tra loro. Quando si verifica un incidente in produzione, il team di supporto cerca inizialmente di risolvere il problema in autonomia, ma se non ha successo, crea rapidamente una war room temporanea con membri dei team Stream-Aligned di riferimento che sono a portata di mano.

• Team di Architetti: il pattern più efficace per convertire un team di architetti è un Enabling Team part-time (corrispondente a un chapter o una gilda, come viene spesso chiamato nelle organizzazioni). Part-time perché i suoi membri devono diventare membri di team Stream-Aligned o Platform Team, e spendere la maggior parte delle loro energie nel realizzare cose concrete. Le decisioni architetturali dovrebbero essere prese dai team operativi, e non imposte da persone esterne.

Affettiamo il monolite

Molti problemi nello sviluppo software derivano da confini non chiari tra i diversi team e le loro responsabilità. Il tutto aggravato tipicamente da una architettura in cui le diverse parti sono tenacemente accoppiate tra loro: il “monolite”.

Esistono diversi tipi di monolite di cui essere consapevoli prima di iniziare a fare cambiamenti:

• Applicazione monolitica: una singola, grande applicazione con molte dipendenze e responsabilità, che espone molti diversi servizi e user journey.
• Monolite Database-Level: composto da diverse applicazioni o servizi accoppiati sullo stesso schema di DB, rendendo difficile modificare, testare e rilasciare ciascuna parte in modo indipendente.
• Build monolitica: usa un gigantesco sistema di Continuous Integration per ottenere una nuova versione anche del componente più piccolo e, solo in teoria, indipendente dal resto.
• Release monolitica: un insieme di piccoli componenti impacchettati insieme in una release. La build dei componenti può avvenire in CI pipeline indipendenti, ma il test può avvenire soltanto in un ambiente condiviso statico senza service mock.
• Modello monolitico (“singola visione del mondo”): software che cerca di forzare un unico linguaggio di dominio e un’unica rappresentazione attraverso molti contesti differenti. Flessibilità e adattamento sacrificati sull’altare della consistenza .
• Pensiero monolitico: pensiero “one-size-fits-all” che impone ai team restrizioni non necessarie sull’uso di tecnologie o modelli implementativi. Standardizzazione a tutti i costi con lo scopo di minimizzare la variabilità, che semplifica le brame di risparmio e di controllo del management sui team, ma ad un costo elevato e occulto. Privare i team della libertà di scelta imponendo un singolo stack tecnologico o un singolo set di strumenti mina la qualità del lavoro, la creatività, e in ultimo la motivazione delle persone.
• Workplace monolitico: un singolo modo di organizzare gli ambienti di lavoro, per qualunque team o persona, senza riguardo alle reali necessità collaborative e comunicative.

Come visto in precedenza, affettare un monolite correttamente è un’operazione che deve tenere in conto i team e il loro carico cognitivo, e la necessità di rendere i team il più autonomi e indipendenti possibile tra di loro. Altrimenti il rischio è di spezzare sì il monolite, ma generando un sistema di interdipendenze malsane: un “monolite distribuito”.
Bisogna anche evitare che, nel risolvere i problemi causati dal monolite, si generino altri problemi quali bassa consistenza tra le diverse parti, duplicazioni accidentali di dati, UX incoerente, aumento di complessità legata a sistemi distribuiti.

I piani di frattura

Un approccio efficace alla suddivisione dei monoliti è il concetto di “piano di frattura“, mutuato dalla geologia. Un piano di frattura è una superficie di giunzione naturale che consente a un sistema di essere diviso facilmente in due o più parti. È possibile rompere un monolite combinando diversi piani di frattura:

• Bounded Context del dominio di business: un bounded context è un concetto del Domain Driven Design. È un’unità internamente consistente per partizionare un dominio più grande. Un esempio: servizio di streaming on-line che può essere partizionato in 3 bounded context ben allineati con aree di business: media discovery (trovare nuova musica), media delivery (lo streaming verso gli ascoltatori) e licensing (gestione dei diritti musicali, pagamento delle royalties). Identificare i bounded context richiede una approfondita conoscenza del dominio di business unita a conoscenze tecniche.
• Compliance regolatoria: isolare dal monolite le parti soggette a specifica regolamentazione (sanitaria, finanziaria, ecc.) per non costringere tutta l’organizzazione alla conoscenza di questi aspetti regolatori, e per non obbligare aree non critiche del sistema a sottostarvi.
• Frequenza di cambiamento: quando diverse parti del sistema necessitano di cambiamenti con frequenze differenti. In un monolite ciascuna parte si muove alla velocità della parte più lenta. Ad esempio le funzionalità “ricerca” in un catalogo potrebbero richiedere una frequenza di cambiamento molto più lenta degli algoritmi Machine Learning che suggeriscono agli ascoltatori nuova musica. Separando queste 2 parti si ottiene che il bisogno di business guida la velocità di cambiamento, piuttosto di avere un monolite che impone una velocità fissa per tutto quanto.
• Ubicazione dei team: quando per determinati team non è possibile avere una completa co-locazione, o una configurazione remote-first, è meglio spezzare il monolite in sotto-sistemi per team in differenti ubicazioni. In questo modo l’organizzazione può sfruttare la legge di Conway e allineare l’architettura del sistema ai vincoli comunicativi imposti dalla geografia.
• Rischio: diversi profili di rischio possono coesistere in un prodotto/servizio, solitamente legati a differenti livelli di appetito per il cambiamento da parte di diverse classi di clienti/utenti finali. Ad esempio un prodotto Saas multi-tier potrebbe avere milioni di utenti nel suo livello gratuito, e solo alcune migliaia nel livello a pagamento. Modifiche a funzionalità gratuite molto popolari potrebbero ricadere in un profilo di rischio elevato, perché qualunque bug potrebbe significare la perdita di milioni di potenziali clienti. Al contrario, un bug in una feature a pagamento potrebbe comportare rischi minori, in quanto il servizio di supporto ai clienti paganti è in grado di mitigarne la temporanea insoddisfazione.
• Performance: diverse parti del sistema possono aver bisogno di diversi livelli di attenzione riguardo le performance e lo scaling. Ad esempio sistemi che comportano un “click-day”. Separare il monolite secondo questo criterio può far in modo che soltanto un sottoinsieme dei team abbia il carico cognitivo di doversi sobbarcare queste problematiche, evitando anche che i costi associati allo scaling vengano sostenuti per parti del sistema che non li richiedono.
• User Personas: quando multipli tipi di utente o user journey coesistono nel monolite. Questo criterio regala anche un robusto focus verso i bisogni di specifici clienti, e quindi tipicamente una migliore customer satisfaction.
• Tecnologia: l’ultima spiaggia. Questo tipo di criterio è solitamente l’unico utilizzato nelle organizzazioni tradizionali (team UX, team FE, team BE, team QA, ecc.) e ne abbiamo già visto le disfunzioni. Tuttavia ci sono situazioni in cui tecnologie molto vecchie e difficilmente automatizzabili possono richiedere team dedicati, ma con l’accortezza di preparare l’organizzazione ad evolvere verso architetture e tecnologie più moderne nel medio periodo. Anche perché team dedicati a vecchie tecnologie potrebbero avere problemi motivazionali. In questo scenario è facile cadere nella tentazione di avere 2 team Stream-Aligned, uno che si dedica alla manutenzione del “vecchio” sistema e uno che si dedica al costruzione del “nuovo” sistema che dovrà rimpiazzare quello vecchio (magari impiegando mesi o anni prima che avvenga la sostituzione). Questo è un anti-pattern perché, separando il lavoro di manutenzione del vecchio dal lavoro di costruzione del nuovo, il feedback proveniente dal campo si perde ed esaurisce nel team di manutenzione, e il team che sta costruendo il nuovo sistema perde la possibilità di beneficiarne e costruire un prodotto migliore. Approcci più efficaci prevedono:
  • di avere un solo team che si occupa di entrambi i sistemi (se non supera i limiti imposti dal numero di Dunbar),
  • spezzare i 2 sistemi, vecchio e nuovo, secondo un analogo piano di frattura, e assegnarne le corrispondenti funzionalità risultanti ai 2 team,
  • se i 2 precedenti approcci non sono praticabili, assicurarsi per lo meno che i 2 team lavorino a stretto contatto in modalità Collaborazione (questa modalità di interazione viene approfondita nel prossimo paragrafo).
• Custom: piani di frattura specifici per una data organizzazione: talvolta possono essere identificati altri piani di frattura naturali in particolari contesti. La cartina di tornasole per l’applicabilità di un piano di frattura: l’architettura risultante genererebbe team più autonomi, con meno dipendenze, e con minore carico cognitivo? Naturalmente raggiungere questi risultati richiede un po’ di sperimentazione all’inizio. Una semplice euristica che può aiutare a capire se la strada intrapresa è quella giusta è chiedere al team e al resto dell’organizzazione “Sarebbe semplice offrire al cliente/utente finale o al resto dell’organizzazione questo servizio? Sarebbe possibile consumarlo efficacemente senza frizioni?“. In caso di risposta affermativa, questo sotto-sistema può essere un buon candidato per l’assegnazione a un team dedicato.

E ora andate e comunicate (con parsimonia)

In molte organizzazioni, interazioni tra team e responsabilità mal concepite sono fonte di frustrazione e inefficacia. Si può anche dire a un team che deve essere autonomo e auto-organizzato, ma se i membri del team sono costretti ad interagire con molti altri soggetti esterni al team per completare il lavoro, autonomia e auto organizzazione sono parole vuote.
Ciò che bisogna evitare è la necessità dei team di dover comunicare con tutti gli altri team per riuscire a portare avanti il loro lavoro. La comunicazione è più efficace quando è intermittente.
Team Topologies definisce tre modi di interazione tra i team:

• Collaborazione: lavorare a stretto contatto con un altro team.
• X-as-a-service: offrire o consumare qualcosa con minima collaborazione.
• Facilitazione: a offrire o chiedere aiuto ad un altro team per rimuovere impedimenti.

Formalizzare le modalità con cui i team interagiscono aiuta a valutare l’efficacia del loro lavoro grazie alla definizione esplicita di interfacce tra di essi. Infatti, grazie alla legge di Conway, ci si aspetta che queste interfacce avranno riflesso nell’architettura del sistema che viene sviluppato. Queste modalità di interazione dovrebbero diventare delle abitudini per i team. Offrendo e pretendendo dagli altri team queste modalità, un team può beneficiare di una migliore chiarezza degli scopi di ciascuno, un aumento dell’engagement, una riduzione della frustrazione nei rapporti con gli altri team. Un elemento chiave di Team Topologies è proprio nelle scelta consapevole che due team fanno tra collaborare su qualcosa, o se scambiarsi qualcosa come servizio.

Modalità Collaborazione

La collaborazione promuove l’innovazione e una rapida discovery, ma rende opachi i confini di responsabilità tra i team. È una modalità adatta quando è richiesto un alto livello di adattabilità in situazioni complesse, incerte, esplorando nuove tecnologie o tecniche di lavoro; durante le fasi iniziali dello sviluppo di un nuovo sistema, o periodi in cui c’è bisogno di scoprire velocemente nuove informazioni. In questi contesti è efficace perché consente di evitare costosi passaggi di consegne tra team. La collaborazione avviene tra gruppi con differenti insiemi skill allo scopo di mettere in comune la conoscenza e l’esperienza di molte persone per risolvere problemi sfidanti.

Ci sono due modi di vedere team che interagiscono usando la collaborazione:

• Due team con conoscenze e responsabilità diverse che lavorano insieme su un piccolo insieme di cose: mantengono sostanzialmente le loro responsabilità ed esperienza per le loro reciproche aree di competenza, lavorando su uno specifico sottoinsieme di attività e dettagli.
• Il lavoro in comune può essere completo: c’è in atto effettivamente una fusione integrale dei 2 team che mettono insieme tutte le skill e conoscenze. Necessario prestare attenzione che il limite massimo del Numero di Dunbar (15) non venga superato.

In entrambi i casi i due team devono avere responsabilità congiunta per l’outcome complessivo della loro collaborazione, perché si creano confini sfumati. Senza responsabilità comune, c’è il pericolo di una perdita di fiducia in caso qualcosa vada storto.
Il fatto che il costo della collaborazione sia elevato (i membri dei 2 team aumentano il loro carico cognitivo dovendo interessarsi di parti nel dominio dell’altro team), implica che deve esserci un valore ancora più elevato nel prodotto della collaborazione.

Quando ricorrere alla modalità Collaborazione

Usare questa modalità per lunghi periodi di tempo non è opportuno. Se si osserva una necessità di collaborazione che non si esaurisce nel medio termine, si è probabilmente in presenza del sintomo di una scorretta assegnazione di responsabilità o di un inefficace mix di skill all’interno di almeno uno dei due team.
Un team dovrebbe usare la modalità di collaborazione al più con un solo altro team per volta.
Usi tipici: team Stream-Aligned che lavorano con Complicated-Subsystem team; team Stream-Aligned che lavorano con Platform Team, Complicated-Subsystem team che lavorano con Platform Team.

Stili di comportamento

Forte interazione, condivisione di spazi fisici e virtuali, mutuo rispetto, uso assiduo di pratiche quali pair e mob programming, lavagne condivise, sketching.

Modalità X-as-a-service

Questa modalità definisce chiare responsabilità e promuove una delivery predicibile, ma necessita di robuste capacità di Product Management. Funziona bene se i confini del servizio sono scelti accuratamente. È adatta a situazioni in cui uno o più team hanno bisogno di utilizzare una libreria, un componente, delle API che funzionino senza frizioni, consumandoli come un servizio. Durante fasi avanzate dello sviluppo e periodi che necessitano di delivery predicibile (in opposizione all’esplorazione di nuovi approcci e tecnologie) è la modalità che funziona meglio.
Affidarsi a qualcosa “as a service” richiede un lavoro di alta qualità da parte del team che fornisce il servizio, e consente agli altri team di lavorare velocemente senza bisogno di sobbarcarsi aspetti non-core del loro lavoro. Se il servizio fornito richiede poca o nessuna interazione tra il team che fornisce il servizio e quello che lo consuma, questo è il segnale che la modalità di interazione sta funzionando correttamente.
È necessario che il team fornitore del servizio abbia una forte responsabilità verso i suoi consumatori, anche in termini di UX e documentazione. Il servizio deve essere gestito in modo che il suo valore venga mantenuto alto, che le richieste di nuove feature siano tenute in considerazione, ma non realizzate automaticamente solo perché un singolo team consumer le ha richieste. L’evoluzione del servizio deve avvenire invece nel miglior interesse di tutta l’organizzazione, con un’attenta pianificazione concordata con tutti i consumatori.

Quando ricorrere alla modalità X-as-a-service

Un team può aspettarsi di usare l’interazione X-as-a-service con diversi altri team contemporaneamente, sia che sia un fornitore, sia che sia un consumatore di servizi.
Usi tipici: team Stream-Aligned e Complicated-Subsystem team che consumano una piattaforma realizzata da un Platform Team; team Stream-Aligned e Complicated-Subsystem team che consumano un componente o una libreria realizzata da un Complicated-Subsystem team.

Stili di comportamento

Enfasi sulla user experience e sulla developer experience, robuste capacità di Product Management, robuste conoscenze in ambito API design.

Modalità Facilitazione

Questa modalità soddisfa le situazioni in cui uno o più team possono beneficiare dell’aiuto attivo di un altro team che facilita, fa coaching, agisce da mentore per alcuni aspetti del loro lavoro. Questa è la modalità principale di lavoro per gli Enabling Team. Un team con competenze di facilitazione non prende parte alla realizzazione del sistema; non pesca, insegna a pescare.
La facilitazione richiede spesso importanti “upgrade” culturali nelle organizzazioni, sia perché implica che delle persone particolarmente esperte si astengano dal lavorare concretamente alla costruzione di qualcosa, sia perché questo tipo di interazione potrebbe inizialmente apparire poco familiare a persone tecniche abituate a “sporcarsi le mani” tutto il giorno.

Quando ricorrere alla modalità Facilitazione

Un team dovrebbe aspettarsi di usare la facilitazione con un piccolo numero di altri team contemporaneamente, sia che stia consumando, sia che stia erogando la facilitazione.
Usi tipici: un Enabling Team che aiuta team di altro tipo; team di qualunque tipo che aiutano un team Stream-Aligned.

Stili di comportamento

Aiutare ed essere aperti a ricevere aiuto, mente aperta nei confronti di nuovi approcci, capacità di ascolto, facilitazione, coaching e mentoring.

Considerazioni sulle su Team Topologies e interazioni tra le 4 tipologie

Ciascuna della 4 topologie ha certi comportamenti caratteristici che la fa lavorare bene nel contesto di una organizzazione. Talvolta, un team necessita di adottare un diverso tipo di interazione con gli altri team al fine di migliorare l’outcome dell’organizzazione.

Tips & Tricks per introdurre ed evolvere Team Topologies

Alcune considerazioni utili all’introduzione dei principi Team Topologies in un’organizzazione, e alla successiva evoluzione nel tempo.
Nell’applicare la Manovra di Conway Inversa illustrata in precedenza, non bisogna aspettarsi che la nuova architettura desiderata emerga immediatamente dopo che una nuova struttura dei team è stata messa in atto: l’architettura preesistente farà inizialmente “resistenza” contro la nuova struttura. Per aiutare la nuova struttura ad avere successo, e per capire se i nuovi confini di responsabilità tra i team sono corretti, la manovra inversa dovrebbe essere applicata con un temporaneo ma esplicito accordo ad utilizzare la modalità Collaborazione tra i vari team, insieme a uno o più Enabling Team in modalità Facilitazione. In questo periodo di uso intensivo della collaborazione potranno esserci continui aggiustamenti dei confini di responsabilità, il che è positivo avvenga il prima possibile, prima che troppo venga costruito richiedendo quindi successivi e dolorosi passaggi di consegne. Una volta che i confini si sono stabilizzati, eliminare le interazioni di collaborazione non più necessarie.

In un’organizzazione rodata, cambiare saltuariamente e temporaneamente modalità di interazione, previo esplicito e consapevole accordo, può aiutare i team member a rinfrescare e accrescere la loro esperienza ed empatia nei confronti degli altri team: creare coppie di pair programming cross-team, mandare un membro in visita ad un altro team per qualche giorno, sono attività che possono fornire preziose occasioni di apprendimento e crescita della motivazione.

Distorsioni del corretto uso delle 3 modalità di interazione possono essere un utile segnale che qualcosa non vada nella definizione delle responsabilità dei team, o delle skill che ci si aspetterebbe abbiano.
In una relazione X-as-a-service c’è troppa comunicazione tra i 2 team? Potrebbe esserci un errata definizione dei confini del servizio, o insufficienti capacità di product management nel Platform Team.
In una relazione di Collaborazione uno dei 2 team non collabora a sufficienza? Quel team potrebbe avere un sovraccarico cognitivo, o non percepire correttamente il valore della collaborazione.

Le 4 tipologie di team, e i criteri con cui assegnare le responsabilità di parti del sistema sono rappresentazioni statiche, valide in un dato momento della vita dell’organizzazione. Non è sufficiente fare determinate scelte, e non aspettarsi cambiamenti dettati dall’evoluzione del mercato, dei clienti, delle tecnologie. Le organizzazione devono cercare di anticipare il bisogno di evoluzione del loro modello organizzativo. In altri termini, dare una nuova forma a un’organizzazione usando Team Topologies può essere efficace, ma lo è ancora di più rendere l’organizzazione consapevole ed esperta dei principi di Team Topologies e delle motivazioni sottostanti. Questo per abituare l’organizzazione ad essere pronta a cambiare agilmente, in modo naturale, la sua struttura ogni qual volta il contesto lo richieda. L’organizzazione deve diventare capace di definire quali sono le regole con cui cambiare, più che definire la sua struttura in un dato momento storico. Nel lungo periodo, cercare di evolvere le modalità di interazione verso X-as-a-service, riservando Collaboration per l’esplorazione di nuovi prodotti e opportunità di business. Questa è una strategia efficace per raggiungere l’agilità.

Alcuni esempi di situazioni che possono agire da trigger per innescare modifiche all’organizzazione:

• Il software è diventato troppo grande per un solo team: i sintomi possono essere: una startup che è cresciuta oltre il Numero di Dunbar di 15 elementi; team che aspettano troppo tempo per ottenere da un Platform Team o Complicated-Subsystem Team le modifiche necessarie; modifiche ad alcuni componenti che vengono assegnate sempre alle stesse persone “perché così si fa prima” anche se quelle persone sono perennemente impegnate; persone che si lamentano per la mancanza di documentazione. In queste situazioni valutare la nascita di nuovi team e la ridistribuzione delle responsabilità.
• La frequenza di rilascio sta diminuendo: i sintomi possono essere: le persone lamentano che in passato si rilasciava più di frequente o che in passato il processo di deploy era più semplice; metriche di team velocity o throughput in costante peggioramento; costante aumento del WIP (work-in-progress). In queste situazioni valutare la nascita di un Platform Team dedicato a erogare servizi di continuous deployment, oppure di un Enabling Team che fornisca coaching sulle stesse tematiche.
• Servizi e funzionalità customer-facing si basano su un insieme di servizi sottostanti eccessivamente grande: i sintomi possono essere: team Stream-Aligned che lamentano una limitata visibilità end-to-end; difficoltà ad ottenere un rapido flusso di delivery a causa della complessità nell’integrazione con sotto-sistemi; i tentativi di riuso di servizi e sotto-sistemi diventano sempre più difficili. In queste situazioni è comune vedere un numero eccessivo di Platform Team con cui un team Stream-Aligned ha a che fare. La soluzione può essere individuata in una iniziativa di “platform-wrapping” o “piattafomizzazione”, in cui tutte le piccole piattaforme vengono unificate, rese consistenti ed esposte all’esterno come un unica piattaforma, riducendo il carico cognitivo per gli utilizzatori.

Conclusioni

Team Topologies è un approccio Agile, ragionato e umanistico al cambiamento organizzativo. Tuttavia la sua applicazione non è sufficiente per avere successo nel rendere le organizzazioni più efficaci e longeve. Oltre alle strutture e alle dinamiche di interazione proposte, ulteriori ingredienti fondamentali devono essere presenti:

• Una sana cultura aziendale che supporti la sperimentazione, l’apprendimento e la trasparenza, in un contesto safe-to-fail.
• La coltivazione di ottime pratiche ingegneristiche: Test Driven Development, Domain Driven Development, Continuous Integration, Continuous Delivery, pair e mob programming, ecc.
• Sane pratiche finanziarie: considerare lo sviluppo software come un centro di produzione del valore, e non come un centro di costo; evitare obsolete pratiche di budgeting che impongono deadline arbitrarie e allocazione di risorse scollegate dalla realtà, e che mortificano l’adattamento e la sperimentazione; preferire l’allocazione di budget formativi e incentivi economici ai team piuttosto che ai singoli individui.
• Chiarezza nella visione di business: la leadership è in grado di fornire una vision non conflittuale e una direzione per tutta l’organizzazione, con obiettivi chiari e realistici, e priorità precise, in modo che le persone possano capire come e perché sono state scelte per partecipare all’impresa.

Infine, quali sono i passi da seguire per iniziare a introdurre Team Topologies nella propria organizzazione?

1. Iniziare o consolidare una cultura team-first, predisponendo spazi, tools, working agreements.
2. Identificare i flussi di lavoro, così come descritto nel paragrafo “Affettiamo il monolite” e affidarne le responsabilità a team Stream-Aligned e, se veramente necessario, a Complicated-Subsystem Team.
3. Identificare una piattaforma che possa essere di supporto alla velocità di delivery dei team Stream-Aligned e Complicated-Subsystem.
4. Identificare gap di conoscenza, in particolar modo in ambito Service Management, Project Management, API documentation, Coaching e Mentoring. Fornire formazione alle persone e/o creare degli Enabling Team dedicati.
5. Praticare differenti modalità di interazione e, contestualmente, assicurarsi che tutta l’organizzazione comprenda e condivida i principi sottostanti questo nuovo modo di lavorare.

Come può scalare questo modello?
Jurgen Appelo ha recentemente proposto un modello di scaling, chiamato unFIX, che usa le 4 topologie di Team Topologies come base per organizzazioni di grandi dimensioni.