Dinamiche di Team e il Ruolo delle Internal Developer Platform

Team Topologies: comprendere la struttura aziendale

La prima domanda che mi sono posta è stata se esistessero modelli di organizzazione dei team nelle aziende IT, perché sembrava che ognuno lo facesse in modo diverso. La struttura organizzativa “d’oro” è difficile da trovare. Ho scoperto la struttura funzionale, la struttura basata sul prodotto, la struttura a matrice e molte altre. Ma come si può razionalizzare tutto questo, concentrandosi sul settore IT?

È stato allora che mi sono imbattuta nel concetto di Team Topologies, un framework per l’organizzazione e la strutturazione dei team di sviluppo del software per migliorare il flusso, la comunicazione e l’efficacia complessiva. Ideato da Matthew Skelton e Manuel Pais, definisce quattro tipi di team e tre possibili modi di cooperare tra loro. Questo modello offre un livello di astrazione superiore rispetto ai modelli dettagliati che ho trovato, perché tutti i tipi di team di un’azienda possono essere rimappati nei quattro tipi di team di Team Topologies. Infatti, la rimappatura è il primo passo consigliato a un’azienda che voglia adottare questo modello per identificare i possibili punti dolenti della struttura attuale e prendere decisioni informate per il miglioramento.

Il primo tipo individuato è detto Stream-aligned Team, che è allineato a lungo termine a una particolare area di business dell’azienda, che si tratti di un prodotto, di un servizio o di una qualsiasi parte duratura dell’attività. Ciò è contrario ai team di progetto che esistono solo finché il progetto è in corso e scompaiono al suo completamento. I Stream-aligned Team sono il tipo di team più comune e tutto ruota intorno a loro: seguono un approccio “You Built It, You Run It”, ovvero gestiscono tutti gli aspetti del loro lavoro senza passare ad altri team.

Gli altri tre tipi di team contribuiscono tutti al buon andamento dello Stream-aligned Team.

• Gli Enabling Team riducono il carico cognitivo e aumentano il flusso negli Stream-aligned Team, fornendo una mentorship esperta e aiutandoli ad adottare nuovi strumenti e tecnologie. Offrono conoscenze specialistiche e rilevano le funzionalità mancanti senza detenere l’ownership di alcun componente software.
• I Complicated Subsystem Teams gestiscono parti del flusso di lavoro che richiedono conoscenze e competenze specialistiche, spesso perché sono troppo complesse per essere gestite da soli dagli Stream-aligned Team.
• I Platform Team forniscono servizi e strumenti fondamentali, consentendo agli Stream-aligned Team di consegnare il lavoro in modo più rapido ed efficace senza dover reinventare la ruota. Gestiscono le configurazioni dell’infrastruttura e automatizzano le attività banali, riducendo la complessità.

Platform team e team di sviluppo

È qui che mi sono resa conto che tutto questo suonava familiare. Quando si parla di Internal Developer Platform, spesso si menzionano i Platform Team, i quali costruiscono ed evolvono la piattaforma per ridurre il carico cognitivo e migliorare la Developer Experience, e i Team di sviluppo, che utilizzano la piattaforma per svolgere le loro attività con facilità, concentrandosi esclusivamente sull’implementazione delle funzionalità e fornendo il miglior valore possibile con velocità, coerenza e qualità.

In questo caso la rimappatura è semplice: il Platform Team nel contesto delle IDP corrisponde al Platform Team di Team Topologies, e i team di sviluppo agli Stream-aligned Teams.

Nell’ambito delle IDP, i Platform Team hanno la responsabilità di sviluppare, mantenere e far evolvere l’Internal Developer Platform. Il loro obiettivo è fornire una serie di strumenti che i team di sviluppo all’interno dell’organizzazione possano utilizzare per lavorare in modo efficace. Il Platform Team svolge un ruolo chiave nel supportare lo sviluppo e la distribuzione efficiente del software all’interno dell’organizzazione, fornendo una solida base tecnologica su cui costruire.

I team di sviluupo, invece, si occupano di sviluppare feature end-to-end sfruttando le funzionalità fornite dall’IDP per concentrarsi unicamente sull’implementazione, mentre la piattaforma gestisce i tool e le configurazioni dell’infrastruttura. In questo modo i team possono concentrarsi sulla realizzazione di funzionalità di alta qualità in modo rapido e costante.

Esigenze diverse richiedono modalità di interazione diverse

Come menzionato in precedenza, Team Topologies definisce tre principali tipi di interazione tra i team:

• Collaborazione: I team si uniscono per un periodo di tempo per raggiungere un risultato specifico, come la gestione di un incidente critico o la combinazione di competenze per gettare le basi di un nuovo progetto complesso. Gli sforzi di collaborazione sono tipicamente intensi e riuniscono competenze e prospettive diverse per affrontare sfide complesse o esplorare nuove idee e soluzioni. Spesso è temporaneo e focalizzato su un obiettivo particolare, il che significa che dovrebbe terminare non appena l’obiettivo viene raggiunto.
• X-as-a-Service: Un team fornisce servizi ben definiti e standardizzati a un altro team con un approccio self-service. Il team che consuma è disaccoppiato dal team che fornisce il servizio, il che significa che può lavorare in modo indipendente senza dover attendere supporto o risorse. Questo modello di interazione supporta relazioni continue e stabili in cui un team offre capacità o risorse specifiche che gli altri team possono utilizzare per migliorare la loro produttività e concentrarsi sui loro compiti principali.
• Facilitazione: Un team ne aiuta un altro a migliorare in una determinata area, come adottare una nuova tecnologia o superare una specifica sfida. Questa interazione spesso è temporanea e altamente focalizzata al trasferimento di conoscenze, competenze e capacità al team di destinazione. Questo trasferimento può avvenire attraverso la formazione, il coaching o l’assistenza pratica.

Possiamo notare che le ultime due interazioni mirano a ridurre il carico cognitivo: la maggior parte delle situazioni che prevedono la cooperazione mirano a ridurre il carico (estraneo o intrinseco) che grava sulle spalle degli Stream-aligned Team. Questo è anche uno degli obiettivi principali delle Internal Developer Platform, che in genere mirano a nascondere la complessità per migliorare il DevX.

Un altro obiettivo principale delle IDP è promuovere le modalità self-service, rispecchiando un principio chiave di Team Topologies, che sostiene una cooperazione diretta limitata, favorendo il lavoro asincrono e indipendente.

Perché il self-service è così importante? Dal punto di vista degli Stream-aligned Team, la capacità di risolvere i problemi e di accedere alle risorse in modo autonomo può portare a una maggiore soddisfazione e a una migliore esperienza complessiva. D’altra parte, per i Platform Team è fondamentale adottare modalità di interazione con i team di sviluppo scalabili, per evitare di essere sommersi dalle richieste di assistenza e dalla costante richiesta di supporto pratico. Infine, dal punto di vista del management dell’azienda, il self-service riduce i costi organizzativi e la necessità di allocare risorse extra.

Fasi di adozione dell’IDP e interazioni tra team

Nei prossimi paragrafi cercherò di mettere in pratica quanto appreso finora, comprendendo come i diversi modelli di interazione possano essere sfruttati per adottare con successo un’IDP.

L’adozione di una Internal Developer Platform non è un evento unico, ma un viaggio progressivo che influenza profondamente il modo in cui i team interagiscono e collaborano. Il successo dell’IDP dipende dal numero di team che lo adottano, quindi il Platform Team deve assicurarsi che gli Stream-aligned Teams possano utilizzare al meglio la piattaforma e comprendere il vantaggio di integrarla nei loro flussi di lavoro.

Fase iniziale dell’adozione

Nelle prime fasi dell’adozione della piattaforma, il Platform Team dovrebbe concentrarsi principalmente sul far sì che i team di sviluppo integrino la piattaforma nel loro lavoro quotidiano. Il promotore del cambiamento è il Platform Team, ma il proprietario effettivo della codebase interessata è il team di sviluppo.

In genere, gli Stream-aligned Teams hanno già i propri flussi di lavoro e non sono motivati a cambiare per adottare le funzionalità della piattaforma. Questo perché l’impegno richiesto è presumibilmente elevato e non riceveranno subito benefici tangibili, per cui sono indotti a de-prioritizzare la migrazione alla piattaforma rispetto ad altre attività più urgenti.

In questa fase, il Platform Team deve garantire che l’adozione avvenga in modo efficace. L’invio di ticket al team di sviluppo è un approccio teoricamente scalabile e gestibile, ma potrebbe fallire perché il team di sviluppo non riesce a dare priorità ai compiti o fatica a capire come adottare la nuova piattaforma.

Ecco perché in questa fase è spesso preferibile una stretta collaborazione: il Platform Team può spesso assumere il ruolo di facilitatore, aiutando gli Stream-aligned Teams a capire come utilizzare i nuovi strumenti e servizi introdotti. Questo potrebbe includere un frequente supporto diretto per garantire una transizione scorrevole alla nuova piattaforma, anche incorporando temporaneamente uno o più membri del team della piattaforma nel team di sviluppo per facilitare la transizione.

Questo approccio pratico assicura che i team di sviluppo possano superare rapidamente gli ostacoli iniziali e iniziare a vedere i vantaggi della piattaforma.

Fase di scalabilità

Quando l’IDP inizia a stabilizzarsi e la sua adozione si diffonde in un numero maggiore di team, l’attenzione del Platform Team si sposta verso il miglioramento delle sue capacità e l’integrazione di un numero maggiore di utenti. La differenza con la fase precedente è che le interazioni ruotano intorno alle esigenze del team di sviluppo: hanno un obiettivo da raggiungere e stanno sfruttando le funzionalità della piattaforma per farlo, mentre nella prima fase il motore del cambiamento era il platform team.

Con un IDP più maturo, il modello di interazione si sposta spesso verso l’approccio X-as-a-service.. Il Platform Team fornisce servizi standardizzati che i team di sviluppo possono utilizzare in modo indipendente. Ciò riduce la necessità di una costante interazione diretta e consente agli Stream-aligned Teams di accedere agli strumenti e all’infrastruttura di cui hanno bisogno senza ritardi.

Anche se la modalità di interazione principale è il self-service, potrebbe essere necessaria una facilitazione quando vengono introdotte nuove funzionalità o aggiornamenti significativi. Il Platform Team può offrire indicazioni e supporto per aiutare gli Stream-aligned Team a sfruttare al meglio le nuove funzionalità.

Fase di evoluzione della piattaforma

Nella fase finale dell’adozione dell’IDP, la piattaforma è completamente integrata nel flusso di lavoro dell’organizzazione e il suo utilizzo è onnipresente.

Le modalità di interazione sono caratterizzate da una maggiore autonomia e da occasionali sforzi collaborativi per l’innovazione: gli Stream-aligned Team sono altamente autonomi, affidandosi ai servizi standardizzati forniti dal Platform Team (collaborazione X-as-a-Service), che può comunque assumere il ruolo di facilitatore quando necessario.

Occasionalmente, i team di sviluppo possono proporre di integrare nuove funzionalità nella piattaforma. Questo è l’opposto della prima fase di adozione, perché il team di sviluppo guida il cambiamento, ma il team della piattaforma ha l’ownership della codebase. In questo caso, il team di sviluppo può inviare ticket al team della piattaforma o contribuire direttamente all’aggiunta di nuove funzionalità e miglioramenti alla piattaforma.