La Squad al centro del “modello”

Nel precedente articolo avevamo visto alcuni aspetti fondamentali relativi al “modello” Spotify e alla sua grande diffusione. Avevamo anche spiegato di come non si tratti di un “modello” pronto all’uso e applicabile senza adattamenti a una qualsiasi realtà aziendale. In questo articolo ci concentreremo sull’unità di base del “non modello” Spotify, ossia la squad, e sull’importanza della cultura aziendale nella implementazione di questo approccio allo scaling.

Come nasce una squad

Un altro aspetto culturale tipico della cultura svedese è quello legato all’interazione e alla comunicazione; a tal proposito bisogna sottolineare come il “lancio” di una nuova squad avvenga in modo del tutto “naturale” ed emergente: si decide l’orario e il luogo in cui organizzare un workshop, durante il quale diversi partecipanti di altre squads possono contribuire alla formazione di un nuovo team, esplicitando le competenze tecniche necessarie per il raggiungimento degli OKRs.

Trasparenza e sincerità

Due cardini fondamentali alla base di un nuovo team sono rappresentati da trasparenza e sincerità, ecco perchè ciascun partecipante del workshop interessato a far parte di tale nuova Squad condivide le proprie competenze attraverso una card che può esser selezionata come “candidata” dal Product Owner.

Quando nasce una squad in Spotify, è il team stesso a proporre cosa è necessario in termini di competenze e il Product Owner a decidere tra le persone che si sono autocandidate (le card rappresentate in figura 2).

Onboarding sul campo

Nella definizione del modello Spotify svoltasi nel corso degli anni, gli Agile Coach erano soliti organizzare il processo di formazione di una nuova squad attraverso un bootcamp di due settimane che coincideva con lo “sprint 0” del team. In questo modo il team è focalizzato sulle proprie attività quotidiane inframmezzate da momenti di formazione sul piano metodologico (framework agili), sul piano tecnico (DevOps, Mob Programming) e di business (Product Vision e OKRs).

Interazione e “salute” tra le Squads

L’immagine di figura 3 riporta una visione ad alto livello del modo in cui le squad sono distribuite e organizzate.

Tipologie di squad

Le varie squad possono essere “categorizzate” sulla base del compito fondamentale al quale si dedicano. In tal senso, pertanto, possiamo avere:

• Infrastructure squads: tutti quei team il cui obiettivo è rendere sostenibili le architetture applicative (backend) [1];
• Container squads: team focalizzati sullo sviluppo del software per le piattaforme più diffuse (p.e.: iOS, Android, web);
• Feature squads: team focalizzati sullo sviluppo di nuove funzionalità.

Come si può notare dall’immagine, risulta chiave il ruolo e l’ottimizzazione svolta dalle squad che si occupano della parte infrastrutturale: in tale modo il sistema sarà in grado di accettare le numerose richieste di deploy da parte dei team applicativi (container) che a loro volta ricevono nuove feature sviluppate.

Health check

In maniera periodica, tipicamente al termine di ciascuna iterazione di lavoro — minimo due settimane — ogni squad utilizza una matrice e delle card per stimolare la conversazione tra i membri riguardo alcuni temi specifici (Mission, Learning, Codebase, e così via). Attraverso i colori utilizzati e una breve descrizione, era possibile identificare le aree di miglioramento contraddistinte in ciascuna card.

In tal modo, ogni squad può valutare il proprio livello di “salute”. Ulteriori approfondimenti sullo Health Check sono presenti nella documentazione condivisa da Spotify stessa [2].

Supporto alle squad: POCLAC

In Spotify gioca un ruolo chiave il trio definito POCLAC (Product Owners + Chapter Lead + Agile Coach): questo acronimo ha tra l’altro assonanza con il termine “potlatch”, che indica un insieme di cerimonie tipiche delle popolazioni native della costa nordoccidentale del continente americano e consistenti in distribuzione di doni, danze e feste.

La collaborazione tra le figure citate sopra viene intesa nel POCLAC con le seguenti responsabilità:

• partecipare giornalmente agli eventi di ciascuna squad nell’ottica di fornire loro supporto;
• rappresentare le squad all’interno di altri meeting aziendali;
• fornire feedback costanti (1to1 o di team);
• fornire apprezzamenti.

Il POCLAC si pone in sostituzione dei ruoli di “Team Lead”. Attraverso il lavoro congiunto di questi tre ruoli si rende possibile fornire un adeguato supporto ai team sul piano di business, di competenze tecniche e di metodologie di lavoro.

Il sostegno della cultura

Dopo aver passato in rassegna il modello a matrice, è doveroso evidenziare i principi culturali che stanno alla base dell’azienda svedese e che abilitano la collaborazione verso tale modello di lavoro.

Libri, libri e ancora libri

Ciascun team deve possedere una terminologia comune sulla quale poter stimolare la collaborazione e la comunicazione; deve inoltre conoscere i principi legati all’Agilità. A tal proposito si è formata una cultura aziendale orientata alla lettura e all’approfondimento in cui ciascun membro della squad è invitato a studiare e ad approfondire le proprie competenze (tecniche) e di interazione (leadership, team building, autonomia, etc.).

Di seguito, riportiamo alcuni dei titoli più diffusi tra i vari team, la cui lettura è considerata quasi un presupposto per la concretizzazione della cultura aziendale.

• Em Campbell-Pretty, Tribal Unity: Getting from Teams by Creating a One Team Culture. Createspace Independent Pub, 2016
• Daniel H. Pink, Drive: The Surprising Truth About What Motivates Us. Riverhead Books, 2011
• Stanley McChrystal – Tantum Collins – David Silverman – Chris Fussels, Team of Teams: New Rules of Engagement for a Complex World. Penguin, 2015
• Richard Hackman, Leading Teams: Setting the Stage for Great Performances. Harvard Business School Press, 2002
• Seth Godin, Tribes: we need you to lead us. Piatkus, 2008
• Dave Logan, Tribal Leadership: Leveraging Natural Groups to Build a Thriving Organization. Harper Business, 2011
• Patrick M. Lencioni, The Five Dysfunctions of a Team: A Leadership Fable. Jossey-Bass Inc Pub, 2002

Un ambiente che “abilita” la collaborazione

In Spotify viene considerato fondamentale prendersi cura dello spazio lavorativo in cui vivono le squad.

Dalle immagini risultano evidenti i seguenti aspetti:

• spazi di lavoro chiusi “isolati” dal rumore circostante;
• spazi di lavoro con pareti trasparenti per non renderli isolanti rispetto al contesto;
• spazi semiaperti in cui è possibile visualizzare il lavoro (board a parete);
• ogni scrivania fiancheggia la parete e non viene posta al centro della stanza; in questo modo le persone sono “costrette” a darsi le spalle focalizzandosi sulle attività, dovendosi ruotare solo per necessità di collaborazione senza inutili interruzioni o distrazioni.

La gestione dello spazio diventa un fattore abilitante per la comunicazione e l’interazione tra le persone oltre che dare forma a un luogo sostenibile per la quotidianità del dipendente.

Minimum Viable Bureaucracy

Un concetto interessante introdotto da Spotify è quello rivolto a identificare un “livello minimo di burocrazia” che renda sostenibile:

• l’interazione tra le squads e le strutture aziendali (HR, Finance, Legal, etc.);
• l’interazione tra le squad di ciascuna tribe;
• la qualità del software sviluppato.

Ad esempio, invece di seguire complesse procedure di “incarico”, per rilasciare del software si indica una persona definita come “il punto di riferimento” da cui ottenere dettagli da questa nuova funzionalità, oppure si stabilisce quali applicativi utilizzare per proporre eventuali richieste specifiche (o ticket) provenienti da una squad.

Minimum Viable Agility

Allo stesso modo, è prassi comune definire all’interno di ciascuna squad “il livello minimo di Agilità”: inteso come l’insieme delle pratiche e dei framework di sviluppo necessari per garantire una qualità di sviluppo eccellente e facilmente scalabile nel tempo. In pratica, si tratta di definire ad esempio:

• eventi di retrospettiva cadenzati;
• tecniche di visualizzazione;
• daily stand-up;
• code reviews;
• Continuous Integration;
• Continuous Delivery;
• Test Automation;
• Pair Programming;
• A/B tests;
• eventi di “demo” dove ciascuna squad condivide quanto prodotto durante un’iterazione.

Condividere le proprie esperienze

Una pratica comune e quotidiana in Spotify è quella di vivere esperienze uniche durante le quali ciascuna persona o team possa esporre i propri successi, fallimenti o semplicemente mettere a disposizione le proprie competenze al fine di una crescita dell’ambiente circostante e rafforzare la propria identità personale con i valori e i principi dell’azienda. Una forma di miglioramento continuo, in due parole: Tribal Kaizen.

Per citare alcuni esempi, ecco le principali attività aperte a tutti, svolte tra i dipendenti durante la giornata (a volte fuori dall’orario lavorativo):

• Tribe Gathering: evento durante il quale ciascuna Tribe condivide i risultati raggiunti e accoglie feedback esterni;
• Tribe Demo: evento dove avvengono dimostrazioni e test su quanto sviluppato da ciascuna Tribe;
• OKRs planning meeting: evento in cui vengono definiti gli OKRs di Tribe sulla base delle indicazioni dei Tribe Leaders e dei feedback dei team;
• Big Retrospective: evento di retrospettiva tra più Tribe;
• Post-mortems: “retrospettiva” su un singolo progetto ormai concluso, per valutare cosa ha funzionato, cosa non è andato e come agire in analoghi progetti futuri;
• Unconferences
• Hack Weeks
• Tech blog
• Lean Lunch

La fiducia al posto del “controllo”

La fiducia prima di tutto: in Spotify come in generale nella cultura nordico europea. Dalla foto in figura 9 è possibile notare come vi sia una totale assenza di controllo verso i materiali (computer, accessori, cavi, etc.) messi a disposizione dell’azienda per facilitare il lavoro dei propri dipendenti.

Il principio che tutti seguono è “Mi fido che tu ne sappia fare buon uso e restituirlo una volta che non ne avrai più bisogno per permettere agli altri di usufruirne”.

Principio simile viene applicato per effettuare le trasferte: ai dipendenti era assegnato un budget fisso con il quale erano liberi di poter decidere che viaggi di lavoro effettuare senza dover chiedere alcuna autorizzazione ai propri manager o HR.

Infine non era ritenuto necessario tracciare le ore lavorative dei dipendenti.

Conclusioni

Dicevamo il mese scorso che Spotify applica molti dei principi alla base della cultura degli stati scandinavi, dal rispetto della persona nei suoi valori e principi all’idea di fornire il servizio migliore ai cittandini, fino al concepire il proprio luogo di residenza — e il proprio ambiente di lavoro — come un contesto vivibile, che favorisce le relazioni interpersonali. Per questo viene data una particolare attenzione alle interazioni sociali al di fuori dell’orario lavorativo, con l’organizzazione di svariate attività, volte a compensare gli effetti “depressivi” legati al particolare ritmo di illuminazione solare e alle condizioni avverse del clima di quelle latitudini [4]

È anche per queste ragioni che un’azienda come Spotify ha applicato concetti analoghi verso i propri dipendenti e verso i clienti “finali”. Ed è anche per questa cultura sottostante alla propria organizzazione aziendale che i risultati di crescita esponenziale si sono ottenuti senza dover “comprare dei modelli di lavoro” preconfezionati o compiere delle “Digital Transformation” dal percorso prestabilito.

Spotify è nata con i principi culturali qui esposti e si è evoluta ascoltando e prevedendo i bisogni dei propri “cittadini” di tutto il mondo. Se non si conosce o si tralascia questo aspetto, rimarrà forte l’idea che esista un “modello Spotify” preconfezionato che una qualche società di consulenza può “vendere” come un plug-in installabile in qualunque azienda per scalare Agile. Ma le cose stanno in modo un po’ diverso, e ci auguriamo di averne quantomeno illustrato gli aspetti principali in questi articoli.