Oganizziamoci per generare un flusso continuo di valore

Il modo purtroppo prevalente di creare o riorganizzare team è adottare soluzioni affrettate, focalizzate a soddisfare necessità immediate delle organizzazioni più che la capacità di adattamento futura.
Per essere più efficaci possibile, c’è bisogno di progettare i team consapevolmente, invece di consentire che si formino a casaccio, guidati dall’urgenza del momento. Ecco due antipattern comuni che derivano da tali cattive abitudini: la progettazione di team ad hoc e il continuo rimescolamento dei membri dei team.

L’antipattern “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.

Anche il continuo rimescolamento dei membri del team 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, tipiche 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 [1] 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 [2] 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’antipattern 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 si scontrerà con 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 (p.e. il provisioning di ambienti di test, la creazione di pipeline di deploy, dashboard di monitoraggio, etc.). Questi servizi possono essere consumati dai team di prodotto al momento del bisogno.
Man mano che l’organizzazione cresce,d è 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“;d
• dai task: “X dipende da Y perché solo Y può realizzare quella cosa su cui, in un secondo momento, X potrà costruirci sopra“.
• Dalle risorse: “X dipende da Y perché solo Y ha accesso a quella risorsa (p.e., un’area protetta, una pipeline, la creazione di credenziali o certificati, l’acquisto di una licenza o di un componente hardware, etc.)“.

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.

Le quattro tipologie di team

Team Topologies [3] 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 quattro tipi andrebbero preferiti adottandone gli scopi, il ruolo, le responsabilità e i tipi di interazione. Semplificare i tipi di team adottando soltanto questi quattro 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 [4] 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 competenze 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, apprendimento continuo 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 [5] 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. Per esempio: “È uscito un nuovo framework in grado di ridurre il tempo di esecuzione delle test suite del 50%”; oppure: “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, per esempio:

• 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 sottosistema.
Lo scopo del Complicated-Subsystem Team è di ridurre il carico cognitivo dei team Stream-Aligned che lavorano al sistema di cui il sottosistema complicato è parte.
Il team gestisce la complessità del sottosistema 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 sottosistema 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 sottosistema complicato, che vengono creati solo se il sottosistema richiede principalmente competenze rare e specialistiche. La decisione se creare o meno tali team è guidata da considerazioni sul carico cognitivo legato al sottosistema, e non da considerazioni legate alla possibile opportunità che il sottosistema sia condiviso o riutilizzabile.

Alcuni esempi di sottosistemi 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, etc.) si stanno di fatto introducendo dipendenze funzionali che sono uno dei principali ostacoli alla capacità di delivery dell’organizzazione.
Inoltre, la parola “sottosistema” non è casuale. Non è una “area funzionale complicata”, ma un vero e proprio sottosistema — 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 sottosistema 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 quarta 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 sottosistema 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 sottosistema, 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 sottosistema ha con il mondo esterno nella fase di maturità e manutenzione del sottosistema.
• Maggior velocità e qualità dello sviluppo del sottosistema rispetto a quando era gestito da un team Stream-Aligned.
• Prioritizzazione del lavoro in accordo con le necessità dei team Stream-Aligned che usano il sottosistema.

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 quattro 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, e così via.

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 utilizzarla. È 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.

Conclusioni

Ci fermiamo qui per questa puntata, in cui abbiamo visto caratteristiche e compiti delle ormai celebri quattro topologie di team presenti nel modello organizzativo Team Topologies. Nella prossima parte cercheremo di capire, nel concreto, come sia possibile intervenire in azienda cercando di far evolvere la realtà esistente in team che si accordino a questo modello.

Riferimenti

[1] Agile software development
https://en.wikipedia.org/wiki/Agile_software_development

[2] What Is DevOps? New Relic
https://newrelic.com/devops/what-is-devops

[3] Matthew Skelton – Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution, 2019
https://teamtopologies.com/book

[4] Dimitri Favre, Live Happily Ever After Without Projects: A #noprojects book. 2020
https://t.ly/9Qu3d

[5] Servant Leadership
https://en.wikipedia.org/wiki/Servant_leadership

Alessandro Giardina

Partito come sviluppatore alla fine degli anni Novanta, ha ricoperto poi ruoli di Team Leader, Product Owner, Scrum Master e Agile Coach, contribuendo a realizzare soluzioni in molteplici mercati.
Praticante entusiasta delle Metodologie Agili, da alcuni anni svolge il ruolo di Delivery Manager in Intré.
Sempre pronto a imparare qualcosa di nuovo, ama lavorare in ambienti collaborativi, in cui le persone possano crescere e migliorarsi.