Perché copiare il modello Squadroni e Tribù di Spotify probabilmente non funzionerà per voi

Quali sono i problemi che Spotify ha dichiarato di avere con questo modello?

Questo modello non è affatto una panacea. Ci sono stati molti approfondimenti da parte di coloro che hanno lavorato in Spotify che hanno spiegato i difetti del loro modello e, a quanto pare, la realtà non ha tenuto il passo con il mito del nirvana agile.

“Mi preoccupa quando la gente guarda quello che facciamo e pensa che sia un framework che possono semplicemente copiare e implementare. … Stiamo davvero cercando di sottolineare che anche noi abbiamo dei problemi. Non è tutto ‘luccicante e tutto funziona bene e tutte le nostre squadre sono super fantastiche’.”

Anders Ivarsson, co-autore del white paper di Spotify

Problema 1: la cultura ingegneristica non è una struttura organizzativa

Il contenuto originale che Spotify ha rilasciato spiegando il loro metodo si chiamava Spotify Engineering Culture. Anche se hanno delineato una struttura organizzativa, si trattava principalmente della loro cultura ingegneristica e dei loro principi fondamentali di lavoro (vedi sotto per una lista di questi).

Problema 2: Il modello era un’ambizione e non è stato adottato completamente

Quando Spotify ha pubblicato il suo libro bianco era in parte ambizione e in parte realtà. Stavano esponendo una visione per il futuro.

“Anche quando l’abbiamo scritto, non lo stavamo facendo. Era in parte ambizione, in parte approssimazione. La gente ha fatto davvero fatica a copiare qualcosa che non esisteva davvero.”

Joakim Sundén, agile coach di Spotify 2011-2017

Il modello ottimizzato per la completa autonomia del team

Con la crescita delle dimensioni dei team, Spotify non ha definito un processo comune per la collaborazione tra team. Quando ogni team aveva un modo unico di lavorare, e non c’erano linee guida sulle scelte, la produttività complessiva dell’organizzazione ne soffriva.

Questione 4: La collaborazione tra i team era una competenza presunta

Come il numero di team è cresciuto, è stato riconosciuto che era necessario un supporto dedicato per guidare e strutturare la collaborazione tra i team. Sono necessarie strutture o processi dedicati per permettere ai team che non sono necessariamente collegati di collaborare insieme.

“In articoli o discorsi come questo, si può pensare che Spotify sia una sorta di nirvana agile dove tutto funziona e questo non è semplicemente vero.”

Henrik Kniberg, Creatore del Modello Spotify

Ricorda che il modello Spotify è stato creato più di 10 anni fa, quindi è molto improbabile che, alla luce dei problemi identificati sopra, e forse altri, questo sia il modello esatto che stanno usando ora. Spotify è un’azienda che impara e cresce costantemente, quindi avrà evoluto questo modello molte volte dal white paper originale. Tuttavia, c’è ancora molto che possiamo imparare, anche se non si dovrebbe applicare il modello direttamente.

La potenza del modello Spotify è nei suoi principi di ingegneria piuttosto che nel suo design organizzativo

La vera magia del modello Spotify era nella cultura di ingegneria e sviluppo del prodotto che hanno creato per team agili veloci, motivati e disaccoppiati. Nel corso del tempo, hanno sviluppato alcuni potenti principi di lavoro fondamentali che sono alla base delle loro alte prestazioni:

1. La produttività è strettamente legata alla motivazione – La motivazione ha un impatto maggiore sulla produttività di qualsiasi altro fattore (vedi Joy Inc di Richard Sheridan). Spotify usa la formula Produttività = Sforzo x Competenza x Ambiente x Motivazione.
2. Equilibrio tra allineamento e autonomia – Spotify cerca di trovare un equilibrio tra allineamento (direzione centrale) e autonomia (auto-organizzazione del team). I manager dipingono il quadro generale ma non dicono alle persone come arrivarci o come risolvere i problemi.
3. Rilasci disaccoppiati per ridurre il tempo di ciclo – Spotify ha cambiato la sua architettura per disaccoppiare le dipendenze e rendere i rilasci più facili e veloci. Questo ha permesso rilasci di produzione più frequenti che possono essere indipendenti tra i vari team.
4. Fidati della tua gente – Spotify si fida e supporta la sua gente senza cercare di controllarla perché crede che la maggior parte delle persone stia facendo ciò che è meglio per l’organizzazione.
5. Manager come leader servitori – È meglio per i manager chiedere ai team come possono aiutare, piuttosto che chiedere alle persone su cosa stanno lavorando o quando avranno finito.
6. Massimizzare il valore rispetto all’impegno – I team generano idee, fanno esperimenti veloci e poi misurano i risultati. Da questo, modificano il loro approccio per massimizzare il valore. Importante, ottimizzano per massimizzare il valore e non solo l’output.
7. Cultura del miglioramento – I team sono incoraggiati a migliorare il loro modo di lavorare, e hanno un modello per ciò che renderebbe la loro vita più facile e migliore. Ci sono risorse dedicate disponibili per aiutare a migliorare i modi di lavorare in tutta l’organizzazione.
8. Una cultura sana guarisce i processi interrotti – I processi possono spesso rompersi, ma una cultura sana porterà le persone a risolvere questi problemi da sole.
9. Definizione del team di fantastico – Spotify incoraggia i team a parlare e decidere cosa li renderebbe fantastici. Dopo tutto, senza una visione della grandezza, è improbabile che ci si arrivi. I team di Spotify usano regolari “controlli di salute del team” e tracciano i miglioramenti nel tempo. D: I vostri team hanno una definizione di fantastico? Tracciate la salute del team e vi sforzate di migliorare continuamente?
10. La soddisfazione dei dipendenti è della massima importanza – Il responsabile delle persone di Spotify ha affermato che il 91% dei dipendenti ama lavorare in Spotify, il che è “ovviamente non soddisfacente”… tale è l’alto livello che si prefiggono.
11. Gli errori sono OK – Il CEO di Spotify spiega che gli errori sono previsti quando si spinge all’innovazione. Per mitigare questo, Spotify ha un sacco di sistemi costruiti per limitare gli effetti dei fallimenti.

“Puntiamo a fare errori più velocemente di chiunque altro”.

Daniel Ek, fondatore di Spotify

Come potete vedere, ci sono alcuni grandi concetti incorporati nel modello, ma non è un modello di progettazione organizzativa agile da solo.

Iterate usando l’ispezione e adattatevi per creare il vostro modello di riferimento

Il contesto della vostra organizzazione, da dove state partendo, la vostra cultura, gli obiettivi e molti altri fattori determineranno la soluzione migliore per voi.

Ovviamente, potete ricercare e prendere in prestito idee da aziende come Spotify, Menlo Innovations, Google, o altre aziende altamente performanti, ma questo dovrebbe essere solo il punto di partenza.

Dovete sapere con chiarezza quale problema state cercando di risolvere e poi creare un piano basato sulla risoluzione del vostro unico insieme di sfide.

Ispettare e adattare è un concetto centrale dell’agile.

Ispettare significa usare una mente aperta e un feedback trasparente (il più delle volte eseguito in una retrospettiva) per guardare onestamente cosa sta funzionando e cosa no. Questo potrebbe essere qualsiasi cosa, dai processi, alle dinamiche di squadra, alla strategia o alle inefficienze, qualsiasi cosa che impedisca le prestazioni della squadra e riduca la loro motivazione e proprietà.

Adattare è il processo di prendere i temi dall’introspezione e trovare modi per rispondere e migliorarli. L’adattamento richiede creatività e sforzo e spesso prende la forma di un esperimento. Si esegue un piccolo test con un sottoinsieme dei team per assicurarsi che la soluzione sia fattibile, prima che sia estesa a tutta l’organizzazione.

Questo processo viene poi ripetuto ogni volta che la vostra organizzazione viene migliorata e si avvicina al vostro stato d’essere ideale.

Siate ispirati ma non copiate alla cieca

C’è molto da apprezzare nel modello di Spotify, se si adottano i loro principi di ingegneria e si modella lo spirito di ciò che stanno cercando di fare.

Il contesto è tutto, quindi a meno che non siate una società svedese di streaming musicale, è improbabile che copiare alla cieca Spotify possa risolvere i vostri problemi.

Tuttavia, è molto improbabile che copiare alla cieca il modello funzioni per voi. È importante trarre ispirazione da più fonti, se volete scalare l’agilità nella vostra organizzazione.

Se vuoi scalare agile e hai più di 150 persone nel tuo team, allora due buoni modelli di scalabilità sono:

1. Scaled Agile Framework (SAFe)
2. Large Scale Scrum (LeSS)

Se hai meno di 150 persone, Shape Up di Basecamp è un ottimo modello cui aspirare.

Spotify non è un nirvana agile

Spero che questo articolo abbia evidenziato che la cultura agile dell’ingegneria in Spotify è molto più che creare squadroni, capitoli, tribù e gilde.

In effetti, il modello Spotify è principalmente la sua cultura e i suoi team ad alta competenza, non il suo design organizzativo. Si possono ottenere enormi benefici adottando i principi anche senza implementare squadriglie e tribù.

“In articoli o discorsi come questo si può pensare che Spotify sia una sorta di nirvana agile dove tutto funziona e basta, ma non è vero.”

Henrik Kniberg

La versione veloce di come scalare agile

Scriverò un intero post sul blog su questo in futuro, ma per ora ecco la versione veloce di come dovreste andare a scalare agile nella vostra organizzazione:

1. Disponete chiaramente quale problema state cercando di risolvere.
2. Consuma le parti migliori e più rilevanti dei migliori modelli di scaling dell’industria, per esempio SAFe, LeSS, DaD ecc. nel tuo design di destinazione.
3. Progetta uno stato di destinazione che prenda le migliori pratiche su misura per il tuo unico insieme di sfide.
4. Modifica il design del tuo stato di destinazione.
5. Inspect and adapt constantly to find improvements based on evidence.
6. Make course corrections based on the feedback.
7. Rinse and repeat steps 4 to 6!