Recentemente, su consiglio di un collega, ho letto questo libro
Fedele all’ SQ3R, riassumo in questo post quanto mi è rimasto in testa di questo libro.
Quali domande?
Per facilitare una lettura attiva e quindi l’apprendimento, l’SQ3R suggerisce di darsi degli obiettivi esplicitando delle domande cui dare risposta attraverso la lettura. Le domande che mi ero dato erano:
- Come evitare l’effetto “silos” in azienda?
- Come aumentare l’efficacia del team attraverso un’opportuna struttura organizzativa?
- Quali strutture minano la produttività? e perchè?
Il libro ha in buona parte risposto alle mie domande, in particolare alla seconda, meno alla prima.
Struttura del libro
Il libro è strutturato in tre parti.
Parte 1: team come mezzo di delivery
La prima parte esprime il concetto di team come unità base di delivery. Questa parte non è particolarmente originale, ma esprime in modo chiaro e conciso alcuni temi di organizzazione moderna del lavoro in contesti “brain intensive” quale lo sviluppo software. I punti chiave sono:
- La legge di conway “condanna” le aziende a creare architetture che ricalcano la propria struttura di comunicazione. Per questo, occorre plasmare la struttura di comunicazione in modo che essa abiliti la creazione delle architetture desiderate (la cosiddetta “inverse conway maneuver”).
- Il team (e non l’individuo) è l’unità base di produzione di valore. La capacità di lavorare insieme è fattore critico di successo piú degli skills del singolo membro del team.
- Il team deve essere caratterizzato alta fiducia interna. Perchè questo sia possibile, deve essere:
- piccolo: studi antropologici (Dunbar) dimostrano che un team può essere al massimo di 7-9 persone perché si crei fiducia e collaborazione. Immagino perché queste erano le dimensioni della squadra media di cacciatori-raccoglitori del neolitico: siamo “progettati” per queste dimensioni. In aziende caratterizzate da una cultura della fiducia elevata, si può arrivare a 15… ma è un’eccezione.
- durevole: perché le persone imparino a lavorare occorre tempo e a volte coaching. Spezzare continuamente i team, come negli approcci tradizionali a progetti, non ha senso.
- al timone: il team deve sentirsi “proprietario” del software che gestisce. Deve averne piena responsabilità e le leve per esercitare questa responsabilità.
- fatto dalle persone giuste: i membri del team devono avere una mentalità “team first”. Alcune best practices: arrivare in orario, restare on track nelle discussioni, concentrarsi sull’obiettivo di gruppo, aiutare gli altri quando sono bloccati, far crescere gli altri membri del team, evitare di “volerla aver vinta”… gli individui tossici vanno eliminati, non importa quanto sia utile il loro contributo come singoli.
- Il carico cognitivo deve essere mantenuto entro livelli accettabili date le dimensioni del team (che per quanto detto sopra, deve essere piccolo). Uno stesso team non può quindi avere ownership su “troppo roba”, o meglio, su troppi domini. Non è tanto la dimensione della codebase che conta, quanto il numero di diversi domini. Idealmente, un team deve essere owner di un singolo dominio (nell’accezione di dominio del DDD). Inoltre, altre forze portano ad un aumento del carico cognitivo e quindi al degrado della performance. Una teoria interessante, che non conoscevo, classifica il carico cognitivo in tre categorie:
- Carico intrinseco: quello relativo al task primario in esecuzione. Per lo sviluppo software ne è un esempio la conoscenza della sintassi di un linguaggio o della standard library.
- Carico estrinseco: quello relativo all’ambiente in cui si svolge il task primario. Ad esempio, le procedure di build e deploy.
- Carico pertinente: quello relativo agli aspetti critici del task primario. Ad esempio, le cautele di sicurezza in un’applicazione di home banking.
- Di queste tre categorie, la prima va minimizzata attraverso training, coaching, etc… e la seconda va eliminata attraverso l’automazione cosí da lasciare spazio per la terza, dove si esplica il valore del team.
- Ogni team deve avere una chiara API per facilitare le interazioni con gli altri team. l’API di un team è fatta dal suo codice, dalle sue regole per mantenerlo (versioning), dalla documentazione e dalle modalità di comunicazione.
- L’ambiente in cui i team operano deve facilitare le modalità di interazione desiderata. Team che devono collaborare strettamente devono essere vicini. Team che devono collaborare “as a service” devono avere una certa segregazione.
Parte 2: Topologie che abilitano il flusso
La seconda parte costituisce l’elemento piú originale del libro. La comprensione è abbastanza immediata, anche se qualche esempio in più avrebbe aiutato.
Vengono presentati 4 tipi fondamentali di team.
Stream-aligned team
Si tratta di quello che da noi abbiamo chiamato product team: un team cross funzionale che si occupa di un certo dominio. Il libro preferisce la dicitura “stream-aligned team” a “product team” per una ragione che mi è sembrata convincente ma che ho francamente rimosso.
lo stream aligned team è l’unità base di delivery, quello che genera le feature, il valore. Le altre tipologie di team, in un modo o nell’altro, sono tutte a supporto di questo tipo di team. Perchè sia efficace, un team stream-aligned deve avere al suo interno tutto quanto permetta di andare dall’idea alla soluzione (idealmente 0 handover). Deve pertanto eccellere in 9 aree:
- Sicurezza
- Commercial & operational viability analisys
- Desing & Architettura
- Sviluppo
- Infrastruttura
- Metriche e monitoraggio
- Product management & ownership
- Testing & qa
- User experience
Enabling team
Poiché i team stream.aligned sono costantemente soggetti alla pressione del delivery, spesso non trovano il tempo per mettere in atto misure di miglioramento.
Un enabling team assolve la funzione di innovazione e facilitazione per ovviare al problema sopra menzionato. Per la natura del suo mandato, un team enabling deve essere dotato di elevati skill tecnici, ma anche di comunicazione per evitare la sindrome della torre d’avorio.
La loro funzione è principalmente di guida, non di esecuzione. Il loro obiettivo è quello di aumentare l’autonomia dei team stream-aligned facendoli crescere in una specifica area o risolvendo un problema specifico. Pertanto sono al servizio dei team di prodotto solo su base temporanea: sono il “Mr Wolf” dei team stream-aligned. Devono risolvere un problema e poi passare al prossimo, quindi la collaborazione deve essere necessariamente time-boxed.
Complicated subsystem team
Un Complicated subsystem team ha il compito di gestire parti del sistema che richiedono competenze specialistiche. Ad esempio, puo’ rendersi necessario in presenza di COTS specifici o di task altamente specializzati (crittografia, data analytics)
Lo scopo del team è ridurre il carico cognitivo degli stream aligned team. La creazione del team nasce non tanto dalla necessità di riuso di un componente (altrimenti si ricade nell’antipattern del team-per-componente), ma dalla necessità di centralizzare competenze specialistiche.
Platform team
Lo scopo di un platform team è quello di abilitare gli stream-aligned team al delivery del lavoro. In questo senso, sono al servizio come service providers dei team stream aligned.
La definizione di platform non è univoca e puo’ includere il provisioning degli ambienti, la disponibilità della toolchain, degli ambienti e strumenti di sviluppo e in generale di tutto quello che serve per erogare la soluzione di business.
Per sua natura, il team platoform deve fornire servizi e avere un approccio concentrato sulla Developed Experience (DevEx): la prima preoccupazione del team platoform deve essere la soddisfazione del cliente, cioè il team stream-aligned.
Presentate le quattro tipologie di team, il libro presenta un’interessante digressione su come scegliere i “Piani di rottura” per creare i vari tipi di team. Spiega cioè come spezzare il sistema in modo che i vari “pezzi” rientrino nel carico cognitivo sostenibile da un team.
Il piano di rottura piú ovvio viene preso a prestito dal Domain Driven Design: ogni dominio costituisce un frammento assegnabile ad un team (avere piú di un dominio sullo stesso team dovrebbe essere l’eccezione limitata a domini particolarmente semplici e affini).
Un’altra dimensione di rottura puó essere imposta da vincoli normativi. Ad esempio, PCI impone una serie di controlli e processi molto stringenti per il rilascio in produzione. Limitare l’area di applicazione di tali regole ad un dominio specifico da un vantaggio in termini di flessibilità.
Vengono poi presentate altri piani di rottura: tecnologici, geografici, basati sul rischio, sulle performances, sulla cadenza di rilascio, etc…
Parte 3: Modalità di interazione
La terza parte del libro estende i concetti della parte 2 presentando tre modalità di interazione tra team e suggerendo quando le varie modalità siano opportune.
Il presupposto è di fondo è che la collaborazione tra team non è necessariamente un bene. Essa può generare valore, ma impone un prezzo.
Il valore della collaborazione stretta fra team si ha in contesti esplorativi, quando un problema può essere risolto più facilmente attraverso la condivisione di esperienze diversificate.
Per contro, la performance del singolo team degrada quando si trova a dover collaborare. Le ragioni del degrado sono l’allargamento del dominio, lo sfumare delle responsabilità tra i team e l’aumento delle dimensioni del team, che arriva almeno temporaneamente ad includere i membri dell’altro team portando potenzialmente a superare il limite di Dunbar (7-9 persone con cui si puo’ creare un rapporto di fiducia).
Per questa ragione, la collaborazione tra team deve essere gestita in modo attivo affinché eroghi valore quando serve.
Vengono proposte queste tre modalità di interazione
Collaboration
I team che interagiscono in modalità collabaration si “fondono” temporaneamente lavorando strettamente sullo stesso tema.
Quando è opportuna? quando è necessario esplorare velocemente nuove ipotesi o aggredire insieme un problema che richiede skillset eterogenei e presenti in team differenti. Si possono ottenere risultati altrimenti impossibili.
A cosa bisogna fare attenzione quando si adotta questa modalità? Visto che la responsabilità tra team viene in qualche modo sfumata, deve essere chiarito che c’è una responsabilità condivisa al 100%. Senza questo, viene meno la fiducia e senza fiducia non si raggiungono risultati (come sottolineato a piú riprese nella parte prima).
Inoltre, il carico cognitivo aumenta in quanto il i domini dei due team si mescolano almeno temporaneamente e la produttività ne risente.
Per queste ragioni, occorre limitare questa modalità di interazione ai momenti in cui è necessaria.
Quali tipi di team collaborano in questo modo? Questa modalità di interazione solitamente si puo’ avere tra un team stream-aligned e un team compliated subsystem, oppure tra un team aligned e un team platform o ancora tra un complicated subsyste e un platform.
X-as-a-Service
In questo modello, un team usa i servizi messi a disposizione da un altro team. In questo contesto, il termine servizi è inteso in senso lato: potrebbero essere librerie, web services, strumenti, etc…
In questo modello il confine tra team è nettamente marcato e l’interazione bassa. In un certo senso, si trova agli antipodi rispetto alla modalità “collaboration”. Il modello è asimmetrico, con un team che eroga servizi e un team che consuma servizi.
Quando è opportuna? Questa modalità è adatta a contesti caratterizzati da alta predicibilità e bassa necessità di innovazione. Contesti “business as usual”. Il fatto di avere un bassa “banda” tra team riduce l’overhead cognitivo: il team che consuma il servizio è schermato dalla complessità del servizio stesso (sempre che il team che eroga il servizio faccia bene il suo lavoro).
A cosa bisogna fare attenzione quando si adotta questa modalità? In primo luogo la modalità deve essere adatta al contesto, quindi ci devono essere attività caratterizzate da un tasso di innovazione basso.
Un fattore critico di successo è costituito dall’attitudine del team che eroga il servizio: da un lato il team deve essere estremamente motivato a rendere la vita semplice al consumatore dei suoi servizi, attraverso documentazione chiara e aggiornata, retrocompatibilità, versionamento, etc… Dall’altro deve avere la fermezza di non accettare richieste che possano snaturare la natura del servizio che eroga. Deve trattare il servizio che eroga come un prodotto, che deve essere apprezzato dai clienti, ma che non necessariamente deve fare qualsiasi cosa.
Quali tipi di team collaborano in questo modo? Quasi tutti i team che inizialmente collaborano in modalità collaboration dovrebbero prima o poi convertirsi all’ “X-as-a service”: finita la fase esplorativa, consolidate le soluzioni, si passa a questa modalità. Tipicamente i team stream aligned o quelli di complicated subsystem consumano servizi di platform team o di altri complicated subsystem teams.
Facilitating
Questa modalità di interazione, asimmetrica come la precedente, prevede che un team interagisca con un’altro allo scopo risolvere un problema specifico. Abbiamo quindi un team facilitante e un team facilitato.
Quando è opportuna? Questa modalità è pensata per risolvere problemi specifici, in particolare di natura non funzionale o di processo… per colmare gaps di capability di un team.
A cosa bisogna fare attenzione quando si adotta questa modalità? Per sua natura, la facilitazione deve essere time boxed. Il team facilitante deve aiutare il team facilitato a crescere e ad essere autonomo cosí che la facilitazione non sia piú necessaria.
Un secondo aspetto negativo è che un team facilitante deve necessariamente essere costituito da individui di elevata compentenza, i quali, mentre svolgono il ruolo di facilitazione, non sono dedicati al delivery.
Da ultimo, i soft skills dei membri di un team facilitante sono fondamentali affinchè sia visto come un aiuto e non come un’indesiderata intrusione.
Quali tipi di team collaborano in questo modo? Questa modalità è tipica dei team enabling, che hanno nella facilitazione la loro ragion d’essere. Saltuariamente un team stream aligned, platform o complicated subsystem puo’ giocare un ruolo di facilitazione nei confronti di un altro tema stream-aligned.
Evoluzione della topologia
Le modalità di interazione non sono fisse, ma variano secondo il momento e la necessità. Come fare a capire quando è opportuno cambiare la topologia o la modalità di interazione? L’ultima parte del libro elenca un buon numero di trigger che possono innescare il cambiamento, tra cui:
Codebase cresciuta troppo, che supera il carico cognitivo del team. Sintomi tipici includono il lock in su alcuni membri del team per i cambiamenti (segno che non c’è ownership distribuita del codice), la mancanza di documentazione e il mero numero di persone che fanno parte del team, cresciuto sopra la soglia critica di Dunbar.
La frequenza di rilascio diminuisce, il work in progress si accumula. Questo puo’ essere dovuto a dipendenze esterne, quindi al fatto che il team non è realmente autonomo, oppure al fatto che il debito tecnico è cresciuto tanto da impattare la velocità.
Diversi servizi di business si basano su una grossa base di servizi sottostanti, e questa, vi dico la verità, non posso dire di averla capita :-).
Conclusioni
Il libro fornisce utili spunti per chiunque voglia capire come cambiare le strutture organizzative per raggiungere un’ evelavata produttività sostenibile nel tempo.
La bibliografia è ricchissima, anche se le vere novità sono poche.
Ci sono alcuni esempi e case studies. Personalmente ne avrei graditi di piú, ma quello è un mio problema :).
La struttura è chiara e lineare, lo stile molto scorrevole.
Suggerito? assolutamente si.
Ringrazio il collega Marco Pizzoli per avermelo consigliato.