De ce copierea modelului Squads and Tribes de la Spotify probabil că nu va funcționa pentru dumneavoastră

Care sunt problemele mărturisite de Spotify cu acest model?

Acest model nu este în niciun caz un panaceu. Au existat multe păreri din partea celor care au lucrat la Spotify care au explicat neajunsurile modelului lor și, se pare, realitatea nu a ținut pasul cu mitul agile nirvana.

„Mă îngrijorează când oamenii se uită la ceea ce facem noi și cred că este un cadru pe care pot pur și simplu să-l copieze și să-l implementeze. … Acum ne străduim din greu să subliniem faptul că și noi avem probleme. Nu este totul „strălucitor și totul funcționează bine și toate echipele noastre sunt super uimitoare”.”

Anders Ivarsson, co-autor al cărții albe Spotify

Subiectul 1: Cultura de inginerie nu este o structură organizațională

Conținutul original pe care Spotify l-a publicat pentru a explica metoda lor s-a numit Spotify Engineering Culture. Deși au prezentat o structură organizatorică, era vorba în principal despre cultura lor de inginerie și despre principiile lor de lucru de bază (a se vedea mai jos o listă a acestora).

Problema 2: Modelul a fost o ambiție și nu a fost adoptat pe deplin

Când Spotify și-a publicat cartea albă, aceasta a fost în parte ambiție și în parte realitate. Ei expuneau o viziune pentru viitor.

„Chiar și în momentul în care am scris-o, nu o făceam. Era parte ambiție, parte aproximare. Oamenii s-au străduit cu adevărat să copieze ceva ce nu exista cu adevărat.”

Joakim Sundén, antrenor agile la Spotify 2011-2017

Subiectul 3: Modelul optimizat pentru autonomia completă a echipei

Pe măsură ce dimensiunea echipelor a crescut, Spotify nu a definit un proces comun pentru colaborarea între echipe. Atunci când fiecare echipă avea un mod unic de lucru și nu existau linii directoare cu privire la alegeri, productivitatea organizației în ansamblu a avut de suferit.

Cuza 4: Colaborarea între echipe a fost o competență asumată

Cum a crescut numărul de echipe, s-a recunoscut că era nevoie de un sprijin dedicat pentru a ghida și structura colaborarea între echipe. Sunt necesare structuri sau procese dedicate pentru a permite echipelor care nu sunt neapărat legate între ele să colaboreze împreună.

„În articole sau discuții de acest gen, se poate da impresia că Spotify este un fel de nirvana agilă în care totul funcționează pur și simplu nu este adevărat.”

Henrik Kniberg, creatorul modelului Spotify

Amintiți-vă că modelul Spotify a fost creat în urmă cu peste 10 ani, așa că este foarte puțin probabil ca, având în vedere problemele identificate mai sus, și poate și altele, să fie exact modelul pe care îl folosesc acum. Spotify este o companie care învață și se dezvoltă în mod constant, așa că vor fi evoluat acest model de multe ori de când a fost creată cartea albă originală. Cu toate acestea, există încă multe lucruri pe care le putem învăța, chiar dacă nu ar trebui să aplicați modelul în mod direct.

Puterea modelului Spotify constă mai degrabă în principiile sale de inginerie decât în designul său de organizare

Reala magie a modelului Spotify a fost în cultura de inginerie și de dezvoltare a produsului pe care au creat-o pentru echipe agile rapide, motivate și decuplate. De-a lungul timpului, au dezvoltat câteva principii de lucru de bază puternice care au stat la baza performanței lor ridicate:

1. Productivitatea este strâns legată de motivație – Motivația are un impact mai mare asupra productivității decât orice alt factor (a se vedea lucrarea Joy Inc a lui Richard Sheridan). Spotify folosește formula Productivitate = Efort x Competență x Mediu x Motivație.
2. Echilibru între aliniere și autonomie – Spotify se străduiește să găsească un echilibru între aliniere (direcție centrală) și autonomie (autoorganizarea echipei). Managerii descriu imaginea de ansamblu, dar nu le spun oamenilor cum să ajungă acolo sau cum să rezolve problemele.
3. Lansări decuplate pentru a reduce durata ciclului – Spotify și-a schimbat arhitectura pentru a decupla dependențele și a face lansările mai ușoare și mai rapide. Acest lucru a permis realizarea unor versiuni de producție mai frecvente, care pot fi independente între echipe.
4. Încredere în oamenii dumneavoastră – Spotify are încredere în oamenii săi și îi sprijină fără a încerca să îi controleze, deoarece consideră că majoritatea oamenilor fac ceea ce este mai bine pentru organizație.
5. Managerii ca lideri servitori – Este mai bine ca managerii să întrebe echipele cum pot ajuta, decât să întrebe oamenii la ce lucrează sau când vor termina.
6. Maximizați valoarea în locul ocupației – Echipele generează idei, fac experimente rapide și apoi măsoară rezultatele. Pornind de la acestea, ele își ajustează abordarea pentru a maximiza valoarea. Este important faptul că acestea optimizează pentru maximizarea valorii și nu doar a producției.
7. Cultura îmbunătățirii – Echipele sunt încurajate să îmbunătățească modul în care lucrează și au un model pentru ceea ce le-ar face viața mai ușoară și mai bună. Există resurse dedicate disponibile pentru a ajuta la îmbunătățirea modurilor de lucru în întreaga organizație.
8. Cultura sănătoasă vindecă procesele defecte – Procesele se pot strica adesea, dar o cultură sănătoasă îi va determina pe oameni să rezolve singuri aceste probleme.
9. Definiția echipei de minunat – Spotify încurajează echipele să vorbească despre și să decidă ce le-ar face minunate. La urma urmei, fără o viziune pentru grozavitate, este puțin probabil să ajungeți acolo. Echipele Spotify folosesc periodic „verificări ale sănătății echipei” și urmăresc îmbunătățirile în timp. Î: Echipele dvs. au o definiție a grozaviei? Urmăriți starea de sănătate a echipei și vă străduiți să vă îmbunătățiți continuu?
10. Satisfacția angajaților este de cea mai mare importanță – Șeful departamentului de personal al Spotify a afirmat că 91% dintre angajați se bucură să lucreze la Spotify, ceea ce, potrivit lui, „bineînțeles că nu este satisfăcător”… atât de înaltă este ștacheta pe care și-o impun.
11. Greșelile sunt OK – Directorul executiv al Spotify explică faptul că greșelile sunt de așteptat atunci când împingi spre inovație. Pentru a atenua acest lucru, Spotify are o mulțime de sisteme încorporate pentru a limita efectele eșecurilor.

„Ne propunem să facem greșeli mai repede decât oricine altcineva”.

Daniel Ek, fondator al Spotify

După cum puteți vedea, există câteva concepte grozave încorporate în model, dar acesta nu este un plan pentru un design organizațional agil prin el însuși.

Iterați folosind inspecția și adaptați-vă pentru a vă crea propriul model țintă

Contextul organizației dvs., de unde porniți, cultura dvs., obiectivele și mulți alți factori vor determina cea mai bună soluție pentru dvs.

Desigur, puteți cerceta și împrumuta idei de la companii precum Spotify, Menlo Innovations, Google sau alte companii foarte performante, dar acesta ar trebui să fie doar punctul de plecare.

Trebuie să știți cu claritate ce problemă încercați să rezolvați și apoi să creați un plan bazat pe rezolvarea setului dvs. unic de provocări.

Inspectarea și adaptarea este un concept de bază al agile.

Inspecția constă în utilizarea unei minți deschise și a unui feedback transparent (cel mai adesea realizat în cadrul unei retrospective) pentru a privi cu onestitate ce funcționează și ce nu funcționează. Poate fi vorba de orice, de la procese, dinamica echipei, strategie sau ineficiență, orice lucru care împiedică performanța echipei și îi reduce motivația și implicarea.

Adaptarea este procesul de a lua temele din introspecție și de a găsi modalități de a răspunde și de a le îmbunătăți. Adaptarea necesită creativitate și efort și, adesea, ia forma unui experiment. Se efectuează un mic test cu un subansamblu de echipe pentru a se asigura că soluția este viabilă, înainte de a fi implementată în întreaga organizație.

Acest proces se repetă apoi de fiecare dată când organizația dvs. este îmbunătățită și se apropie mai mult de starea de a fi ideală pe care o urmăriți.

Să vă inspirați, dar nu copiați orbește

Există multe lucruri care să vă placă la modelul Spotify, dacă adoptați principiile lor de inginerie și luați ca model spiritul a ceea ce încearcă să facă.

Contextul este totul, așa că, dacă nu sunteți o companie suedeză de streaming de muzică, atunci este puțin probabil să copiați orbește Spotify pentru a vă rezolva problemele.

Cu toate acestea, este foarte puțin probabil ca o copiere orbească a modelului să funcționeze pentru dumneavoastră. Este important să vă inspirați din mai multe surse, dacă doriți să vă extindeți agile în organizația dvs.

Dacă doriți să scalați agile și aveți mai mult de 150 de persoane în echipa dvs., atunci două modele bune de scalare sunt:

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

Dacă aveți mai puțin de 150 de persoane, Shape Up by Basecamp este un model excelent la care să aspirați.

Spotify nu este o nirvana agilă

Sper că acest articol a evidențiat faptul că cultura de inginerie agilă de la Spotify este mult mai mult decât crearea de escadroane, capitole, triburi și bresle.

De fapt, modelul Spotify constă în principal în cultura sa și în echipele de înaltă competență, nu în designul său organizațional. Puteți obține beneficii uriașe prin adoptarea principiilor chiar și fără a implementa squads și triburi.

„În articole sau discuții de genul acesta poate apărea ideea că Spotify este un fel de nirvana agilă în care totul funcționează pur și simplu, iar acest lucru pur și simplu nu este adevărat.”

Henrik Kniberg

Versiunea rapidă a modului de a scala agile

Voi scrie o întreagă postare pe blog pe această temă în viitor, dar deocamdată iată versiunea rapidă a modului în care ar trebui să procedați pentru a scala agile în organizația dumneavoastră:

1. Să vă fie clar ce problemă încercați să rezolvați.
2. Consumați cele mai bune și mai relevante părți ale celor mai bune modele de scalare din industrie, de exemplu SAFe, LeSS, DaD etc. în designul dvs. țintă.
3. Desenați o stare țintă care preia cele mai bune practici adaptate pentru setul dvs. unic de provocări.
4. Faceți schimbări către designul dvs. de stare țintă.
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!