Prima di Codemotion Madrid, dove aprirà l’evento con il suo keynote “Playing Tetris with Cognitive Load”, ho avuto il piacere di fare alcune domande a Manuel Pais sul suo libro “Team Topologies: Organizing Business and Technology Teams for Fast Flow”, sulla sua attività attuale e sui suoi piani futuri:
Vorrei presentarti in qualche modo. Quindi, puoi spiegare cosa stai facendo attualmente? Qual è il tuo lavoro oggi?
Oggi la gente mi conosce come uno degli autori del libro sulle ‘Team Topologies’. In pratica, questo significa che sono un relatore, faccio formazione e faccio da consulente per alcune organizzazioni. Sviluppo anche prodotti legati alle idee sui team. Coinvolge molteplici aspetti e gestire il mio carico cognitivo non è sempre facile, ma ci sono molte cose interessanti in corso.
Questo si può dedurre da molte interviste che ho visto su di te in questi giorni. Una cosa che tutti ti chiedono effettivamente è se puoi essere più specifico riguardo alla parola ‘topologie’:
Il termine ‘topologie’ è comunemente usato in ingegneria, in particolare riguardo alla struttura di rete. La parola deriva dal greco e si riferisce a come le diverse parti di un sistema sono interrelate o organizzate insieme. Nel contesto del nostro libro, significa pensare a come le diverse squadre si relazionano tra loro, se sono connesse o meno, e come fare scelte intenzionali su queste connessioni. Dovrebbero essere più connesse? Dovrebbero collaborare di più o essere più indipendenti? Uno dei punti chiave che discutiamo è essere più specifici sul tipo di interazioni che dovrebbero avvenire tra le squadre, decidendo quando è vantaggioso collaborare per risolvere un problema comune e quando tale collaborazione potrebbe effettivamente nascondere una mancanza di capacità in alcune squadre
Prima di iniziare a leggere il libro, che trovo molto interessante, alcuni amici mi hanno detto che il vostro protocollo è stato adottato da Amazon come riferimento per organizzare i team interni. Quali sono le tue sensazioni riguardo a questo endorsement?
È effettivamente molto interessante perché non abbiamo lavorato direttamente con Amazon o AWS su questo, ma da quando il libro è stato pubblicato quasi cinque anni fa, abbiamo visto un cambiamento nei tipi di richieste che riceviamo. Inizialmente, erano principalmente da early adopters come piccole aziende nel 2020 e 2021, che trovavano le idee molto utili e volevano fare cambiamenti organizzativi. Nel corso degli anni, abbiamo iniziato a vedere interesse anche da parte di grandi aziende e settori tradizionali come banche e assicurazioni, dove le nuove idee, specialmente su modi di organizzare e lavorare, tendono ad essere adottate più lentamente. È molto gratificante vedere non solo piccole aziende, ma anche grandi nomi come AWS applicare i concetti delle topologie di squadra. Hanno utilizzato approcci simili fin dai primi anni 2000, dove enfatizzano che le squadre devono possedere i loro servizi e essere scollegate, sapendo quando collaborare e quando non collaborare eccessivamente.
Sappiamo che l’architettura e le strutture di squadra dovrebbero essere progettate in modo tale da evitare che molteplici squadre siano coinvolte quando viene sviluppata una nuova funzionalità. Ma sappiamo anche che questo a volte accade, ed è OK.
Cosa suggeriresti come il miglior modo per mantenere sincronizzati i compiti nei backlog dei team coinvolti quando si verificano dipendenze?
È una domanda interessante. Prima di tutto, è vero che non sempre avremo squadre che possono lavorare completamente autonomamente sui loro backlog. L’ideale è che le squadre siano più indipendenti e autosufficienti. Tuttavia, ci saranno certamente situazioni che richiedono a più squadre di sincronizzarsi per implementare un cambiamento. Se abbiamo un buon equilibrio, diciamo che l’80% del tempo le squadre lavorano sui loro backlog e il 20% o meno hanno bisogno di collaborare con altre squadre, è molto meglio che avere sempre bisogno da tre a cinque squadre per ottenere qualcosa. Come gestire questo nella pratica dipende un po’ dalla natura dei compiti comuni a queste squadre. Se si tratta di interfacce ben definite, le squadre possono collaborare inizialmente per definire queste interfacce, poi eventualmente utilizzare servizi mock per testare indipendentemente queste dipendenze, controllando regolarmente per assicurarsi che rimangano sincronizzate man mano che le cose evolvono. Se c’è molto coinvolgimento, potrebbe essere necessario un sincronizzazione giornaliera tra tutte le squadre per assicurarsi che le persone giuste collaborino e che le dipendenze siano gestite efficacemente.
Quali sono gli obiettivi principali che le organizzazioni mirano a raggiungere adottando le strutture e le strategie delineate nelle topologie di squadra? Possiamo definire alcuni obiettivi da perseguire inizialmente?
Spesso le organizzazioni cercano di scalare; stanno crescendo, hanno avuto successo con alcuni prodotti o servizi e stanno iniziando a vedere dove le loro strutture stanno collassando. Questo potrebbe funzionare in un contesto più piccolo o quando un prodotto potrebbe essere organizzato e costruito da una o due squadre. Quindi si rendono conto che questo non funzionerà man mano che crescono, e iniziano a identificare skill mancanti, forse necessitando di diversi servizi di piattaforma, come discusso nel libro. Spesso si tratta di crescita e scalabilità in modo sensato perché ciò che funziona oggi non scalerà domani. Si tratta anche di raggiungere un flusso più rapido, essere in grado di rispondere più rapidamente alla concorrenza o portare più velocemente nuovi prodotti o valore sul mercato. A seconda della situazione economica, come un blocco delle assunzioni o ridotti investimenti, il focus potrebbe spostarsi sul taglio dei costi in modo che non rallenti i team, mantenendo l’efficacia anche quando non si cresce in dimensioni.
È chiaro che provieni da un background DevOps. Quello che mi viene spontaneo chiederti è come i tipi di team individuati nel libro si allineano con i principi DevOps.
È una bella domanda. Il mio background è in ingegneria del software, e sono stato profondamente coinvolto con DevOps e Continous Developement. I tipi di team di cui discutiamo sono strettamente collegati ai principi DevOps. Ad esempio, uno dei tre principi del DevOps è raggiungere un flusso più rapido, il che significa una consegna più veloce di valore ai clienti. Il primo tipo di team di cui parliamo sono i team streamline, che si concentrano su questo flusso più rapido. In DevOps, enfatizziamo cicli di feedback più brevi e maggiore autonomia, che i team streamline esemplificano. Gestiscono il prodotto dall’inizio alla fine, dalla raccolta dei requisiti dei clienti alla consegna e al collaudo del prodotto in produzione, allineandosi con il primo principio del DevOps—migliorare il flusso. Il secondo principio riguarda il feedback rapido, e queste squadre, grazie alla loro struttura, possono ottenere rapidamente feedback perché non sono dipendenti da altre squadre. Il terzo principio è l’apprendimento continuo, che è fondamentale per i team che gestiscono la proprietà end-to-end, richiedendo un ampio insieme di competenze e conoscenze.
Approfondiamo la dinamica degli individui nei team . Ho letto una citazione che diceva che gli individui all’interno di questi team crescono per agire come una squadra unita piuttosto che solo come un gruppo di persone. Puoi suggerire le best practice per selezionare individui che performano bene in un team?
I tipi di team che abbiamo definito aiutano a guidare la selezione degli individui non solo in base alle esigenze operative ma anche alle motivazioni e inclinazioni personali. Ad esempio, qualcuno con competenze specifiche che ama condividere conoscenze potrebbe adattarsi bene in una squadra abilitante, mentre qualcuno che prospera affrontando sfide tecniche potrebbe essere più adatto per una squadra di piattaforma. È importante che i membri del team abbiano un mix di competenze richieste per i loro ruoli. Tuttavia, in molte organizzazioni, è difficile per gli individui passare a ruoli in cui si sentono più motivati. Spesso, le persone vengono reclutate per team specifici e successivamente scoprono che non è la collocazione migliore. Ci sono casi in cui i membri dei team abilitanti sono passati a team di piattaforma perché preferivano sviluppare soluzioni direttamente piuttosto che insegnare o fare da mentore. Idealmente, le organizzazioni dovrebbero facilitare tali transizioni per garantire che gli individui siano in ruoli che si adattano meglio alle loro competenze e interessi.
Pensi che questo approccio debba essere adottato dall’alto verso il basso in un ambiente che supporta lo sviluppo professionale, o può iniziare dal basso verso l’alto, partendo dagli individui all’interno dell’organizzazione?
È interessante perché molti nuovi approcci organizzativi, inclusi quelli in ingegneria, spesso richiedono una combinazione di strategie dal basso verso l’alto e dall’alto verso il basso per consolidarsi. Quando stavamo scrivendo “Team Topologies” pensavamo inizialmente che sarebbe interessato principalmente alla dirigenza e a chi decide sulle strutture di team. Tuttavia, siamo rimasti sorpresi nel scoprire che anche coach agili, architetti e persino contributori individuali stavano leggendo il libro. Ci sono aspetti del nostro approccio che possono essere implementati dal basso verso l’alto. Ad esempio, i team possono essere più attenti sul come interagiscono con altre squadre e su come definiscono e comunicano le loro API di team per chiarire le loro modalità di interazione e pratiche preferite. Se queste pratiche vengono adottate a livello di team e si dimostrano vantaggiose, possono influenzare cambiamenti organizzativi più ampi. Idealmente, si usano entrambi gli approcci: le persone all’interno dell’organizzazione adottano e sostengono le pratiche, e la leadership riconosce il loro valore e supporta un’implementazione più ampia.
Molto interessante. Infine, la domanda dovuta sull’intelligenza artificiale. Influisce sulle topologie di team e, in caso affermativo, quali sono gli effetti principali?
Sì, l’intelligenza artificiale, in particolare l’IA generativa, sta influenzando notevolmente le topologie dei team all’interno dei team orientati alla tecnologia. È importante che le organizzazioni siano predisposti ad integrare gli strumenti di IA. Non si tratta solo di adottare nuovi strumenti come Copilot; è importante comprendere come questi strumenti cambiano i nostri modi di lavorare e influenzano il nostro carico cognitivo. Organizzativamente, dobbiamo pensare a come utilizzare l’IA in modo efficace su tutti i fronti, il che potrebbe includere la creazione di team abilitanti per diffondere buone pratiche e affrontare questioni etiche e di sicurezza associate all’uso dell’IA. In ultima analisi, l’uso efficace dell’IA nelle organizzazioni dovrebbe essere visto come un potenziamento delle capacità, non solo a livello di singolo team, ma in tutta l’organizzazione.
La mia ultima domanda: su YouTube, cercando notizie su di te, ho visto un video in cui parlavi di topologie nella sicurezza. È il tuo prossimo argomento? Stai pianificando di sviluppare qualcosa lungo queste linee?
No, non stiamo scrivendo un libro specificamente su questo. Il successo di “team topologies” è piuttosto affascinante perché ha ispirato le persone a espandere alcune delle idee in domini specifici, come la sicurezza, per esempio. Penso che tu stia facendo riferimento a una sessione che ho avuto con Mario Platt, che è un esperto di sicurezza. Stava spiegando diverse topologie di sicurezza che si concentrano su un mindset abilitante che aiuta i team a comprendere abbastanza bene la sicurezza da integrare con le pratiche DevSecOps in quello che io chiamerei team snelli.
La sicurezza è un dominio ampio, e ci sono molti aspetti da considerare. Ad esempio, Eduardo da Silva ha fatto un lavoro davvero interessante su come i team abilitanti possono aiutare a costruire capacità di data science. Il nostro lavoro attuale non riguarda la scrittura specifica su questi argomenti, ma piuttosto l’amplificazione del grande lavoro che questi esperti e altri stanno facendo.
Il mio focus, insieme a Matthew, è su come queste idee su flusso rapido, topologie di team e i modelli possano essere applicati più ampiamente, non solo nell’ingegneria. Ad esempio, abbiamo parlato con organizzazioni in vari settori, come uno studio legale che non sviluppa software e organizzazioni sanitarie. Queste discussioni ruotano attorno a come accelerare i processi di lavoro migliorando i sistemi in cui operiamo, garantendo un feedback rapido e affrontando aspetti critici come la sicurezza dei pazienti nell’assistenza sanitaria.
Ci sono esempi interessanti, in particolare nel Regno Unito, di applicazione di queste idee durante la pandemia, come lo sviluppo di sistemi per la gestione delle vaccinazioni. Quindi, mentre non prevediamo di pubblicare un libro quest’anno o il prossimo, stiamo considerando di compilare queste esperienze in un libro tra qualche anno, offrendo una prospettiva più ampia e coerente.
Grazie mille per il tuo tempo, spero di vederti per il tuo keynote a Codemotion Madrid.
È stato un piacere, spero di incontrarti a Madrid.
