- Brawa na Sprint Review — 06/09/2024
- Kanban — Jak zacząć? — 30/08/2024
- Definicja Ukończenia kontra Kryteria Akceptacji — 26/08/2024
Model Spotify — to co widać na obrazku
Spotify to firma, aplikacja, usługa streamingu muzyki. Jednak od pewnego czasu jest to też nazwa popularnego modelu skalowania Agile a nawet Transformacji Agile.
Kiedy w 2015 roku bank ING w Holandii ogłosił, że przeprowadzi transformację w ten sposób, przyciągnął uwagę instytucji finansowych. Od tego momentu Model Spotify jest określany również jako the ING Bank Model. Ta druga nazwa brzmi już bardziej poważnie. Jeśli model zadziałał w jednym banku, to biorąc pod uwagę podobieństwo struktury i oferowanych produktów powinien też zadziałać w innych bankach. A jak coś działa w bankach, to w sumie powinno sprawdzić się w każdej korporacji, prawda?
Skąd pomysł na Model Spotify?
Spotify zaczęło swoją przygodę jako mały startup w 2008 roku jednak po otrzymaniu inwestycji i pozyskaniu dużej liczbie użytkowników musiało zacząć szybko się rozrastać. Wtedy pojawiła się potrzeba zbudowania organizacji, której struktura pozwoli pracować większej liczbie ludzi zachowując startupowy sposób pracy. W 2012 został opublikowany artykuł Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds.
Z jednej strony chcemy zachować szybkość podejmowania decyzji w małych zespołach i krótki time to market charakteryzujący startup, a z drugiej strony budujemy jeden duży produkt, który powinien być spójny dla użytkowników. Zatem potrzebujemy czegoś co umożliwia dużą autonomię i dużą zgodność kierunku (high autonomy and high alignment). Potrzebna jest jakaś struktura spinająca zespoły, ale na tyle lekka, żeby ich nie spowalniać.
“Naszym celem jest popełniać błędy szybciej niż ktokolwiek inny
— Daniel Ek, założyciel Spotify”
Patrząc na rysunek struktury nie widać na co została zoptymalizowana cała organizacja i co dają autonomia i zgodność kierunku. Każdy model jest nastawiony na jakiś cel. Spotify stanęło w szranki z konkurencja taką jak Apple czy Google, więc musiało jakoś zbudować konkurencyjność i przewagę. Spotify jako główny cel stawia sobie szybkie uczenie się na błędach. Do tego potrzeba sposobu przeprowadzania wielu szybkich (nie zawsze udanych) eksperymentów, szybkiego podejmowania decyzji i szybkiego procesu wdrażania produktu. Temu właśnie ma służyć taki model organizacji.
Squad — startup
Podstawową jednostką organizacyjną w Spotify jest multidyscyplinarny zespół, który nazywa się Squad. Squad ma zapewniać skupienie na wartości i podejście startupowe. Liczebność Squadu wynosi od 6 do 12 członków. Produkt jest podzielony na wyraźne obszary, tak żeby każdy Squad wiedział jaką ma misję i jaką wartość dostarcza. Przyrosty produktu z tego zespołu powinny być łatwe do zintegrowania i do wydania. Zespół otrzymuje wsparcie organizacji w rozwiązywaniu problemów, czyli ma jasną ścieżkę eskalacji jeśli sam czegoś nie może rozwiązać. Dlaczego Squad a nie po prostu Scrum Team? Ponieważ niektóre zespoły korzystają ze Scrum, niektóre z Kanban, kolejne z Programowania Ekstremalnego, inne mają mix podejść.
Każdy zespół ma swojego Product Ownera i Agile Coacha. Agile Coach może być współdzielony między zespołami. Squad pracuje bezpośrednio z interesariuszami. W ramach rozwoju produktu zespoły są zachęcane do stosowania podejścia Lean Startup, czyli skupieniu się najpierw na zbudowaniu MVP (Minimal Viable Product), a następnie testach A/B. Każdy członek zespołu może poświęcić 10% czasu na hack days, czyli pracę nie związaną z Backlogiem Produktu. W ten sposób powstają narzędzia, usprawnienia i innowacje (innowacja wymaga poświęcenia czasu na nią). Czasem powstają nawet nowe funkcjonalności takie jak na dobieranie muzyki w tempie biegania, kiedy zespół chce sprawdzić czy coś “da się zrobić”.
Główną cechą Squadów jest autonomia zespołu i samodzielność członków zespołów. Kilka razy na różnych konferencjach podkreślano, że jeśli czekasz aż ktoś Ci powie co robić, to Spotify nie jest miejscem dla Ciebie. Chcesz pracować w jakimś Squadzie, chcesz zmienić coś w procesie, w produkcie? Po prostu zrób to. Squad może decydować co i jak zbudować. Squad jest właścicielem przynajmniej jednego komponentu w architekturze Spotify i zajmuje się nim od koncepcji do utrzymania. Oczywiście architektura organizacji ma odzwierciedlenie w architekturze systemu. Każdy komponent jest wyspecjalizowanym oprogramowaniem pełniącym konkretną funkcję. Jest to zgodne z prawem Conwaya.
Tribe — inkubator statrupów
Pomysł samodzielnych Squadów wydaje się idealny, ale wiadomo, że w rzeczywistości zespoły pracujące nad tym samym produktem, czy tą samą funkcjonalnością będą miały zależności. Tribe ma być inkubatorem dla startupów, czyli squadów. Squady potrzebują odpowiedniego środowiska, które zapewnia zasoby, umożliwia komunikację i pomaga rozwiązać zależności. Dlatego Squady pracujące w podobnym obszarze są zebrane w Tribe. Zespoły w Tribe są kolokowane — siedzą w tym samym miejscu i blisko siebie. Rozkład biura wspiera pracę w zespole i komunikację między zespołami.
Za Tribe, a dokładniej za środowisko dla Squadów jest odpowiedzialny Tribe Lead. Tribe Lead również odpowiada za innowację i współpracę Squadów w ramach tego Tribe’u. Zauważ, że nie jest to szef Product Ownerów.
W ramach Tribe śledzone są zależności pomiędzy Squadami. Zależności opóźniające pracę zespołów są rozwiązywane poprzez zmianę priorytetów, reorganizację zespołów, zmiany w architekturze lub inne rozwiązania techniczne. W razie ścisłej współpracy zespołów nad produktem, do codziennej synchronizacji wykorzystywana jest praktyka Scrum of Scrums.
Ze względów praktycznych idealna liczebność Tribe’u jest ograniczona do 100 osób. Jest to związane z liczbą Dunbara, która określa maksymalną ilość osób z jakimi możemy mieć relację.
Ciekawostka. W PKO BP zamiast Tribe używa się określenia Formacja.
Synchronizacja i komunikacja pomiędzy Squadami
Duża autonomia Squadów może prowadzić do lokalnych optymalizacji i zatracenia perspektywy całej organizacji. W dużej organizacji dobrym pomysłem jest ustalenie pewnych standardów, rozprzestrzenianie dobrych pomysłów i praktyk. Istotne jest zbudowanie potrzebnego rozwiązania w jednym zespole, żeby uniknąć duplikacji prac. Czyli z jednej strony mamy potrzebę autonomii, a z drugiej zapewnienie spójności i skorzystanie z ekonomii skali. Trzeba stworzyć kompromis. W tym celu Spotify stworzyło Chaptery i Gildie (ang. Guild).
Chapter — spójność i rozwój kompetencji
Chapter zrzesza ludzi o podobnych umiejętnościach w ramach Tribe’u. Chapter jako obszar kompetencji ma zapewnić spójne standardy pracy i rozwój umiejętności. Chapter ma swojego lidera — Chapter Lead. Chapter Lead jest kierownikiem liniowym odpowiedzialnym za rozwój kompetencji i ustalanie wynagrodzenia. Jednakże bardzo ważne jest, że Chapter Lead wykonuje pracę w ramach Squadu. Każda osoba w Squadzie ma Product Ownera i Chapter Leada, z którym współpracuje. Dzięki tym dwóm różnym odpowiedzialnościom zapewniony jest dobry balans pomiędzy dostarczaniem jak największej wartości biznesowej i zapewnienie dobrej jakości rozwiązania.
Gildia — krąg zainteresowań
Gildia to społeczność skupiająca osoby o podobnym zainteresowaniu (community of interest). Dobrym przykładami są Gildia Agile Coachów czy Gildia Testowania, Gildia Developerów Webowych. Taka grupa ludzi wymienia się wiedzą, doświadczeniami, narzędziami i praktykami. Tutaj nacisk jest na przepływ wiedzy i dobrych pomysłów, a nie na utrzymanie standardów. Czasem tematem Gildii może być rozwiązanie wspólnego problemu. Gildia zrzesza ludzi z różnych Tribów często z podobnych Chapterów, ale dostępna jest dla wszystkich zainteresowanych. Za działanie Gildii odpowiada koordynator (ang. Guild Coordinator). Gildie powstają organicznie, kiedy formuje się grupa osób o podobnym zainteresowaniu. Taka grupa zwykle organizuje cykliczne spotkania w formie Unconference albo Open Space Technology.
Podsumowanie
Tak zwany Model Spotify pokazuje tylko i jedynie jak zorganizować zespoły pracujące w obrębie jednego, dużego produktu. Jest to model organizacji matrycowej, jednak podstawą jest autonomiczny zespół, a nie dział, z którego wypożycza się zasoby.
Nie wszystkie role i zależności między nimi są widoczne na bardzo popularnym obrazku pokazującym strukturę.
Nie wyjaśniono też jak powstaje uzgodnienie pomiędzy Product Ownerami, ani jak podejmowane są decyzje co do rozwoju całego produktu. Jak powstaje strategia? Kto decyduje o celach biznesowych? Jak wyglądała droga Spotify do modelu, który opublikowali i czy nadal tak pracują? Tego nie widać na popularnym obrazku.
Zapraszam do kolejnych części, gdzie będziemy schodzić w dół góry lodowej.