Considerazioni sulle su Team Topologies e interazioni tra le 4 tipologie
Ciascuna della 4 topologie di team 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.
La figura 1 mostra le modalità di interazione primarie previste per le quattro topologie, come visto negli articoli precedenti.
La figura 2, invece, mostra altre possibili combinazioni di interazione.
Tips & Tricks per introdurre e far evolvere Team Topologies
Forniamo adesso alcune considerazioni utili all’introduzione dei principi Team Topologies in un’organizzazione, e alla sua 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 a 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 saranno stabilizzati, si elemineranno 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, o mandare un membro in visita a un altro team per qualche giorno sono attività in grado di fornire preziose occasioni di apprendimento e crescita della motivazione.
Analizzare i problemi
Distorsioni del corretto uso delle tre modalità di interazione possono essere un utile segnale che qualcosa non sta andando nella definizione delle responsabilità dei team, o delle skill che ci si aspetterebbe essi abbiano.
In una relazione X-as-a-service c’è troppa comunicazione tra i due team? Potrebbero esserci un’errata definizione dei confini del servizio o insufficienti capacità di Product Management nel Platform Team.
In una relazione di Collaborazione uno dei due team non collabora a sufficienza? Quel team potrebbe avere un sovraccarico cognitivo, o non percepire correttamente il valore della collaborazione.
L’evoluzione non è statica
Le quattro 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 “una volta per tutte”, senza tener conto dei cambiamenti 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 a essere pronta a cambiare agilmente, in modo naturale, la sua struttura ogni qualvolta 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 far 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à.
Situazioni che innecano il cambiamento
Alcuni esempi di situazioni che possono agire da trigger per innescare modifiche all’organizzazione vengono riportati di seguito.
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à a 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.
Considerazioni finali
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, e così via.
- 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.
I primi passi pratici
Infine, quali sono i passi da seguire per iniziare a introdurre Team Topologies nella propria organizzazione?
- Iniziare o consolidare una cultura team-first, predisponendo spazi, tools, working agreements.
- Identificare i flussi di lavoro, così come descritto nella terza parte di questa serie a proposito della scomposizione del monolite e affidarne le responsabilità a team Stream-Aligned e, se veramente necessario, a Complicated-Subsystem Team.
- Identificare una piattaforma che possa essere di supporto alla velocità di delivery dei team Stream-Aligned e Complicated-Subsystem.
- 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
- Praticare differenti modalità di interazione e, contestualmente, assicurarsi che tutta l’organizzazione comprenda e condivida i principi sottostanti a questo nuovo modo di lavorare.
Scaling
Un’ultima considerazione va fatta per rispondere alla domanda: “In che modo può scalare il modello Team Topologies?”
Jurgen Appelo ha recentemente proposto un modello di scaling, chiamato unFix [2], che usa le quattro topologie di Team Topologies come base per organizzazioni di grandi dimensioni: una riprova della validità del modello organizzativo.
Riferimenti
[1] Matthew Skelton – Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution, 2019
https://teamtopologies.com/book
[2] unFIX. Organization design for continuous innovation & better human experience
https://unfix.com/