Introduzione
In questi due articoli elaboro e sintetizzo le idee di Matthew Skelton e Manuel Pais riguardo alla configurazione dei team e ai loro meccanismi di interazione all’interno di organizzazioni che si occupano di sviluppo software. Sono stati fonte di ispirazione Il loro libro Team Topologies [1], e il workshop con Manuel Pais, organizzato da Avanscoperta [2] nell’aprile 2021, a cui ho avuto occasione di partecipare.
Il mio lavoro come Delivery Manager mi porta a interagire con diversi team presso aziende di varie dimensioni e settori di business. Osservando la loro struttura, il loro modo di relazionarsi con il resto dell’organizzazione, la loro evoluzione nel tempo, molte cose risuonano in Team Topologies. Il mio intento è di fare tesoro di queste idee nell’aiutare i team a lavorare meglio, e i loro membri a essere più contenti della loro professione.
Stabile e veloce non sono più in alternativa
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 raccolte 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 visione chiara. Costruire e operare sistemi software è un’attività socio–tecnica, non una catena di montaggio come in una fabbrica di stampo fordista.
Organigrammi e ri-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 ritengano necessario 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 [4]. 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 antipattern
Negli ultimi decenni ci sono stati molti tentativi di superare gli organigrammi tradizionali (per esempio con le organizzazioni matriciali [3], 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 antipattern è 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 do committees invent?, pubblicata nel 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 progettano 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 inversa di Conway:
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, è improbabile che un’organizzazione strutturata in silos funzionali (DBA, QA, BE, FE, etc.) 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 solo 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 [7] è un concetto teorizzato dallo psicologo John Sweller nel 1988 come
La quantità totale di sforzo mentale usato nella memoria di lavoro.
Sweller definì tre tipi di carico cognitivo:
- 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?“.
- 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?“.
- Attinente: relativo ad aspetti del task che necessitano di attenzione speciale all’apprendimento o a elevate prestazioni, ad esempio, “Questo servizio come deve interagire con il 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, etc.
- 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.
- Facendo 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, uniformità, 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 le cose all’esterno, anche tramite l’uso di information radiators.
Esempi di questi elementi da mostrare all’esterno con un “approccio ad API” possoo essere:
- 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, etc.).
- 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 comunichinono e collaborino il più possibile. Non è così. Henrik Kniberg, in Real Life Agile Scaling [8], 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 invece di stanze dedicate ai singoli team o ai “cubicoli” individuali. Quali team mettere in uno stesso open space, quali in stanze attigue invece che distanti, quali addirittura nello stesso piano di un edificio invece 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 soluzioni molteplici per molteplici 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 ne basterebbe uno solo. Altre volte un solo strumento è in uso, e questo crea problemi tra team che beneficerebbero ognuno del suo strumento dedicato.
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, risulterà probabilmente 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 discorso diverso 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 e incoraggiare persone con skill o interessi comuni a 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 a 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 del Manifesto Agile recita:
La continua attenzione all’eccellenza tecnica e alla buona progettazione esaltano l’agilità.
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 raccolte di individui, quando si tratta di attività ricche di conoscenza, che necessitano di problem solving e di elaborare 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 britannico Robin Dunbar, in uno studio degli anni Novanta che lo portò a teorizzare il cosiddetto “numero di Dunbar” [10], 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 e 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ù grandifino a un 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 sei mesi e 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 preesistenti del team.
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-pollination. 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 svariati team effettuino cambiamenti allo stesso sistema o sottosistema 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 quattro 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 a cui fa riferimento anche la pratica DDD formalizzata da Eric Evans nel suo libro [11].
Possiamo inquadrare i domini in base al loro livello di complessità, dividendoli 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, per la loro assegnazione ai team possono essere usate 4 euristiche:
- 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 e assegnarne uno per team.
- 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.
- Terza euristica: un team responsabile di un dominio complesso non dovrebbe aver assegnato alcun altro dominio, anche se semplice.
- 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 a 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, dovrebbe essere il destinatari dei budget formazione.
Conclusioni
Abbiamo visto come l’interazione tra i team e il carico cognitivo a cui sono sottoposti siano fondamentali per far funzionare al meglio l’organizzazione nella quale tali team vivono. Abbiamo anche visto alcune strategie per favorire o, se del caso, limitare la comunicazione. Inoltre abbiamo visto come distribuire la ownership dei vari domini di lavoro nei team e che cosa rappresenti un approccio team-first.
Nel prossimo articolo vedremo come organizzarsi per generare un flusso continuo di valore e quali sono i quattro tipi di team previsti da Team Topologies, con le loro caratteristiche.
Riferimenti
[1] Matthew Skelton – Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution, 2019
https://teamtopologies.com/book
[2] Team Topologies Training @ Avanscoperta
https://www.avanscoperta.it/it/training/team-topologies-training/
[3] Organizzazioni matriciali
https://en.wikipedia.org/wiki/Matrix_management
[4] Joost Minnaar, Advice From The CIA: How To Sabotage Your Workplace. Corporate Rebels Blog, 2019
https://www.corporate-rebels.com/blog/cia-field-manual
[5] Melvin Conway, How do committees invent?. Datamation, April 1968
https://www.melconway.com/Home/pdf/committees.pdf
[6] James Lewis, Microservices and the Inverse Conway Manoeuvre. Codemotion Rome, 2017
https://bit.ly/42MXFxe
[7] Cognitive load
https://en.wikipedia.org/wiki/Cognitive_load
[8] Henrik Kniberg, Real-life Agile Scaling
https://blog.crisp.se/wp-content/uploads/2015/11/Real-life-agile-scaling.pdf
[9] Legge di Brooks
https://it.wikipedia.org/wiki/Legge_di_Brooks
[10] Dunbar’s number
https://en.wikipedia.org/wiki/Dunbar%27s_number
[11] Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional, 2003